Comments (7)
It isn't immediately obvious to me that the changes for the mip-cmor-tables use will break CMOR for use of other sets of MIP tables, but I can see that maintaining the tests using the tables may be a little more tricky, and the tests in this repository would benefit from some reorganisation/attention.
Regarding the different forthcoming releases, I'd recommend creating and maintaining a "release branch" for version 3.7 while development proceeds on main for v3.8. A fix to 3.7 can then be applied to the release branch and released, and then it can be cherry-picked into main while v3.8 is being prepared. Once v3.8 is ready create a v3.8_release
branch and any bug fixes to that version can proceed while developing v3.9.
The important thing with release branches is to ensure that a fix applied to the v3.7_release
branch is propagated to main
and other release branches if necessary. It is moderately straightforward to cherry-pick changes (providing changes to release branches are "squash and merge"'d) from one branch to another as long as the code has not diverged too far from the branch on which it is developed. It is also key that care is taken to try to keep a linear history within the repository as merges can interleave commits from one branch into another on merge
from cmor.
It isn't immediately obvious to me that the changes for the mip-cmor-tables use will break CMOR for use of other sets of MIP tables, but I can see that maintaining the tests using the tables may be a little more tricky, and the tests in this repository would benefit from some reorganisation/attention.
It's the formatting change strings to lists for dimensions
and modeling_realm
(e.g. CMIP6 Amon tas and MIP APmon tas) that breaks backward compatibility.
Of course, another option would be to reformat the cmip6-cmor-tables
to align with CMOR3.8, but that would need to be thought about.
from cmor.
It isn't immediately obvious to me that the changes for the mip-cmor-tables use will break CMOR for use of other sets of MIP tables, but I can see that maintaining the tests using the tables may be a little more tricky, and the tests in this repository would benefit from some reorganisation/attention.
It's the formatting change strings to lists for
dimensions
andmodeling_realm
(e.g. CMIP6 Amon tas and MIP APmon tas) that breaks backward compatibility.
I would have thought it possible to run the equivalent of the following python code for the dimensions
and modeling_realm
if isinstance(variable_entry['dimensions'], list):
dimensions = variable_entry['dimensions']
else:
dimensions = variable_entry['dimensions'].split(' ')
Of course, another option would be to reformat the
cmip6-cmor-tables
to align with CMOR3.8, but that would need to be thought about.
I wouldn't even consider this while CMIP6 is still operational
from cmor.
If the code that reads variable values from the tales encounters an array, then it will convert that array into a string.
Lines 215 to 233 in 10bb94a
Values for
dimensions
and modeling_realm
will get treated as a space-separated list in a string regardless of their format in the tables.from cmor.
@mauzey1 excellent, if I am reading (and interpreting this correctly) in then means that we can continue to use CMOR3.8 with the cmip6-cmor-tables, right?
from cmor.
Yes, CMOR 3.8 should still work with cmip6-cmor-tables.
from cmor.
@mauzey1 just circling around on this, and correcting the erroneous assumption that CMOR3.8/.9 was going to break backward (cmip6-cmor-tables) support, great.
Just trying to calibrate if anything is holding up the CMOR3.8 release, and if so, it'd be great to get any remaining issues identified so these can be resolved and CMOR3.8 can be released
from cmor.
Related Issues (20)
- Exposing latest netcdf 4.9.x library functionality: quantize, zstandard HOT 13
- Remove unused attributes when processing CMIP6Plus datasets HOT 14
- Exposing latest netcdf 4.9.x library functionality: quantize, zstandard HOT 48
- unclear warning... HOT 5
- bounds required on singleton lon and lat? HOT 5
- avoid attributes of bounds of auxilliary coordinates (`vertices_latitudes` / `vertices_longitude`) HOT 5
- CMOR 3.8.0 Release HOT 4
- Update README.md to remove v3.7 reference
- default `realm = "REALM"` is always written although not required by CV HOT 2
- order in `required_global_attributes` matters HOT 1
- input time type as INT HOT 3
- CircleCI current image deprecated HOT 1
- Numpy 2.0 compatibility issue HOT 2
- File output size and chunking HOT 10
- Message Logging generates duplicated output lines
- DESTDIR support HOT 2
- Failure invoking set_deflate HOT 1
- user defined grid mapping
- Add CITATION.cff file HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmor.