[CMIP6 CMOR-ization & ESGF-publication] NorESM2-LM - historical ensemble member 1

[YanchunHe]

Full path to the case(s) of the experiment on NIRD

• /projects/NS9560K/noresm/cases/

experiment_id

• historical

model_id
NorESM2-LM

CASENAME(s) and years to be CMORized

• NHIST_f19_tn14_20190625 (1850-1949)
• NHIST_f19_tn14_20190710 (1950-2014)

Optional information

parent_experiment_id
piControl

parent_experiment_rip
r1i1p1f1

parent_time_units
e.g.,
'days since 0421-01-01'

branch_method
'Hybrid-restart from year 1661-01-01 of piControl',
update: 2023-june-26
'Hybrid-restart from year 1600-01-01 of piControl',

other information
(provide other information that might be useful)
Ensemble member 1 of historical

[YanchunHe]

cmorized with additional fields

data path

• /tos-project1/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical/r1i1p1f1/
• /projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/historical/v20191108/

version

• v20191108

sha256sum

• .r1i1p1f1.sha256sum_v20191108b

[monsieuralok]

@YanchunHe published

[YanchunHe]

cmorized new data version to fix bugs reported in issues: #109 #178 #179

data path

• /projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical
• /projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/historical

version

• v20200218

sha256sum
/projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

• .r1i1p1f1.sha256sum_v20200218
• .r2i1p1f1.sha256sum_v20200218
• .r3i1p1f1.sha256sum_v20200218

[monsieuralok]

@YanchunHe published

[YanchunHe]

(refer to X.Yao)
"The output datasets of NorESM2-LM might miss the snc (snd / snw) _LImon_NorESM2-LM_historical_r1i1p1f1_gn_199001-199912.nc data file."

[monsieuralok]

@YanchunHe besides snc (snd / snw), lwsnl, sootsn are also missing. What do we need to do?

[YanchunHe]

Then I will cmorize those variables, src, snd, snw, lwsnl, sootsn if they are available in model output, and then publish them.

[YanchunHe]

(quote, K. Zimmermann)

according to my attempts of downloading it from ESGF, it seems that the
variable (NorESM2-LM, historical, r1, Amon, pr) has data published only
from 1950 forward, missing the first 10 files with data from 1850 to 1950.

Do you know where (or when, or if) the missing data is available?

[YanchunHe]

Yes, pr, together with several others including ccb,cct, and hurs, are all missing between 1850 and 1949 as they are not directly available in the model output during this period.

However, the pr can be derived from other model output during this period.

Therefore, we can CMORize pr for 1850-1949 soon later and publish to ESGF. However, the others (ccb, cat and hurs) will not be available in the future as far as I know.

[YanchunHe]

These above-mentioned data are cmorized and can be published to ESGF.

• pr for 1850-1949 in v20190815b, for 1850-1949
• snc, snd, snw, lwsnl and sootsn in v20190917b, for 1990-1999

data path

• /projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical
• /projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/historical

version

• v20190815b
• v20190917b

sha256sum
/projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

• .r1i1p1f1.sha256sum_v20190815b
• .r1i1p1f1.sha256sum_v20190917b

Commits:

• 03c2805
• 311e923

[YanchunHe]

@monsieuralok Could you also report an erratum for the missing ccb,cct, and hurs during 1850-1949? thanks!

[monsieuralok]

@YanchunHe did it.

[YanchunHe]

