Otto,
There is something to your arguments and I am a bit unused (still) to thinking about before and after compilation - not being a software engineer myself... ;-)
To reframe what your are saying, let us simply assume, that I have an exectuable instance of a model and the user can enter a value that is used when the simulation is actually started. On the screen I would have to tell the user an "instance before his entry", that he is supposed to give say a rate in days, weeks, or months - because this is how the model is set up to calculate in the formulas. So, in Modelica lingo the time base of the model (i.e. the unit of time) would have to be of constant variability (e.g. set before the model is made an executable) and the entry of the user would be of parametric variability. Right?
Note: The other option (@Jan Brugard - as with time zones ;-) ) would be to have everything converted to some standard e.g. SI-units like seconds in the case of time. This being very unusual for SD ... I have not done it (yet).
Now, I am still confused about the following code (which is used at the top level of every model I set up with my library):
inner parameter TimeBases modelTimeBase = TimeBases.years "The model's time base";
inner constant String modelTimeBaseUnit = BusinessSimulation.Constants.timeBaseUnits[modelTimeBase];
inner parameter Time dt(unit = modelTimeBaseUnit) = 1 / 16 "Smallest possible interval of time for compatibility with conventional fixed-step System Dynamics models";
I am having an enumeration TimeBases (seconds, minutes, hours, ... ) which is used to choose the unit of time for the model (which then nicely works as a drop down menu). Even though the String modelTimeBaseUnit above is stated to be a constant, it seems to "inherit" the parametric variability of modelTimeBase.
In short: The above use of modelTimeBaseUnit to set the unit attribute inside the lower level components of models does cause an error also.
So, change the above variables to be constants? (or better stick to SI-units with scaling?)
Guido
PS:
Constants and parameters are very similar, but also have some differences (Section 3.11.2, page 99). Parameters are typically much more common in application models. When in doubt whether to use constant or parameter, use parameter, except when declaring a constant in a package/ library where constant is allowed but not parameter.
Fritzson, Peter. Principles of Object-Oriented Modeling and Simulation with Modelica 3.3: A Cyber-Physical Approach (Kindle-Positionen1795-1799). Wiley. Kindle-Version.
When in doubt ... After thinking about what you have written, I still believe that the user may well choose time and the unit of time as a parameter given a compiled model.
Most Modelica tools support resimulating a model without recompilation after changing a parameter, which usually makes the time waiting for results much shorter.
Fritzson, Peter. Principles of Object-Oriented Modeling and Simulation with Modelica 3.3: A Cyber-Physical Approach (Kindle-Positionen1785-1786). Wiley. Kindle-Version.
Everything in that model could be made to act upon that parametric choice (as with all other parameters also). Chosing the unit of time for giving rates could (and maybe should) well be a parameter of a model (the choice of time scale could be passed onto other components as an inner parameter). While I cannot simply "rescale" apples to be oranges, I can well do so for any unit of time. Where is the fault in my thinking?
