Attachment | Size |
---|---|
UnivariateTwinAnalysis20090925.R | 7.2 KB |
I thought that only matrices with changes (dropping/constraining parameters) have to be specified in a submodel [see line 62+ of attached script] , when the full model name is the first argument of the new mxModel command but somehow it doesn't seem to find the MZ.objective anymore. Is this a new bug? I thought this was working before.
hi hermine,
I think the problem is passing in the name of the model you want to use as a basis for the new model as a string: It is then treated as the name of a new model.
so
mxModel(oldMod, changes...)
not
mxModel("oldMod", changes...)
Using a monolithic supermodel (i.e., building the submodels inside the supermodel, instead of building them outside and then importing them into slots in a new supermodel makes updating harder.
Have a look at the current state of the trunk/demo/ twin examples now: They are restructured to decompose the shared and group-specific elements into seperate models, and then to update and combine these as needed in supermodels.
I attach a hack on the script you attached above as an example of this type of restructuring.
nb (from ?mxModel)
model This argument is either an MxModel object OR a string. If 'model' is an MxModel object, then all elements of that model are placed in the resulting MxModel object. If 'model' is a string, then a new model is created with the string as its name. If 'model' is either unspecified or 'model' is a named entity, data source, or MxPath object, then a new model is created.