-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow parameter values to be provided after translation #2952
Comments
I could see how it could be handled within the current specification. You cannot simulate the model without the parameter-values, but you could translate it as a step before that (and then change parameters). |
Yes, that's the goal, but would all tools agree that such a model is valid given the current specification text? |
Separate issues: should only use start-value for parameter if explicitly set. Can then delay setting the parameter from translation until simulation. (No error.) |
Design meeting: Alternative design:
Some tools translate all models to FMUs, and one can't have parameters without a value in an FMU. |
In System Modeler we are currently trying to become strict about parameters with
fixed = true
and neither a declaration equation nor explicitstart
. Until now, this has only been treated with a warning, and the non-explicit value ofstart
has been used.What we find now is that some models can't be built, even though the parameters don't need to become evaluated. None of the alternatives for dealing with this appeals to us:
start
is just counter-acting the purpose of the rule that requires parameters to be defined. A warning will be issued, but there is a substantial risk that users won't pay attention. Also if the typical action to take would be to setstart
even though there's no good default to use, why not simply allow the non-explicitstart
to be used?start
has the same drawbacks, but is even worse as there won't even be a warning when translating the model without providing a sensible parameter value.To remedy the situation, one could allow tools to delay the requirement that all parameters with
fixed = true
have values. For example,would be legal as a simulation model, but it would be required that no value for
p
is assumed during translation, and tools must require that an explicit value forp
is provided at initialization.Can others also see how this would be useful, or am I missing a way to handle this within the constraints of the current specification?
The text was updated successfully, but these errors were encountered: