file suffix functionality on model tasks to allow more sensitivity experiments across the oggm workflow

[bearecinos]

Link to issue with workflow tutorial with different climate data sets OGGM/tutorials#113

Seems like you can set a suffix for certain tasks but that functionality is not carry out in upper level tasks e.g.
we have a file suffix here: mass_conservation_inversion(gdir, glen_a=None, fs=None, write=True,filesuffix='', water_level=None,t_lambda=None) But that passing argument does not follow to the inversion_tasks(gdirs, glen_a=None, fs=None, filter_inversion_output=True,add_to_log_file=True). Maybe this can be done but is not clear from the docs or the code.

[pat-schmitt]

Yes, adding filesuffix to all tasks is not so much of a problem. But for sensitivity studies of the whole workflow we also need to think of how to store the calibrated parameters (dynamics and mass-balance).

For mass-balance we can save different mb_calib.json files with a suffix. And add this to the mass_balance models as an option to read the data from a certain mb_calib file.

And for the dynamic parameters, we could add glen_a and fs as values to the inversions flowline object, and pass these values on to the final dynamic flowline objects (adding two new attributes). Then we can add an option to the run_tasks if we want to use the 'flowline-dynamic parameters' or use the values from params.cfg for the run.

And the user is responsible for using the right mass-balance parameters together with the right dynamic parameters, or we add some tests to check that both use the same filesuffix and raise an error which can be suppressed if wanted.

This would mean quite some changes in the oggm code base.

[fmaussion]

I have some code to do that - I'll get back to this issue soon.

[fmaussion]

related: #1678

[fmaussion]

Can we define a use case for this? I.e. a workflow that we could write as a tutorial, and address the problem at the same time (this would help the development).

For example, I just wrote https://oggm.org/tutorials/master/notebooks/tutorials/massbalance_perturbation.html (still in construction) which originated after a specific experiment was asked for a project.

Right now we just shuffle parameters without calibrating, which is fairly easier (although both should be possible).

I really like the calibs.json mechanism and I think it's better than whatever we are doing right now with the glen_a and fs parameters - we should use this more often.

Perhaps a brainstorming while Im in Edinburgh could be useful.