Update check%ranges type in cable.nml

[ccarouge]

Fixes #22

Needed for compatibility with CABLE/main branch.

[ccarouge]

I am not sure how to specify the version of benchcab and CABLE this is compatible with. And the same for the previous versions of bench_example. So far, we linked the version of bench_example to the version of benchcab but this shows the version of CABLE is important as well. But we aren't going to release CABLE versions very often.

Should we use the CABLE commit hash in a version tag?

[abhaasgoyal]

So for now, maybe in the commit description have the version of benchcab and the commit hash of CABLE that bench_example is compatible with (or if wanting more clarity instead of the SHA256 hash use git tag in CABLE with the appropriate name, which is not related to release).

In the future, we do need dependency management. The following files in bench_example, have I/O by the packages:

1. benchcab - reading config.yaml and creating namelist from the default one provided by adding names.
2. CABLE - reading default parameters namelist from bench_example, and parameters created by benchcab.

In the future, for bench_example we could have a optional config key which provides the semantic versions/tags for benchcab/CABLE, which are automatically checked when running bench_example. If no such key is provided, then the latest versions for benchcab and CABLE are checked. It could also be not in config.yaml and be a separate file like package.lock.

[ccarouge]

@abhaasgoyal thanks for the ideas. I'm wondering how to guide users through all this. A commit description is maybe too hidden.
For example, let's say someone branched out CABLE before the check%ranges changes and want to use benchcab. They need to use bench_example at the commit before the one for the merge of this PR. And that's a bit tricky to find.

Would it be better, i.e. easier on users, to have several versions of the namelist directory instead of updating the namelist file? We could have a version (not sure the format) in the directory name with a symbolic link of the latest version to a generic namelist name. Then, we tell to users to change the symlink to an older version of the namelist files if needed?

[abhaasgoyal]

I think the symlinks could create confusion since if the user were to compare 2 realisations which have namelist changes, they will have to specify patch according to the symlink either way (which would have different values and not reproducible without mentioning which symlink). They will also have to find the correct version to symlink to manually. I think we do need to make changes in benchcab / CABLE to make the solution work (outside the scope of this PR).

Maybe for namelists we can still have
(a) multiple folders
(b) git submodule (which I think is better for automated management)
based on versions of namelist files, and let benchcab decide which version of namelist to pickup. Some ways to pick it up:
(a) putting the version number via config (preferred since it's easier, but then multiple folders would be better for new users)
(b) finding a way to have dependency resolution between namelist and CABLE in an automated way. Some sort of package manager / spack maybe?

For now, maybe have different folders for namelist, along with a CHANGELOG in the parent folder of versions. We do tell users to symlink the versions as well. However, we should create an issue in benchab where instead of symlinking, users put the version namelist to use in config.yaml under a certain realisation.

[ccarouge]

For the moment, I've created version folders with a symlink to the latest folder.
I don't know if I want to make changes to benchcab or tell users that if their branch isn't compatible with the latest benchcab either at compilation or for running configurations, then they should merge the main branch in their branch first.

Edit: we'll need changes to benchcab to allow re-running older tests but these might be different than allowing running current tests with older versions.