iLAMB tree generator capped at 24 years?

Land Surface
1

I’ve been using the NRI-supported iLAMB-tree-generator/CMOR-lite on some of our ESM1.6 pi_control and amip test runs. Back in May 2025 this part of the process worked and successfully created iLAMB ready datasets of 5,10, and 30 years length.

I have recently restarted benchmarking efforts (using more recent runs) and now the CMOR-lite part seems to max out at 24 years.

So specifically
>ilamb-tree-generator --datasets ./config_amip1.yml --ilamb_root $ILAMB_ROOT --merge
with config_amip1.yml of
datasets: - {mip: non-CMIP, institute: CSIRO, dataset: ACCESS-ESM1-6, project: CMIP6, path: /scratch/p66/rml599/access-esm/archive/test-amip-dev-amip-fd157d82, output_range: [001, 030]}
does create iLAMB ready data but with only 24 years. The amip output directory pointed to here includes data from years 000 through to 034 - this has also occurred with other simulations with much longer ranges.

I’ve definitely given sufficient wall time to my pbs.job (3 hours) script since we do get output and iLAMB results.

Any ideas/insight as to why and/or how to address?

3

Hi @RhaegarZeng,

Could you please have a look at this when you get a chance?

4

Let me take a look at the raw data first.

5

@RhaegarZeng Thanks - but please note that this 24 year feature isn’t specific to that data set. Working from /g/data/p73/archive/CMIP7/ACCESS-ESM1-6/spinup/AprilSpinUp-AprilSpinUp-56aae814 and /g/data/p73/archive/CMIP7/ACCESS-ESM1-6/spinup/JuneSpinUp-JuneSpinUp-bfaa9c5b also produced output at 24 years. Previously I have run on the April Spinup data and produced 30 year CMOR-lite files.

My tree generator output is in /g/data/p66/inh599/iLAMB/ILAMB_ROOT_ESM1_6 - for directories where there files _orig.nc, the _orig.nc are the files from the tree generator and the others are where I’ve shuffled time to be a common year (1979).

There is/was an additional quirk with the AMIP simulation data in that the time field (when looked at in a numpy/datetime object) looks different to that from the PI control runs. The AMIP format was like “1979-01-16T12:00:00.000000000” whereas the PI control format was like “0682-01-16 12:00:00”. I had thought this was also going to be an issue but my latest attempt to run iLAMB from these data seemed to work okay.

6

Thanks for sharing those @inh599, I’ll take a look as soon as I can. Apologies for the delayed response, I’m on sick leave today. I’ll get back to you once I’ve figured out the cause.

7

Hi, @inh599, I have just test the data stored in /g/data/p73/archive/CMIP7/ACCESS-ESM1-6/spinup/AprilSpinUp-AprilSpinUp-56aae814, /scratch/p66/rml599/access-esm/archive/test-amip-dev-amip-fd157d82, and /g/data/p73/archive/CMIP7/ACCESS-ESM1-6/spinup/JuneSpinUp-JuneSpinUp-bfaa9c5b. No errors occurred during the process, and the full time range was successfully merged.

I’m wondering if the issue might be related to the module version. I’m currently using conda/analysis3-25.06. Could you please check whether you were using an older version?

Thanks!