Customization Notes and Suggestions

Isight models can be run using the Design and/or Runtime Gateways, the Command Client, or the SIMULIA Execution Engine WebTop. Customization data must be passed via root component parameters because they are the only channel available in each of these environments. Fresh data are passed as follows:

• Within a Gateway: Launch the model using the Configure and Run Model option on the Run menu, and, in the configuration dialog box, either set values for the relevant parameters by hand or select a Name-Value file.
• Within the Command Line Client: Launch the model using the start command, and set the values of the relevant parameters directly using args: assignments and/or indirectly via an input: Name-Value file.
• Within the WebTop: Change the values of the relevant parameters in your browser, send the new values back to the server, and launch the model.

The set of root-component input parameters used to pass customization data can include input file parameters, so the amount of data that can be used for customization is not at all restricted. For example, you can add an “in-model” text file to the root component and create a customization script to read the file and extract configuration data. At runtime, the text of a configuration file can replace the text in the model, if any (this is especially easy to do with a Name-Value assignment).

Model customization is performed by the Isight runtime system (even for testing). When that system is a SIMULIA Execution Engine, customization is almost certainly performed on a platform different than the one running the Isight client. Therefore, your model customization must be written using the following restrictions:

• Configuration data must not be passed via “in-file” file parameters, because the data will be inaccessible for one or both of these reasons: the file parameter names a file or directory that does not exist on the SIMULIA Execution Engine platform, or the SIMULIA Execution Engine may have security enabled, so that no file input/output can be performed by the customization script (or anything else running within the SIMULIA Execution Engine). Similar restrictions will most likely apply to URL-type file parameters.
• No customization script can run an independent program, particularly not an interactive program. This restriction means you cannot pass configuration data by launching a custom GUI into which the data can be entered.

Although no component’s script is interpreted unless that component is reachable from the root component via the simulation process flow, you should remember that a component that is initially out of the sim-flow may be brought into the sim-flow by another component’s script and may then be reachable.

You may find it convenient for your model customization scripts to follow this protocol: First, the whole-model script processes the given configuration data (e.g., reading and parsing “in-model” file parameter text), reorganizes it for greater convenience, and places the data on the blackboard. Second, each component script takes its own portion of the configuration data from the blackboard and customizes itself accordingly.

While no key may be put into the blackboard more than once (so that the Java object associated with a key cannot be changed), this object can be a Java container object, whose contents may be freely changed.

When a job is loaded in the Runtime Gateway, the customized model is displayed. The customization script will not be available in the customized model even when the model from the Runtime Gateway is saved as a ZMF file.