Understanding the Customization Process

Model customization allows you to evaluate program scripts contained within a model and transform the structure of the model.

Introduction

Model customization is performed whenever a model is run. When an Isight job is created, a copy of the not-yet-customized model is sent to the Isight runtime system (either the local runtime engine or the SIMULIA Execution Engine), along with an “initial context” that provides new initial values for the input parameters of the model’s root component. This copy is processed by the model customizer, with alterations being made in response to configuration data provided by the initial context. The resulting post-customized model is then validated. If it passes validation, the requested job is created around it and dispatched for execution. Finally, the post-customized model is returned to the client application that created the job, for use as the client requires. For example, if the job was created by the Runtime Gateway, the customized model will be displayed, with the History tab, graphs, and tables, etc., all configured to match that model.

Note: For jobs run in the SIMULIA Execution Engine environment, model customization scripts are executed on the SIMULIA Execution Engine computer, not on the stations that run the individual components. Therefore, for models that you intend to run in the SIMULIA Execution Engine environment, it is strongly recommended that you do not write customization scripts that depend on external resources (e.g., files, other programs, etc.). If this is unavoidable, you must ensure that those resources are accessible on the SIMULIA Execution Engine computer and consider the security implications and multi-user scenarios.

Customization Script Evaluation

The customization process is a complete traversal of the model hierarchy, during which each customization script that is not disabled is evaluated as follows:

  1. The customization script for the model as a whole (if one exists) is evaluated.
  2. The components of the model are visited in top-down order, beginning with the current model root component. As each component is visited, its own script (if one exists) is evaluated.
  3. If it is a process component that has child components in its simulation process flow, those child components are then visited in simulation process flow order.
  4. If one of these components is a Reference component that points to an internal submodel, the referenced submodel root is then analyzed, unless it has already been analyzed.
  5. Any component that is not accessible through the simulation process flow is not analyzed.

Scripting Languages

Each customization script is written in one scripting language and is evaluated in an “interpreter” object specific to that language. The “interpreter” implementation for each supported scripting language allows Java objects to be created in, or added to, the scripting environment and manipulated within that environment.

The supported languages are Jython and DynamicJava.

Initial Global Variables

Each script is interpreted within an environment that initially contains no global variables, except for the following Java objects:

Object Description
data A VariableCollection object containing a copy of each Input parameter of the model root component, except each copy may have a different value or values. Scripts may draw configuration data peculiar to the current job from the values of the parameters in this object.
blackboard An object used to associate String keys with Java objects. Associations persist throughout customization, so scripts can use this object to pass arbitrary data to other scripts. Associations are made and accessed via the following methods:
  • hasEntry(String key): Returns true if the blackboard contains an object associated with the given key; returns false otherwise.
  • getEntry(String key): Returns the Java object associated with the given key; throws an exception if there is no such association.
  • putEntry(String key, Object value): Associates the given key with the given object; throws an exception if that key is already associated.
log A Log object used to record messages logged during job execution. Any uncaught exception generated during customization is logged as an unrecoverable error via this object. You can use this object to make notes during customization for debugging purposes. If an error is logged during customization, customization is considered to have failed.
model The DtModelManager object representing the model to be customized. Scripts can access (and alter) the model properties and the model root component via this object and can fetch any model element given its unique internal ID.
component Used only with component scripts. The DtComponent object representing the component whose script is currently being interpreted. Scripts can access (and alter) the component’s name, properties, parameters, children, simulation process flow, dataflow, etc. via this object.
comp_api Used only with component scripts. A ComponentAPI object returned by calling the method getAPI() on the component whose script is currently being interpreted. Scripts can access (and alter) the component’s properties via this object; when the component is a process component (DOE, MonteCarlo, Optimization, etc.), scripts can access (and alter) the process component configuration via this object.

Important: This API object implements a transaction-like protocol—changes made to it are not reflected in the component unless and until the object’s apply() method is called.

Classes/Interfaces Imported

Each scripting language includes at least one “import” command (not necessarily of that name), which can be used to make external code packages available within an interpreter, including Java class and interface definitions provided by Isight or other sources. For convenience, each of the following classes or interfaces is imported before each script is interpreted:

java.lang.Boolean 
java.lang.Double
java.lang.Integer
java.io.File
com.engineous.common.i18n.IString
com.engineous.sdk.designdriver.parameters.DesignVariable
com.engineous.sdk.designdriver.parameters.Factor
com.engineous.sdk.designdriver.parameters.Objective
com.engineous.sdk.designdriver.parameters.OutputConstraint
com.engineous.sdk.designdriver.parameters.RandomVariable
com.engineous.sdk.designdriver.parameters.Response
com.engineous.sdk.designdriver.parameters.TaguchiResponse
com.engineous.sdk.designdriver.plan.DOEPlan
com.engineous.sdk.designdriver.plan.MonteCarloPlan
com.engineous.sdk.designdriver.plan.OptimizationPlan
com.engineous.sdk.designdriver.plan.ReliabilityPlan
com.engineous.sdk.designdriver.plan.SDIPlan
com.engineous.sdk.designdriver.plan.SixSigmaPlan
com.engineous.sdk.designdriver.plan.TaguchiPlan
com.engineous.sdk.designdriver.plan.TargetSolverPlan
com.engineous.sdk.log.Log
com.engineous.sdk.model.DtComponent
com.engineous.sdk.model.DtDesignPlan
com.engineous.sdk.model.DtModelManager
com.engineous.sdk.model.DtUtils
com.engineous.sdk.model.exceptions.DtModelException
com.engineous.sdk.vars.EsiTypes
com.engineous.sdk.vars.Variable
com.engineous.sdk.vars.VariableException
com.engineous.sdk.vars.VariableReference
com.engineous.sdk.vars.VariableUtil