Customization of Published Models

The typical model customization process explains all customization except the customization of published submodels. When a job is created for a model containing one or more Reference components configured to use published submodels, at some point the running job must fetch a copy of the submodel from the Isight library, customize it, and run it as if it were part of the model.

This implementation poses two questions: Precisely when is the submodel copy to be fetched, and what is passed as its configuration data? Isight answers these questions by providing the following fetch modes:

  • Just once before the model runs. The submodel copy is fetched and customized when the associated Reference component is reached during customization of the model; the parameters of the Reference component, possibly changed by customization, are passed as configuration data. From then on the post-customized submodel is run when the Reference component is run.

  • Just once when this reference first runs. The submodel copy is fetched and customized when the associated Reference component is to be run for the first time; the parameters of the runtime context of the Reference component, for that run, are passed as configuration data. From then on the post-customized submodel is run when the Reference component is run.

  • Every time this reference runs. The submodel copy is fetched and customized every time the associated Reference component is to be run; the parameters of the runtime context of the Reference component, for that run, are passed as configuration data. The post-customized submodel is then run and discarded.

These fetch options for published submodels are controlled by the Advanced setting in the Reference component that is configured to run it.



Advanced users of published models should be aware of the following subtleties:

  • The names, types, modes, and structures of the parameters of the root component of a Reference component must be identical to the (non-Local) parameters of the root component of the referenced published submodel; otherwise, runtime parameter values cannot be transferred between the two components, so the job will not run. Therefore, if customization alters the parameters of the Reference component, it must alter those of the submodel root in exactly the same manner, and vice-versa.

  • In some applications, when a reference to a published submodel appears along a conditional branch of a component’s simulation process flow, it is possible that the published model will never be run by the current job. In that case you may save some time by marking the reference Just once when this reference first runs so that it will not be loaded (this applies regardless of whether the submodel must be customized).

  • When more than one Reference component in a model refers to a single published submodel, each Reference component that is set to prefetch will run a single, shared copy of the submodel during execution; each remaining Reference component will run a separate copy.

  • A post-customized copy of each prefetched submodel is sent back to the application that created the job along with the post-customized model (e.g., for display in the Runtime Gateway).

  • When a published submodel itself refers to a published sub-submodel, the above fetch modes are applied to all levels in a straightforward manner. For example, when a Just once when this reference first runs submodel refers to a Just once before the model runs sub-submodel, a separate copy of the sub-submodel is fetched, customized, and used at runtime for each separate copy of the submodel.

  • A model that uses a published submodel will take longer to run using Just once before the model runs than when using the other fetch modes when the submodel must run more than once. When building a model, be sure your application actually requires this capability before you use it.