Keep in mind the following when re-running jobs:
-
Only application
components can be re-run.
-
The application
component must not be a referenced component (e.g., where the source
is a File Stored In Model reference, a library
reference, or a partner (federated) reference, etc.).
-
The application
component metamodel (determined by the component developer) must not
disallow database lookup, such as the “Mail” component.
-
All mapped output parameters must be saved to the database for
the mapped output parameters (see Setting Local Results Database Preferences).
-
During execution, the restored input values must exactly match the execution
input values because many Isight
process
components depend upon random number generators for their search logic.
When re-running a job, the random number generator seed for the re-executed
job is initialized to the seed value used by the original job. However,
if there are custom or third-party process
components that do not honor the reproducible random results requirement
of Isight,
normal execution begins as soon as a discrepancy is detected. This problem
does not occur with SIMULIA-supplied components.
-
If the Completion Code (see The Run Summary) of an
application
component is Failed or System Failed,
the effect of re-running the job will depend on the status of the parent
process
component as follows:
- If the parent process
component did not fail, re-running the job restores the application
component to the Failed or System Failed
state.
- If the parent process
component failed, re-running the job executes the application
component. Isight
executes the application component in this case because for many components,
it is typical to have a certain number of failed runs (e.g., bad inputs).
If the process
component ran to successful completion, Isight
restores the failed application
component’s output values rather than rerun them. Isight
does so because re-running the values could alter the output statistics
of the parent process
component, which could alter the dependent simulation process flow behavior
and cause the job re-execution to cease restoring values and begin executing
them.
However, if the process
component failed, it is likely that this point in the model is where
the external dependency caused the model to fail. In addition, every
component after this failed component would have failed to run because
of simulation process flow rules. In this case, the job re-execution
begins executing these application
components rather than restoring the failed results.
|