new gto chart support added to the engine #206
Merged
Conversation
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
This was referenced Sep 29, 2025
|
Is this v_originalRapidRun a clone of the rapidRunData, or just a pointer to? In the latter case, it doesn't necessarily add a lot of storage until you do at least 3 rapidRuns. |
|
Pointer |
…ta, and capped getPeakFeedin/Delivery() to 0 (never negative). adjusted everything in model accordingly. -> Now the getters do what they should do.
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.
For now I save the v_rapidRunData class of the initial run in every GC that has a p_detailedCompany (determined in the interface where the first headless run is called). This is then also stored as the v_originalRapidRun which is then never removed/changed again during the simulation.
This way it is possible to always create coops where the original GTO calculation is possible (if the selected companies support it at least).
For now, the entire v_rapidRunData class is stored (only for businesspark models and only for companies where owner is p_detailedCompany). This is a lot of additional stored data that is not used.
With that in mind, I was also considering maybe creating a 'light' rapidrundata version that only contains the balance flow electricity and some other needed parameters for the GTO chart.
However, I could also see the benefit of v_rapidRunData in its entirety so I am not sure on wanting to do that. For now I decided to go with the entire v_rapidRunData, as this is already supported and easy to implement. But: I would like to have a discussion with you guys about wheter we want to start creating/defining lighter v_rapidRunData classes for these purposes.