1.模拟对比：
先按原来几何，只改水池厚为1.8m模拟分析本底情况
再将低温壁和无氧铜改为5cm的聚四氟乙稀模拟计算并进行对比
2.计算中子穿过水池的效果
计算出中子的剩余比例和能谱分布.
3.问题
使用聚四氟乙稀方案下，水池壁的不锈钢是否有问题水池壁改为水泥，模拟中相当于岩石了
There are comments.
Other articles
七月模拟
ApplicationRuntimeHandler及IRuntimeHandler文档解析
ApplicationRuntimeHandlers
类图如下：
文档解析：
匹配app和backend的handlers机制。
1.add(self,application,backend,handler)
2.get(self,application,backend)
3.getAllBackends(self,application=None)
4.getAllApplication(self,backend=None)
IRuntimeHandler
类图如下：
文档解析：
RuntimeHandler是一个连接器，用来连接app和backend。app的configure方法产生appconfig对象。backend的submit方法使用jobconfig对象。RuntimeHandler将appconfig对象转换成jobconfig对象。该转换是作业提交的一部分。它在prepare方法中实现。
1.master_prepare(self,app,appmasterconfig)
- 为作业提交的共性（共享）部分做一些准备
- 每个作业调用一次（包括要拆分作业或者不拆分的作业）
- 返回值为backend可理解的jobmasterconfig对象
- 参数
- - app: 原始的app对象
- - appmaster ...
There are comments.
IMerger及ISplitter文档解析
IMerger
类图如下：
文档解析：
1.merger(self,subjobs,sum_outputdir,**option)
- 合并子作业的输出到sum_outputdir.
- options（关键字参数）由具体的子类定义
2.validatedMerge(self.job)
ISplitter
类图如下：
文档解析：
1.split(self,job)
- 根据主作业返回子作业列表
- 主作业不会被更改
- 具体子类必须实现本方法
- 修改子作业的确定部分（如特定的属性）。子作业的其他部分都会相同。只有在schema中声明为"splitable"的属性才可修改。如果app handler不能处理被修改的参数，这个限定应用在app对象上就可以避免前后不一致。
- 当前的实现中，backend的类型也不可更改。
2.validatedSplit(self,job)
- 调用split()方法执行作业拆分，并使mutability inveriants有效
- 如果invariants损坏(或者split()中发生异常），则抛出SplittingError异常 ...
There are comments.
IApplication文档解析
类图如下：
是所有app对象的基类。子类在GPI中给出程序逻辑并从功能上实现配置操作。app配置是作业提交的第一步。
实现配置方法的基本规则：
一般configure()和master_configure()方法会在作业提交的时候调用，所以原则上你
方法文档：
1.master_configure(self)
- 配置app的共享（主要）方面。
- 调用一次，splitting情况下也会调用
- 返回元组(modified_flag, appconfig)
- -appconfig(或appextra): 结构任意。由特定app运行时handler处理
- -modified_flag: 如果configure()时对象self被改变了则为true
- 如果方法未实现则忽略掉
2.config(self,master_aapconfig)
- 配置app的特定方面。与方法1有类似语义并且返回元组(modified_flag,appconfig).
- 具体子类必须实现，否则作业提交（submission)会失败。
- 参数master_configure是方法1的返回
- splitting情况下每个子作业对象调用一次。即有多少子作业就会调用多少次。
- 无spliting情况下则会调用一次.
- 从Ganga4.0.x开始，方法1被忽略。
3 ...
read moreThere are comments.
Ganga中文
GangaDoc Ganga文档首页入口
3 实现
这章提供了GANGA中一些重要部分的当前实现细节。
3.1 组件
作业的各个组件以插件类的形式来实现，需用户在配置文件中设为enabled，则会由GANGA在启动时导入。这表示用户仅能看到与其特定工作环境相关的组件。
插件维护十分简单，采用了一组内部接口和一个产生代理类的机制。组件类继承自接口类。每个插件类都定义了一个schema，用它描述插件的属性和指定类型（只读/读写/内部）、可见性以及相关的用户友好(user-convinence)的过滤器和语法快捷方式(shortcut)。
与用户直接进行交互的不是插件类，而是一个自动产生的代理类，代理类在GPI中可见。代理类只包含插件类中的一些在schema中定义可见的属性以及选出用于导出的方法。插件和代理的层次（level)分离十分灵活。在GPI层插件的实现细节不可见；所有代理类都遵循相同的设计逻辑（例如按值拷贝copy-by-value)；持续性自动化，会话等级锁定透明。用这种方法，底层的内部的API就与用户层的GPI分离开。
框架不强迫开发者支持app和backend的所有组合，只要支持有意义和有趣的组合即可。为便于管理这些组合，提出了submission handler的概念。sumission handler是app和backend组件的一个连接器。在提交时间，它将app的内部表示（representation)传送给特定backend可以接受的表示(representation ...
read moreThere are comments.
Page 1 / 4 »