This is a common case and there is no reason not to support it. It might be reused for analysis pipelines too and would therefore greatly enlarge the scope of xarray-simlab.
The proposition below is not as flexible as #52, but I don't know if #52 is a good idea.
In the xarray extension, providing clocks should be really optional (it is already optional in the API, but running a model without a clock coordinate raises an error).
We could add the .run() reserved method in process classes. For models with no explicit time loop, the following simulation stages would be available : initialize -> run -> finalize. Initialization and/or finalization might still be useful in that case too (e.g., allocate/clean resources), but it remains optional. However, run vs run_step / finalize_step should be mutually exclusive (we could raise if a process decorated class does implement both, and we could also check and raise if a model has processes that mix both).
In the xarray extension, output_vars may accept a list (in this case, it's nicer than a dictionary with all values set to None).
This is a common case and there is no reason not to support it. It might be reused for analysis pipelines too and would therefore greatly enlarge the scope of xarray-simlab.
The proposition below is not as flexible as #52, but I don't know if #52 is a good idea.
In the xarray extension, providing clocks should be really optional (it is already optional in the API, but running a model without a clock coordinate raises an error).
We could add the
.run()reserved method in process classes. For models with no explicit time loop, the following simulation stages would be available :initialize -> run -> finalize. Initialization and/or finalization might still be useful in that case too (e.g., allocate/clean resources), but it remains optional. However,runvsrun_step / finalize_stepshould be mutually exclusive (we could raise if a process decorated class does implement both, and we could also check and raise if a model has processes that mix both).In the xarray extension,
output_varsmay accept a list (in this case, it's nicer than a dictionary with all values set toNone).