Forcing factors

[laurenebouaziz]

Added factors for precip and potential evaporation and additive for temperature to be able to run climate scenarios with the delta change method easily in Wflow (without duplicating the forcing file). @visr, we tested the changes and they seem to work fine, but could you perform a review of the changes? thanks!

[visr]

Isn't this already supported? https://deltares.github.io/Wflow.jl/dev/user_guide/step2_settings_file/#Modify-parameters

[input.vertical.precipitation]
netcdf.variable.name = "P"
scale = 1.5
offset = 0.5

[laurenebouaziz]

good question, for climate change we are using monthly grids of delta's for each forcing variable. so with the current PR we can add them as cyclic parameter: cyclic = [ "vertical.leaf_area_index","vertical.precip_factor","vertical.epot_factor","vertical.temp_add",] epot_factor = "delta_pr_CNRM-CM6-1_ssp585_far" where epot_factor in the netcdf has dimension (12) time, y, x. I don't think this can be done with the current implementation of modify parameter right?

[visr]

Ah indeed, that cannot be done using the modify parameters feature. Nice that you've been able to make it work this way. Do you think this will be used regularly? I'm wondering if this feature is worth including in the main branch. If we decide to include it, it would also need some documentation and tests.

This could also be used as an example that we work out in the docs of a custom run loop, which I mentioned also in https://github.com/Deltares/Wflow.jl/issues/162#issuecomment-921710968. In here: https://github.com/Deltares/Wflow.jl/blob/977a4d76b7c6f302204c029fbb57e21e94183933/src/Wflow.jl#L208-L212 If we add a bit of code between load_dynamic_input and update(model), there we can update any variable in any way we want, depending on the current time.

[laurenebouaziz]

actually I think this is a feature that we may want to use in other projects in which we run climate scenarios, so I think it would be good to include in the main. It will have the advantage that it can then also be ran with the (next) executable. With the custom run loop, it means that we run from Julia right? And I agree with you that we should then add some documentation and tests. Let me know what you think and I can have a look at documentation and tests.

[visr]

With the custom run loop, it means that we run from Julia right?

In principle yes. Though if executables are needed it is also possible create a branch on this repository with the custom changes to Wflow.run, that we wouldn't merge, but we can easily create executables from a branch.

[laurenebouaziz]

thanks for the review! I will try to also add documentation and unit test shortly.

[laurenebouaziz]

With the custom run loop, it means that we run from Julia right?

In principle yes. Though if executables are needed it is also possible create a branch on this repository with the custom changes to Wflow.run, that we wouldn't merge, but we can easily create executables from a branch.

thanks, good to know!

[visr]

Note that there are also 3 BMI tests that need to get updated for the new number of variables; https://github.com/Deltares/Wflow.jl/runs/7631174183?check_suite_focus=true#step:6:142

[verseve]

If we add a bit of code between load_dynamic_input and update(model), there we can update any variable in any way we want, depending on the current time.

I think this is a good idea for the proposed functionality. Although the implementation is probably more simple than what was done in the AXA project, I think it makes sense to pull this out the main Wflow functionality (also in case more complex changes are required at some point). Let's discuss further during one of the stand-ups @laurenebouaziz , @visr and @JoostBuitink ?

[verseve]

During the wflow stand-up today we did conclude that it is preferred to have this kind of functionality outside of the Wflow computational engine. @laurenebouaziz will save (fork) this branch (as project backup), and after that this branch can be removed.

@visr: what would be a good location to store these custom run functions, also in relation to building an exe (TeamCity)?

[visr]

what would be a good location to store these custom run functions, also in relation to building an exe (TeamCity)?

For building an exe the easiest is just to modify the main run function in a branch on this repository that is not for merging. We could add this to the docs with some examples of useful customizations.