Merged
Conversation
Contributor
Benchmark Results (Julia v1.10)Time benchmarks
Memory benchmarks
|
Contributor
Benchmark Results (Julia v1)Time benchmarks
Memory benchmarks
|
…ishing) into their own files
document new multi-rate option
for multi-rate policies
for multi-rate policy
We now make a window as large as the largest consumer request (e.g. one consumer at 4h and one at 24 will produce a 24h window) instead of the full history.
multirate with classic status tracking (Dict) vs multirate with online export requests (Vector{OutputRequest})
forbid using multithreading / distributed computing when in multirate mode
add more tests for multirate
… need to dev the pkg)
Upgrade to MultiScaleTreeGraph v0.15.0
… scalar when the temporal cache path misses in multirate execution Added logic to read mapped_variables for each input. If mapping gives one unambiguous source (scale,var), inference now uses it directly. If mapping exists but is multi-source/self-mapped, generic same-name inference is skipped (to avoid wrong auto-bindings). Kept strict ambiguity error when truly ambiguous and no mapping hint resolves it.
Symbols cannot be copied
… and skips generic same-name inference when mapping already defines the input source:
Add more tests to check that output_policy trait is just a hint, and only used if needed, and that output_policy trait can be overwritten by the user, or complemented by the user. User-inputs always take priority. For example, if we need output var1 and var2 and they are both defined by the model trait as e.g. a sum integration, we use that, but if we also need a maximum value integration as var1_max, users can provide it too.
Fix issue with input bindings forcing multirate runtime.
Always prefer local status over other scales
…-timestep + better resolution (all models in same range = same range, model wth no hint = meteo rate)
Fix world age issues
improve the tutorial
improve the tutorial
Member
Author
|
Checks before merge:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces major improvements to PlantSimEngine’s architecture, documentation, and core interfaces to support upcoming features like multi-rate simulation, scoped model instances, and advanced scheduling policies.
Documentation enhancements:
AI_PACKAGE_SUMMARY.md) explaining PlantSimEngine’s architecture, data structures, dependency graph, multiscale mapping, MTG integration, execution flow, and known pain points.Core scaffolding for multi-rate and scoped simulation:
src/PlantSimEngine.jlfor multi-rate scaffolding (time/multirate.jl) and model specification (mtg/ModelSpec.jl). [1] [2]GraphSimulation struct extension:
GraphSimulationstruct to includemodel_specsandtemporal_statefields, enabling support for normalized model usage specifications and multi-rate temporal storage.These changes collectively prepare PlantSimEngine for more flexible and robust simulation workflows, including multi-rate execution and scoped modeling.
To do before merging:
multirate=trueargument torun!, because we will find de information in theModelMappinrun!and inGraphSimulation.GraphSimulationbe defined when buildingModelMapping? This is the case for theModelListroute so...output_policy) for defining a default transformation for integration if needed (but can still be modified by the user from theModelMapping). Thanks to this trait, we have less to write in theModelMapping.