| Summary: | /process/em/deexcitation is not defined until after /run/initialize | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Michael Kelsey <kelsey> |
| Component: | Application Developers Guide | Assignee: | Vladimir.Ivantchenko |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | ||
| Priority: | P5 | ||
| Version: | 10.2 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Michael Kelsey
2016-01-26 03:18:10 CET
Hi Mike, before 10.2 it was a strong requirement to apply any de-excitation UI command after "/run/initilize". If in some manual for 10.1 and early releases there is sometning opposite - it is a bug. For 10.2 this is not anymore a requirement. The only constrain: EM physics constructor should be instantiated before any EM UI command. It is the case for all reference PhysList and all PhysLists of EM examples. In 10.2 we recommend to define EM options before "/run/initialize", simply because by that we avoid double initialisation: in many cases a change of a EM parameters (not necessary de-excitation command) require re-initiliasation. So, for 10.2 this bug report means that ADM should be checked. Is it correct? I do not see any further need improving EM initialisation logic in general. If concerns to details we , of course, can do. Vladimir For 10.3 this question is not any more actual. Documentation also is updated. |