Cmorized with additional iLAMB variables (#262), AERday zg500 (#263) and corrected fNup (#251).

They are ready to be published to ESGF.

data path

• /projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/historical/v20210203
• /projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

version

• v20210203

sha256sum
/projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

• .r1i1p1f1.sha256sum_v20210203

[oyvindseland]

Did you also cmorize ps as described in the request or is that already cmorized and can be published

[YanchunHe]

ps was previously cmorized in Amon, Emon or AERmon tables(s). Could you check if it is OK?

Otherwise, I don't think it needs to be cmorized again.

[oyvindseland]

i need 6hr ps. I actually found in 6hrLev even if it is a instantaneous variable

[oyvindseland]

conclusion: I have what I need for this request

[YanchunHe]

OK, that is good. Thanks!

[oyvindseland]

Sorry I have made a stupid mistake. I wanted the output on the native vertical grid not z levels. I though the Pt referred to instantaneous time and not the z-level. I see now that it should have been 6hrLev.
How should I proceeed. Just write the same in all ensemble members.

[oyvindseland]

It may be that this is enough for the end users so do need additional data for now.

[YanchunHe]

Hi Øyvind,

6hrLev is 6 hourly-averaged on 'atmosphere_hybrid_sigma_pressure_coordinate' if I understand correctly.

6hrPlevPt is 6 hourly-instantaneous on 27 'air pressure' levels.

None of them on purely 'z levels'.

It is not clear what do you need?

ps is only surface pressure, so nothing about 'levels' right?

ps is availabe in '6hrLev', 'AERmon', 'Amon', 'CFday', 'Emon', but not in '6hrPlevPt', as it is not a required variable in that table.

Could you explain a bit more? Thanks!

Yanchun

[oyvindseland]

The main story is that I misunderstood the classification, but see it now.
The person who asked about data could use both so the issue can be closed.
I noticed however earlier today that on ESG it looks like the subdomain 6hrPlevPt includes both. E.g. ua files are placed under the same searchdirectory, but the names of the files are different as they should be. It is split up as it should on the node itself so this looks a classification issue, not an error at the ESG nodes

[YanchunHe]

OK, that means the user can get what they need through for, e.g., 'ua' through the '6hrLev' on original 32 sigma-hybrid levels, which are already all available through ESGF. No further action is needed (but just need to publish the 'snowmxrat' as requested above).

[oyvindseland]

Good. Then I am just waiting for the publication

[monsieuralok]

@YanchunHe 2000-2010 data are missing for 6hrPlevPt.snowmxrat

[YanchunHe]

fixed, please proceed with publish. @monsieuralok

[monsieuralok]

@YanchunHe There seems to be wrong with date of files example in r1* 200001010600-201001010000; please can you check .r1i1p1f1.sha256sum_v20210908 and others :
r1i1p1f1/6hrPlevPt/snowmxrat/gn/v20210908/snowmxrat_6hrPlevPt_NorESM2-LM_historical_r1i1p1f1_gn_200001010600-201001010000.nc
r1i1p1f1/6hrPlevPt/snowmxrat/gn/v20210908/snowmxrat_6hrPlevPt_NorESM2-LM_historical_r1i1p1f1_gn_201001010600-201501010000.nc
r1i1p1f1/6hrPlevPt/snowmxrat/gn/v20210908/snowmxrat_6hrPlevPt_NorESM2-LM_historical_r1i1p1f1_gn_199001010600-200001010000.nc

[YanchunHe]

They should be right.

They are 6hourly data, so the time stamp just cover the next time slice.

So if this is not harmful for ESGF data publish/inquiry and download, please just go ahead with publish.

Thanks!

[monsieuralok]

I will check but, I have already published r2 and r3 as I noticed issue of missing file in r1. But, you have now changed all r1,r2 and r3. But, because of these timestamps data are not getting published. I will check again and update you.

[monsieuralok]

@YanchunHe this one is published. But r2 and r3 are published with old map files. Do we need to retract those? If data are same then, we do not need to retract.

[YanchunHe]

seems like all are published at ESGF, including year 2000-2010.

:

So I guess we can close this issue now? @monsieuralok

[monsieuralok]

@YanchunHe published

[YanchunHe]

Recmorize sftlf and sftgif related to issue #162
need to be published

data path

• /projects/NS9034K/CMIP6/.cmorout/NorESM2-LM/historical
• /projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

version

• v20191108

sha256sum
/projects/NS9034K/CMIP6/CMIP/NCC/NorESM2-LM/historical

• .r1i1p1f1.sha256sum_v20191108c

[monsieuralok]

@YanchunHe published

[YanchunHe]

I made small update here at the top of the threads.

The historical r1 is branched from 1600-01-01 from piControl, as it is set in the cmorization, and according to the email earlier in 2019 by Øyvind:

I think we agree but just to be sure.
The N1850_19_tn14_20190621 experiment had the branch start in 1596 the first 5 years was used as a technical test to check that it gave the same answer as N1850_f19_tn14_11062019 and it did so.

I set the piControl is the parent experiment of historical to comply with the convention of CMIP table (tables/CMIP6_CV.json).
There is no need of realignment of dates. Year 1600 is the branch point. N1850_f19_tn14_11062019 year 1600 is the same as N1850_19_tn14_20190621 year 1600, so the only adjustment needed is that pictrl start from model year 1600 of N1850_19_tn14_20190621.

No changes of startdate needed except if the ctrl should be defined as days since 1600-01-01

Øyvind

[oyvindseland]

Can confirm from check of case catalogue that historical ensemble number 1 of NorESM2-LM start at 1600-01-01.

[YanchunHe]

Thanks!