You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, run_simulation takes many arguments, including filenames, which are then loaded and used to run the simulation. This makes programmatic runs (i.e. optimization) more difficult and time consuming.
We are mixing concerns between interface and implementation. This leads to issues where there is no way to specify whether a value should be taken from the config, or calculated within the simulation. These side effects are difficult to track down and may cause misleading results for researchers.
Proposed solution
We need to be able to run the greenheart simulation in a more flexible way. The file handling and other configuration elements should be pulled out so that we may split the configuration/interface from the implementation. We have something similar in the Hopp -> HybridSimulation workflow, so we can use a similar pattern here:
GreenHeartConfig: dataclass responsible for the interface to run_simulation. The initialization logic can live on this class, or in some function like configure_simulation
run_simulation: will now take GreenHeartConfig as an argument
GreenHeartOutputs: dataclass that encapsulates relevant outputs
Within run_simulation, we can then utilize the config to determine whether fields should be calculated or user-specified.
Alternatives considered
Additional context
The text was updated successfully, but these errors were encountered:
greenheart input/output configs
Currently,
run_simulation
takes many arguments, including filenames, which are then loaded and used to run the simulation. This makes programmatic runs (i.e. optimization) more difficult and time consuming.We are mixing concerns between interface and implementation. This leads to issues where there is no way to specify whether a value should be taken from the config, or calculated within the simulation. These side effects are difficult to track down and may cause misleading results for researchers.
Proposed solution
We need to be able to run the greenheart simulation in a more flexible way. The file handling and other configuration elements should be pulled out so that we may split the configuration/interface from the implementation. We have something similar in the
Hopp
->HybridSimulation
workflow, so we can use a similar pattern here:GreenHeartConfig
: dataclass responsible for the interface torun_simulation
. The initialization logic can live on this class, or in some function likeconfigure_simulation
run_simulation
: will now takeGreenHeartConfig
as an argumentGreenHeartOutputs
: dataclass that encapsulates relevant outputsWithin run_simulation, we can then utilize the config to determine whether fields should be calculated or user-specified.
Alternatives considered
Additional context
The text was updated successfully, but these errors were encountered: