WUR-AI / WUR-AI/diffWOFOST

[Tasks]: Implement Data array organization inside Engine

Open
#25 2 comments 0 reactions 1 assignee View on GitHub

@fnattino is already working on this.

Since Nov 6, 2025.

Dominant language
Python
Stars
25
Forks
6
Avg merge
2d 23h
Merged PRs (30d)
1

Description

After merging https://github.com/WUR-AI/diffWOFOST/pull/12 , we want to change the data array organization inside the module, see https://github.com/WUR-AI/diffWOFOST/issues/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:

  1. usability
  2. scalability: improving input arguments: parameterprovider, weatherdataprovider, agromanagement. In parallel, we make sure that submodels can handle vectors for both parameters and weather data.
  3. efficiency: to check this, we need bigger data than current test data, check out pcse notebooks.
  4. readability/maintainability

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.