Skip to content
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

API : enable passing in a vector providing values per timestep in multi-scale modelling #117

Closed
Samuel-amap opened this issue Dec 16, 2024 · 1 comment · Fixed by #122
Closed
Labels
enhancement New feature or request

Comments

@Samuel-amap
Copy link
Collaborator

It's possible to provide a vector to the status in a ModelList simulation, which is convenient for quick testing, but currently not possible for a mapping.

One way of doing this would be to create a model before hard dependencies are parsed, and add it to the dependency graph. That model would provide the variable as output, relative to the current timestep.

Documentation would need to be very clear about how this is implemented and usage, as one needs to make sure the user understands this API quirk is unusual relative to other variable initialisations(relates to #93 ). Also, passing in such a model to a specific organ scale makes the per-timestep value constant for every instance of that organ, which is consistent with the ModelList world and makes sense (if the user wants it to be non-constant then they should use a custom model), but needs documenting.

Error reporting is likely to be confusing as well, without prior clarification that a model was implicitely created.

Note that it also currently isn't obvious how to access the current timestep, it might be worth adding it to the status, or to provide some means for the user to access it. Also note that the current way of doing it (through the meteo DataAPI) will likely need to be revamped when doing multi-timestep simulations (relates to #88 ).

@Samuel-amap Samuel-amap added the enhancement New feature or request label Dec 16, 2024
@Samuel-amap
Copy link
Collaborator Author

Another point worth bearing in mind : if ever we decide to generate a model on the fly to compute the current timestep, or some other model with a PSE-generated variable, there will be a risk of naming conflict with user-defined variables in other models.
Probably worth documenting how we name our generated variables to avoid confusion (and prefix them with something that makes sense, eg 'reserved', 'internal', ... that we could also use as filters for error-checking)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
1 participant