After merging #12 , we want to change the data array organization inside the module, see #18. For now, focus only on part B and implement engine, which takes care of slicing data over time steps and passes it to each module. n_timestpes will be added to the input/output of the engine. The computations are time-dependent, and the parallelization (or batch processing) is done on other dimensions.
Requirements:
- The existing tests should pass.
- New tests should be implemented for vectorization.
- Documentation should be updated.
Note:
Read related issues #20, #21, #22, #23, #30, #60
Explanation:
Engine` handles the actual simulation of the combined soil- crop system and forwards the simulation in time. It can be used to run a simulation object (the whole wofost model or its sub models). Currently, there are are three scripts related to Engine:
pcse/base/engine.py: contains the base Engine class.pcse/engine.py: contains the main Engine class, responsible to pass data to simulation object (the whole wofost model or its sub models).diffwofost/physical_models/utils.py::EngineTestHelper: This is a helper to be able to run individual sub models because the main Engine class does not support "external states".
The main concerns with Engine:
- efficiency (computational costs): we want to check both memory and speed performance of the current Engine and see what are the bottle necks.
- usability: we want to use the Engine to run simulations of sub models, e.g. setting external states, updating parameters without re-initializing the whole engine, accepting model config as an object instead of a file, etc. This leads
removing EngineTestHelper. Also, Engine should be able to resume the simulation.
- scalability: currently the data is passed to Engine via three main input arguments:
parameterprovider, weatherdataprovider, agromanagement. These are all designed to handle the data of one location, one crop, and time slicing (one day) is done inside the Engine. We want to see how to change the data organization inside of each provider to handle multiple locations and time slicing outside of the Engine.
- readability/maintainability: we want to refactor the code to make it more readable and maintainable.
Implementation plan:
We might use several PR to address the above concerns step by step, considering time budget, start with important ones. As discussed, we follow this order:
- usability
- scalability: improving input arguments:
parameterprovider, weatherdataprovider, agromanagement. In parallel, we make sure that submodels can handle vectors for both parameters and weather data.
- efficiency: to check this, we need bigger data than current test data, check out pcse notebooks.
- readability/maintainability
After merging #12 , we want to change the data array organization inside the module, see #18. For now, focus only on part B and implement engine, which takes care of slicing data over time steps and passes it to each module.
n_timestpeswill be added to the input/output of the engine. The computations are time-dependent, and the parallelization (or batch processing) is done on other dimensions.Requirements:
Note:
Read related issues #20, #21, #22, #23, #30, #60
Explanation:
Engine` handles the actual simulation of the combined soil- crop system and forwards the simulation in time. It can be used to run a simulation object (the whole wofost model or its sub models). Currently, there are are three scripts related to Engine:
pcse/base/engine.py: contains the base Engine class.pcse/engine.py: contains the main Engine class, responsible to pass data to simulation object (the whole wofost model or its sub models).diffwofost/physical_models/utils.py::EngineTestHelper: This is a helper to be able to run individual sub models because the main Engine class does not support "external states".The main concerns with Engine:
removing
EngineTestHelper. Also, Engine should be able to resume the simulation.parameterprovider,weatherdataprovider,agromanagement. These are all designed to handle the data of one location, one crop, and time slicing (one day) is done inside the Engine. We want to see how to change the data organization inside of each provider to handle multiple locations and time slicing outside of the Engine.Implementation plan:
We might use several PR to address the above concerns step by step, considering time budget, start with important ones. As discussed, we follow this order:
parameterprovider,weatherdataprovider,agromanagement. In parallel, we make sure that submodels can handle vectors for both parameters and weather data.