-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update check%ranges
type in cable.nml
#23
Conversation
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 Should we use the CABLE commit hash in a version tag? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
benchcab
- readingconfig.yaml
and creating namelist from the default one provided by adding names.CABLE
- reading default parameters namelist frombench_example
, and parameters created bybenchcab
.
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
.
@abhaasgoyal thanks for the ideas. I'm wondering how to guide users through all this. A commit description is maybe too hidden. 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 |
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 Maybe for namelists we can still have For now, maybe have different folders for namelist, along with a |
c16430b
to
4491a8f
Compare
4491a8f
to
ca3e009
Compare
For the moment, I've created version folders with a symlink to the latest folder. 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. |
944e715
to
4cf48c1
Compare
Fixes #22
Needed for compatibility with CABLE/main branch.