Automatic recursive initialisation
This functionality is due for release in version 0.9.8.
In ASCEND we write default_self METHODs to set any initial 'guess' values for variables that might otherwise not converge properly, or converge to an undesired value. Up to now, it was up to the user to ensure that all the nested sub-models in their model were correctly initialised, through the correct chaining-together of RUN statements.
Now there is some new code that deals with setting default values so that models can be returned to their as-loaded state correctly. The implementation starts with the default definition of METHOD on_load from models/basemodel.a4l:
METHOD on_load; RUN default_self; END on_load;
This in turn is defined as:
METHOD default_self; EXTERNAL defaultself_visit_childatoms(SELF); EXTERNAL defaultself_visit_submodels(SELF); (* overwrite ATOM defaults explicit nested code if needed *) RUN default; (* local overrides *) END default_self;
METHOD default; (* do nothing, user can over-write this *) END default;
The EXTERNAL code is actually the built-in code from ascend/packages/defaultall.c. The first function, defaultself_visit_childatoms returns the values of all locally-defined atoms to their 'default' value, as taken from the variable's type declaration (ATOM statement, for example see models/atoms.a4l. The second function, defaultself_visit_submodels runs the default_self on any sub-models of the top level model (and this then operates recursively down all the levels). Finally, the default is run, which by default does nothing. It is intended that, using this approach, the user can just write a METHOD default if there is anything in the model that needs to be initialised to anything other than its default value.
Using the above system, a composite model can be declared by assembling sub-models, and there is no need to manually declare any initialisation code for the top-level model; it will be defined automatically as above. This should be especially useful in the case of the canvas-based modeller for ASCEND, where the user expects this default behaviour to 'just happen'.
A problem with the above approach is that it mixes up the neatly divided specify, values and default_self earlier recommended. We are still working out how best to resolve that.
Some sample models showing this functionality are given in models/test/defaultall.