UofMD-landState-3-0: land use data set

[slm7826]

CMIP6Plus data set, v20241002: Time units
First off, I'd like to thank the authors of this data set for providing the data for examination and review.

One thing that bothers me a bit is the units of the time axis: In this data set it is set to “days since 0850-01-01 00:00:00”, in NOLEAP calendar. If taken on its face value, it would mean that the models need to apply land use every 365 days. GIven that the historical and future simulations are typically done using calendars other than "NOLEAP", it would result in significant shift in application dates with respect to the year boundaries.

I think CMIP6 data set used "years since ...", and this seems to be more logical choice in this case, clearly indicating that the data are annual. I know that CF conventions does not recommend [although does not prohibit] using "years" as time units, but perhaps in this case it is justified.

[slm7826]

CMIP6Plus data set, v20241002: Comparison of transition rates with CMIP6

Comparison of globally-integrated transition rates among different land use types showed some significant differences from CMIP6 data set, in particular fairly strange spiky character of the CMIP6Plus data. To illustrate, the figure below shows the transition to pasture (primf_to_pastr + primn_to_pastr + secdf_to_pastr + secdn_to_pastr + urban_to_pastr + c3ann_to_pastr + c4ann_to_pastr + c3per_to_pastr + c4per_to_pastr + c3nfx_to_pastr + range_to_pastr + pltns_to_pastr)

As evident, these transition rates -- and their time variability -- are much higher in CMIP6plus compared to CMIP6, starting around 1990. There are also significant strange spikes at the boundaries of the 1950 decade. The next figure shows transitions from pasture (pastr_to_secdf + pastr_to_secdn + pastr_to_urban + pastr_to_c3ann + pastr_to_c4ann + pastr_to_c3per + pastr_to_c4per + pastr_to_c3nfx + pastr_to_range + pastr_to_pltns) that shows the same spiky behavior, and significant increase of transition rates in later decades.

I would be grateful for comments on this change from earlier data set; in particular, the spikes at the beginning and the end of 1950 decade. Also, should we expect all transition rates to increase in the later decades in CMIP6plus data set compared to CMIP6?

[znichollscr]

Thanks for the feedback @slm7826

Re the time units:

The reason we changed this was that, with the "years since...", the data would not load cleanly with xarray. This is, arguably, a bug in xarray although it's not completely clearly because, as you say, "years since..." is not a cf-compliant unit. That said, writing a dataset that can't be read with such a standard tool seemed a terrible idea, so we switched the units.

If taken on its face value, it would mean that the models need to apply land use every 365 days

I think this is a misreading of the point of the calendars. The time bounds of the dataset make clear that the transitions happen between Jan 1 of year X and Jan 1 of year X + 1. The calendar just tells the user what calendar the data is in, and changing to another calendar is a trivial exercise given this state of the data (I don't think any calendar translator would do anything other than put this data on 1 Jan of every year, although I can see it is perhaps not totally unambiguous).

However, given your confusion, this is probably something we should include once we get our user guidance notes going (x-ref #118 (comment)). A line like the following may be enough to clarify, but please suggest any adjustments you would like, "The data is annual. We use a noleap calendar for simplicity and for cf-compliance. However, don't let that confuse you, in all calendars, the transitions should be applied between 1 Jan of year X and 1 Jan of year X + 1."

[slm7826]

Absolutely, and in general this would be true. However, for this instance, the change is trivial, just divide the time calendar by 365 and you're back to years so I don't think we need to spend any more brain power on this.

I would not trivialize the code changes changes necessary for such translations for many modeling centers without intimate knowledge of their code, nor the potential compatibility issues with the older data sets.

[znichollscr]

Just to check I understand, you're saying that writing a quick script to alter the time axis back to years isn't trivial? You can do that in an easy language (i.e. a language other than C/C++/Fortran) if you need, i.e. effectively create your own version of the file that is back in the previous format, then just use it and your code won't even know that the file on the ESGF was different.

[slm7826]

I was interpreting your suggestions as changing the models' codes to read the data with new time units directly.

If you propose to change time units in pre-processing to match the expectations of the existing models' code then I agree, that should be easy. On the other hand, why do it and force many CMIP7 participants to do their pre-processing if the time units in this data set can be simply made the same as in CMIP6?

Besides, I still think that "years since..." is a more logical choice for annual data of this nature.

[znichollscr]

I get all that. I can only repeat what I said previously to explain why we changed from CMIP6 (#141 (comment)) so I think we've reached the end of our circle.

[durack1]

Just stepping back a little. @slm7826 and @znichollscr wouldn't the aspirational goal be to have CF compliant, well oiled and formatted datasets that are as consistent with one another as possible? That would then mean that clunky once off code (calendar, time axis, grids etc) disappears.. And potentially code to could written and shared across groups..

I also feel uncomfortable about hacky time axis being defined with observed data, which is collected on a gregorian calendar, so why impose a non-reality calendar "noleap" when the data was recorded against a gregorian, including leap days..

There's a balance to usability, vs never-ending iteration for little gain, but just thought this perspective is useful, particularly as we are aspiring to "operational" and "sustainable" dataset delivery..

[durack1]

@lchini ping!