Registration of synchronously coupled transient simulation of the last deglaciation with interactive ice sheets and solid earth dynamics

assigned to @k204227

changed the description

mentioned in issue #11

@k204212 I have now started to upload the corresponding data to the following directory: /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous At the moment, I have only uploaded the ice sheet data and the 2D atmosphere fields. I think, this will get us started. The above mentioned directory also contains a README file with information about the subruns and their corresponding simulation year. Please, let me know if you need anything else or have any questions or if I missed something.

mentioned in issue #6 (closed)

@m300792 I cmorised the 2x7 PISM variables (i.e. for ANT and NH) for 100 years of that simulation: /work/bk1192/k204212/palmod_CS/transient-deglaciation-interactive_r1i1p1f1-CR/archive/PalMod2

From pmo0016b the simulation years 2000-2099 (PISM -020990 to -020900) were cmorised as 5001-5100. I yet used the metadata of the transient-deglaciation-prescribed, so when you have a look, please ignore the global metadata in the files for now.

My questions in the following:

General
- When the HSM allows, you can retrieve the Vilma and echam/jsbach output. We have enough diskspace available.
- The jsbach input files are not available under the common path and in the Google Spreadsheet no other path is provided.
- Vilma output is not yet provided and is also not yet part of the CMOR tables and Variable Mapping, so there is some work to be done. Please see #11 where this is discussed. The open questions are: Should relative sea level be published for this simulation (see my last post with Uwes quoted comment in #11)? Should the topography and glacier mask replace the echam-variants, or should we publish them with new CMOR tables SLmon or similar, to make clear they come from Vilma (which I would recommend)? In this case the cell area would have to be published as well.
- I noticed that some PISM output is duplicated (the last year of pmo0016a is included in pmo0016b). This should not be a problem for the processing, it will then be only read from one of the directories, but just to make you aware.
Metadata related (see eg. ncdump -h /work/kd1292/ESGF_PalMod/PalMod2/MPI-M/MPI-ESM1-2-CR/transient-deglaciation-prescribed-glac1d/r1i1p1f1/Amon/tas/gn/v20230201/tas_Amon_MPI-ESM1-2-CR_transient-deglaciation-prescribed-glac1d_r1i1p1f1_gn_0000101-0010012.nc for the metadata used in the previous simulations):
- the new simulations will be published with the same source and source_id as the prescribed transient glaciation simulations. To account for the differences we set the source_type attribute to include SLM ISM. Is that ok? I think at least that this was the plan we set up in #14.
- Should the references change?
- What about the variant_label and variant_info? For the prescribed simulations we had different tuning states of the model. How is it here? Are they the same for the interactive simulations? If the variant_info of the prescribed simulations does not at all apply for the interactive simulations, I will just use whatever you provided in the Google Spreadsheet.
- You did not enter any parent experiment and there was no spinup phase. Is this correct? In this case the jsbach input data of the first simulation year must be included in the input data for pmo0016a.
- Can you please provide me with a path or link to the Vilma (visko.inp) metadata you want to include in the metadata? Usually I would put this information either into the references or the variant_info attribute.

@k204212 Thanks for your feedback. The initial cmorised PISM data looks fine to me. In reply to your questions:

When the HSM allows, you can retrieve the Vilma and echam/jsbach output. We have enough diskspace available.

I have now downloaded all the necessary output from echam/jsbach/mpiom and Vilma. You can find them under the experiment path mentioned above.

The jsbach input files are not available under the common path and in the Google Spreadsheet no other path is provided.

I have added the path to the jsbach input files to the Google Spreadsheet.

Vilma output is not yet provided and is also not yet part of the CMOR tables and Variable Mapping, so there is some work to be done. Please see #11 where this is discussed. The open questions are: Should relative sea level be published for this simulation (see my last post with Uwes quoted comment in #11)? Should the topography and glacier mask replace the echam-variants, or should we publish them with new CMOR tables SLmon or similar, to make clear they come from Vilma (which I would recommend)? In this case the cell area would have to be published as well.

So, we discussed this again and have come to the decision to publish the variable relative sea level for all of the simulation where Vilma is used. I put the corresponding output under: /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016[a,b,c,d]/outdata/vilma/vilma_-0?????/rsl.nc. As there is really no standard_name that fits the description, should we register a new variable? And how could that be done?
As for the glacier and land-sea mask. Here, we would like to take the glacier mask from jsbach (available from the input file) and the land-sea mask from jsbach (also available from the input file) and mpiom. These are not equivalent because both variables reside on different grids. The mpiom land-sea mask is available under: /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016[a,b,c,d]/outdata/mpiom/*slm*.nc. Because the masks only change every 10 years, I suggest SLdec as variable name

I noticed that some PISM output is duplicated (the last year of pmo0016a is included in pmo0016b). This should not be a problem for the processing, it will then be only read from one of the directories, but just to make you aware.

Yes, this is a consequence of us using the last year of say pmo0016a to initialise the first run in pmo0016b. If it is not problem for the processing, we would refrain from deleting duplicates manually.

the new simulations will be published with the same source and source_id as the prescribed transient glaciation simulations. To account for the differences we set the source_type attribute to include SLM ISM. Is that ok? I think at least that this was the plan we set up in #14.

I updated this information in the Google Spreadsheet. Source type should be AOGCM ISM SEM (for solid earth model). source and source_id should be unchanged.

What about the variant_label and variant_info? For the prescribed simulations we had different tuning states of the model. How is it here? Are they the same for the interactive simulations? If the variant_info of the prescribed simulations does not at all apply for the interactive simulations, I will just use whatever you provided in the Google Spreadsheet.

I updated the variant_label label for the current simulation. The situation is that we will have basically two ensembles with I believe 4 members that are based on two slightly different model versions. This means that we would like to start from r1i1p1f1 for each ensemble. Where would it be best to note the slightly different model version? In the source as MPI-ESM1-2-CRv1?

You did not enter any parent experiment and there was no spinup phase. Is this correct? In this case the jsbach input data of the first simulation year must be included in the input data for pmo0016a.

I have added this info to the spreadsheet now. There is a 1000a spin-up phase.

Can you please provide me with a path or link to the Vilma (visko.inp) metadata you want to include in the metadata? Usually I would put this information either into the references or the variant_info attribute.

I added the file to /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous. I think this metadata would be best put into the references

@m300792 Thank you for the update, I will take a look when time allows. Meanwhile I can give the following replies:

We can provide the jsbach and mpiom land sea masks without creating a new MIPtable, the mpiom land sea mask (sftof would be in Odec, the jsbach land sea mask (sftlf) in dec. Only glacier mask and orography on the vilma grid would require new MIP tables + variables.
If the relative sea level variable does not exist in the CMIP/CORDEX Data Requests we will have to come up with a variable description ourselves. If there is also no existing standard_name, one would have to be registered. The registration process takes several weeks to months, however (see. eg. https://github.com/cf-convention/discuss/issues/274 ). I would invite you to brainstorm the standard_name and description with the example of existing standard_name registration issues on github, and then initiate the registration (or wait for Swati/@k204227 to return and take over from there).
For a slightly varying model version, the physics version should be varied (the p in r1i1p1f1), and the differences in the model versions should be listed in the variant_info attribute. Concerning the source_ids and source descriptions, we had finished our discussion here: #14. I do not think we should start over with this discussion. It is necessary that the variant_labels will be compatible with the ones of the transient deglaciation runs: it is essential that a consistent assignment of physics_index be used across all simulations performed by a particular model. So if the model versions differ from the ones used for the transient deglacation p1 or p2, and thus p1 and p2 cannot be attributed to any of the ensembles, then p3 and p4 have to be used.

@k204212 Thanks for the update

We can provide the jsbach and mpiom land sea masks without creating a new MIPtable, the mpiom land sea mask (sftof would be in Odec, the jsbach land sea mask (sftlf) in dec. Only glacier mask and orography on the vilma grid would require new MIP tables + variables.

That is good to know and makes our life certainly easier in this regard.

If the relative sea level variable does not exist in the CMIP/CORDEX Data Requests we will have to come up with a variable description ourselves. If there is also no existing standard_name, one would have to be registered. The registration process takes several weeks to months, however (see. eg. https://github.com/cf-convention/discuss/issues/274 ). I would invite you to brainstorm the standard_name and description with the example of existing standard_name registration issues on github, and then initiate the registration (or wait for Swati/@k204227 to return and take over from there)

Yes, I will prepare everything and depending on how long it takes me, either proceed myself or wait for Swati

For a slightly varying model version, the physics version should be varied (the p in r1i1p1f1), and the differences in the model versions should be listed in the variant_info attribute. Concerning the source_ids and source descriptions, we had finished our discussion here: #14. I do not think we should start over with this discussion. It is necessary that the variant_labels will be compatible with the ones of the transient deglaciation runs: it is essential that a consistent assignment of physics_index be used across all simulations performed by a particular model. So if the model versions differ from the ones used for the transient deglacation p1 or p2, and thus p1 and p2 cannot be attributed to any of the ensembles, then p3 and p4 have to be used

OK. Happy to follow that procedure then.

Submitted issue to new CF standard name forum on 07.05.2024 based on Clemens"s write up for 1 variable (solid each model VILMA) at https://github.com/cf-convention/discuss/issues/311

The below proposed is a new standard name variable (relative sea level change) as a part of solid earth model VILMA, developed within the German paleo-climate initiative, Project PalMod (www.palmod.de)

Proposer's name: Swati Gehlot, DKRZ, Hamburg (technical description via Clemens Schannwell - clemens.schannwell@mpimet.mpg.de)

Date 2024-05-07

1. Relative sea-level change

Term: relative_sea_level_change

Description: The change in local mean sea level relative to the local solid surface, i.e. sea floor

Units: m

CMOR name: rslc

Hi @k204227 and @k204212,

as discussed at the PalMod meeting, here is a little time line of when we would roughly need the cmorisation of our deglaciation simulations. So we are relatively far advanced with our paper writing, such that I expect submission within the next month. Considering that on average the time for review is about 3 months, it would be good to have the runs cmorised in about 4 months time which would be mid/end of October 2024. In addition to the simulation that I have provided already, there will be seven more simulations that need to be cmorised by this date. However, the structure and variables between the simulations are identical which hopefully makes the cmorisation process a little easier.

@m300792 I took a look at the data, and there is an inconsistency in the naming of the files in restart/topo/: In the already processed simulations of Marie: (eg./work/mh0110/m211003/mpiesm-1.2.00p1/experiments/pmu0180a/restart/topo) topo_20880k glac_16020k.nc jsbach_T31GR30_11tiles_5layers_natural-veg_15700k.nc etc.

For pmo0016 (/work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016a/restart/topo/): GLAC_5179.nc TOPO_5179.nc jsbach_T31GR30_11tiles_5layers_natural-veg_5779.nc

This is problematic, because we cannot reuse the CMOR scripts 1:1 but have to rewrite parts of them. Considering the complexity regarding all the different time axes (and timestamps in filenames) you are using in this simulations, this is prone to errors and takes a lot of time. So, whenever possible, please try to avoid that.

I would also have some more questions:

the file visko.inp contains:

0.000000e+00    3.480000e+06    1.000000e+19    1.000000e+19
3.480000e+06    5.701000e+06    1.000000e+22    1.000000e+22
5.701000e+06    6.291000e+06    4.000000e+20    4.000000e+20
6.291000e+06    6.371000e+06    1.000000e+30    1.000000e+30

I am not sure how to add this series of numbers to the metadata. I think, we would first need some description what these numbers represent, and then we could decide whether to put them all in one global attribute (eg. comment, references, ...; including the description). Or put them in individual non-standard attributes, eg. vilma_<variable> = 3.48e+06

variant_label (r1i1p1f1): What physics_index should we set for this simulation? The CMIP6 DRS states: it is essential that a consistent assignment of physics_index be used across all simulations performed by a particular model. Apart from PISM and VILMA running, are there differences to Marie's model setups (parameterizations, ...)? If not, we need to use p1, p2 or p3 from Marie's model setups (whatever fits), else define a new p4.
The references are not filled in in the Spreadsheet. I shall use the same as for Marie's runs?
Just to confirm because the discussion here is long and a lot of time passed inbetween:
- I will cmorize pmo0016a-d as transient-deglaciation-interactive` ("synchronously coupled transient deglaciation with interactive ice sheets and solid earth").
- There are several new variables:
  - MPIOM decadal land sea mask: outdata/mpiom/*slm*.nc Update: This variable was calculated so far by sao/sao or sos/sos and I would like to keep it this way - apart from that, the variable in the mpiom *slm* files has monthly frequency (not decadal) - and the metadata say sea surface salinity?!
  - jsbach decadal land sea mask in restart/topo/*jsbach* (I think we submitted this before for Maries runs)
  - jsbach glacier mask in restart/topo/*jsbach* (I think we submitted this before for Maries runs)
  - relative sea level change (vilma output) in outdata/vilma/rsl* Update: the units is "m" - I assume I have to divide it by 10 to get m year-1 as requested by the new CF entry?!
  - topography (vilma grid) in restart/topo/TOPO*
  - glacier mask (vilma grid) in restart/topo/GLAC*
  - All changes can be seen here: 80efda1d
Update: I do not have read permissions for /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016d and /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016c

I took a look at the data, and there is an inconsistency in the naming of the files in restart/topo/: In the already processed simulations of Marie: (eg./work/mh0110/m211003/mpiesm-1.2.00p1/experiments/pmu0180a/restart/topo) topo_20880k glac_16020k.nc jsbach_T31GR30_11tiles_5layers_natural-veg_15700k.nc etc.

For pmo0016 (/work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016a/restart/topo/): GLAC_5179.nc TOPO_5179.nc jsbach_T31GR30_11tiles_5layers_natural-veg_5779.nc

This is problematic, because we cannot reuse the CMOR scripts 1:1 but have to rewrite parts of them. Considering the complexity regarding all the different time axes (and timestamps in filenames) you are using in this simulations, this is prone to errors and takes a lot of time. So, whenever possible, please try to avoid that.

That is true. This is a change that Uwe made as it significantly simplifies the bookkeeping of the various counters between the individual components of the coupled model.

I would also have some more questions:

the file visko.inp contains:

0.000000e+00    3.480000e+06    1.000000e+19    1.000000e+19
3.480000e+06    5.701000e+06    1.000000e+22    1.000000e+22
5.701000e+06    6.291000e+06    4.000000e+20    4.000000e+20
6.291000e+06    6.371000e+06    1.000000e+30    1.000000e+30

I am not sure how to add this series of numbers to the metadata. I think, we would first need some description what these numbers represent, and then we could decide whether to put them all in one global attribute (eg. comment, references, ...; including the description). Or put them in individual non-standard attributes, eg. vilma_<variable> = 3.48e+06

Yes, the visko.inp file is indeed not really self-explanatory. So the first and second columns show the distance in meters from the core of the Earth. The third and the fourth column show the same thing so that in fact we can delete column 4. They show the corresponding Earth viscosity for the depth range specified by columns 1 and 2. For example, we specify a viscosity of 1e19 Pa s from 0 meters to 3.48e6 meters from the core of the Earth. Then we move on to the next layer. This means that our viscosity structure of the Earth is piecewise constant. It also means that the last row goes from the Earth surface (6.371e6) to 80 km below the Earth surface (6.291e6), which I find a little counterintuitive, but this stems from the fact that the origin is defined as the core of the Earth.

variant_label (r1i1p1f1): What physics_index should we set for this simulation? The CMIP6 DRS states: it is essential that a consistent assignment of physics_index be used across all simulations performed by a particular model. Apart from PISM and VILMA running, are there differences to Marie's model setups (parameterizations, ...)? If not, we need to use p1, p2 or p3 from Marie's model setups (whatever fits), else define a new p4.

This is a completely different MPI-ESM to Marie's model (for example it now includes icebergs). Therefore, we would like to start a new numbering system here. This particular run should get the variant label (r1i1p4f1). There will be eight more simulations, seven of which with different p-values and one with a different f-value.

The references are not filled in in the Spreadsheet. I shall use the same as for Marie's runs?

This is true. The reason for this is because the reference will be the paper that we will publish alongside the data. I have added a note to the spreadsheet that the paper should shortly be out in discussion at climate of the past. However, the final reference should be to the published and peer-reviewed version of the manuscript.

Just to confirm because the discussion here is long and a lot of time passed inbetween:

I will cmorize pmo0016a-d as transient-deglaciation-interactive` ("synchronously coupled transient deglaciation with interactive ice sheets and solid earth"). Yes, this sounds good.
There are several new variables:
- MPIOM decadal land sea mask: outdata/mpiom/*slm*.nc Update: This variable was calculated so far by sao/sao or sos/sos and I would like to keep it this way - apart from that, the variable in the mpiom *slm* files has monthly frequency (not decadal) - and the metadata say sea surface salinity?! Yes, you can calculate this from these masked fields. The actual field is sea surface salinity, but the new variable should be the land-sea mask.
- jsbach decadal land sea mask in restart/topo/*jsbach* (I think we submitted this before for Maries runs) OK!
- jsbach glacier mask in restart/topo/*jsbach* (I think we submitted this before for Maries runs) OK!
- relative sea level change (vilma output) in outdata/vilma/rsl* Update: the units is "m" - I assume I have to divide it by 10 to get m year-1 as requested by the new CF entry?! This is a good point. Vilma does not output this natively. I added the processed relative sea level change to the vilma output directory under outdata/vilma/delta_rsl*
- topography (vilma grid) in restart/topo/TOPO* OK!
- glacier mask (vilma grid) in restart/topo/GLAC* OK!
- All changes can be seen here: 80efda1d

Update: I do not have read permissions for /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016d and /work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016c

I have modified the read permission so that you should have access now. If not, please let me know!

@m300792

Yes, the visko.inp file is indeed not really self-explanatory. So the first and second columns show the distance in meters from the core of the Earth. The third and the fourth column show the same thing so that in fact we can delete column 4. They show the corresponding Earth viscosity for the depth range specified by columns 1 and 2. For example, we specify a viscosity of 1e19 Pa s from 0 meters to 3.48e6 meters from the core of the Earth. Then we move on to the next layer. This means that our viscosity structure of the Earth is piecewise constant. It also means that the last row goes from the Earth surface (6.371e6) to 80 km below the Earth surface (6.291e6), which I find a little counterintuitive, but this stems from the fact that the origin is defined as the core of the Earth.

So one has 4 layers and a viscosity value for each. This could then be another time invariant variable with the only dimension being (height above earth core [if that exists in CF]), or a long comment in each file (hoping we don't exceed a character limit), e.g.:

"Earth viscosity configuration for the solid earth model VILMA. The viscosity is piecewise constant for specified layers of the earth: (1) 0 to 3.480000e+06 m from earth core: 1.000000e+19 Pa s. (2) 3.480000e+06 to 5.701000e+06 m from earth core: 1.000000e+22 Pa s. (3) 5.701000e+06 to 6.291000e+06 m from earth core: 4.000000e+20 Pa s. (4) 6.291000e+06 to 6.371000e+06 m from earth core: 1.000000e+30 Pa s."

This is a completely different MPI-ESM to Marie's model (for example it now includes icebergs).

If it is really a completely different ESM (and not just because VILMA and mPISM were running as well), then we should indeed register a new model version in the CV.

This is the actual registered version:

"MPI-ESM1-2-CR":{
                "activity_participation":[
                    "PalMod2",
                    "PMIP"
                ],
                "cohort":[
                    "Registered"
                ],
                "institution_id":[
                    "MPI-M"
                ],
                "source_id":"MPI-ESM1-2-CR",
                "source": "MPI-ESM1.2-CR (2017): \naerosol: none, prescribed Kinne (2010)\natmos: ECHAM6.3 (spectral T31; 96 x 48 longitude/latitude; 31 levels; top level 10 hPa)\natmosChem: none, prescribed\nland: JSBACH3.20, River Transport Model\nlandIce: none / mPISM 0.7 (10 km x 10 km (NH), 15 km x 15 km (SH), 121 levels)\nocean: MPIOM1.63 (bipolar GR3.0, approximately 300km; 122 x 101 longitude/latitude; 40 levels; top grid cell 0-15 m)\nocnBgchem: none, prescribed\nseaIce: unnamed (thermodynamic (Semtner zero-layer) dynamic (Hibler 79) sea ice model)\nsolidLand: none / VILMA-1D"
            },

What did change?

MPI-ESM1.2-CR (2017) ?
mPISM 0.7 ?
...

You would need to provide a new source description and a new source_id with updated version number, like eg.: MPI-ESM1-2-1-CR or MPI-ESM1-2-p08-CR

@k204212 Apologies for the late reply, but I have been on holiday.

So one has 4 layers and a viscosity value for each. This could then be another time invariant variable with the only dimension being (height above earth core [if that exists in CF]), or a long comment in each file (hoping we don't exceed a character limit)

I would be in favour of your long comment suggestion.

As for the name for the new Model version, we have decided as a group that the best name would be "MPI-ESM1.2.1-CR".

Please let me know if there is anything else we need to clear up.

@m300792 What would change in the source description? Should the release year be updated? Or the version of one of the components?

"MPI-ESM1-2-1-CR":{
                "activity_participation":[
                    "PalMod2",
                    "PMIP"
                ],
                "cohort":[
                    "Registered"
                ],
                "institution_id":[
                    "MPI-M"
                ],
                "source_id":"MPI-ESM1-2-1-CR",
                "source": "MPI-ESM1.2.1-CR (2017): \naerosol: none, prescribed Kinne (2010)\natmos: ECHAM6.3 (spectral T31; 96 x 48 longitude/latitude; 31 levels; top level 10 hPa)\natmosChem: none, prescribed\nland: JSBACH3.20, River Transport Model\nlandIce: none / mPISM 0.7 (10 km x 10 km (NH), 15 km x 15 km (SH), 121 levels)\nocean: MPIOM1.63 (bipolar GR3.0, approximately 300km; 122 x 101 longitude/latitude; 40 levels; top grid cell 0-15 m)\nocnBgchem: none, prescribed\nseaIce: unnamed (thermodynamic (Semtner zero-layer) dynamic (Hibler 79) sea ice model)\nsolidLand: none / VILMA-1D"
            },

Should the comment regarding the VILMA setup be changed or is it ok as it is:

"Earth viscosity configuration for the solid earth model VILMA. The viscosity is piecewise constant for specified layers of the earth: (1) 0 to 3.480000e+06 m from earth core: 1.000000e+19 Pa s. (2) 3.480000e+06 to 5.701000e+06 m from earth core: 1.000000e+22 Pa s. (3) 5.701000e+06 to 6.291000e+06 m from earth core: 4.000000e+20 Pa s. (4) 6.291000e+06 to 6.371000e+06 m from earth core: 1.000000e+30 Pa s."

@k204212 I think updating the source year would be the best. So we did most of the simulations in the year 2022, which I think would hence be most suitable.

As for the comment. It looks already pretty good. If we still have a few characters to spare. I would suggest to modify the second sentence to:

The vertical viscosity structure is piecewise constant for the following specified layers of the earth ...

@m300792 Under the following path, there are 100 years CMORized output for pmo0016a: /work/bk1192/k204212/palmod_CS/transient-deglaciation-interactive_r1i1p1f1-CR/PalMod2

Could you have a look please at the data and metadata?

In general it is a little "unclean", to publish both high resolution (topo, glac) and low resolution (rslc) data as part of vilma. For topo and glac we could specify some variable comment denoting why the data is provided on a higher resolution, can you provide such a comment please? The vilma (i.e. solid earth model) gridarea (fx_areacellsl) I set up to be calculated for the high resolution data. If you would rather like the gridarea of the low resolution grid to be published please let me know.

The references netCDF global attribute is yet missing (as substitute I set the references attribute of the prescribed simulations):

This is true. The reason for this is because the reference will be the paper that we will publish alongside the data. I have added a note to the spreadsheet that the paper should shortly be out in discussion at climate of the past. However, the final reference should be to the published and peer-reviewed version of the manuscript.

If the data needs to be published before the paper then we cannot set the new paper as references attribute (or only a preliminary version) else we need to wait until you can provide the citation info for the paper.

In the metadata I set an incorrect phyics_index/version (r1i1p4f1), this will be changed to p1.

Regarding the time axes:

jsbach/echam/mpiom, jsbach&vilma input: simulation years 5000-5099 have been standardized as 1-100
vilma / pism: simulation years -24999 to -24900 (i.e. files pism_-024990 to pism_-024900) have been standardized as 1-100 (decadal files are yet labeled 6-96, which is a CMOR problem for decadal frequency, and will be corrected)

The following variables cannot be created since the output is missing:

Amon: hurs, huss - codes 54, 55 not in echam stream
Ofx: thkcello, deptho, volcello - no stream mpiom_fx
Lmon: rh (heterotrophic respiration) - codes 143, 211 not in veg stream
SImon: sisnconc (% area of sea ice covered with snow) - sisnconc (code 1015) not in mpiom_data_2d_mm stream
EmonZ: sltbasin - global_sltbasin etc. (codes 1112-1114) not in data_moc_mm stream

@k204212 I have now had a look at the 100 years of cmorized output that you provided. I noticed the following:

I think I made a mistake in defining the variable libmassbffl. At the moment the conversion reads libmassbffl=bmelt*917*86400*365. However it should be: libmassbffl=bmelt*917 /(86400*365). This should be changed for both hemispheres (IdecAnt and IdecGre)
I also think that the variable sftgifIt is computed wrong at the moment. As far as I understand this gives the land_ice_area fraction. So for PISM, it should take the variable mask and wherever the mask is 2 or 3 it should be set to 100% and everywhere else it should be set to zero. I do not understand from the *mpism_PalMod2_recipes.json what is being done to create this field. Having said this, it is displayed correctly in the SLdec directory (variable sftgif in this case)
The rest looks OK to me!

Could you have a look please at the data and metadata?

Meta data looks good. I only noticed that for both IdecAnt and IdecGre the global attribute nominal resolution is set to 25 km. As written in the source it should rather be 10 km for IdecGre and 15 km for IdecAnt.

In general it is a little "unclean", to publish both high resolution (topo, glac) and low resolution (rslc) data as part of vilma. For topo and glac we could specify some variable comment denoting why the data is provided on a higher resolution, can you provide such a comment please? The vilma (i.e. solid earth model) gridarea (fx_areacellsl) I set up to be calculated for the high resolution data. If you would rather like the gridarea of the low resolution grid to be published please let me know.

In this case, it would be better to have the vilma gridarea be calculated from the low resolution data (e.g. rslc data) as this is the native grid of vilma. I believe, the interpolation onto the higher resolution grid is necessary because the bathymetry adjustment that we do is carried out on a much finer grid such that smaller scale features are still being resolved. I will check back with Uwe (who is currently away) and get back to you with a comment.

If the data needs to be published before the paper then we cannot set the new paper as references attribute (or only a preliminary version) else we need to wait until you can provide the citation info for the paper.

I updated the reference for the data in the google spreadsheet. However, in the end we would like to have the peer-reviewed publication as reference. I hope we can arrange that with the journal. How long would it take to change the reference in the cmorised data?

In the metadata I set an incorrect phyics_index/version (r1i1p4f1), this will be changed to p1.

I updated all the physics_index/version in the google spreadsheet, where I also added all the other simulations. So the label for the current simulation (pmo0016[a,b,c,d]) has changed anyway. I will also shortly start downloading the data for the other simulations until there is no more space on Levante.

The following variables cannot be created since the output is missing:

Amon: hurs, huss - codes 54, 55 not in echam stream

These variables are not present in the ECHAM6 version that we used for this set of simulations. But we would like to keep them around as they are present in our current model version.

Ofx: thkcello, deptho, volcello - no stream mpiom_fx

Unlike in normal CMIP6 simulation these variables change over time in our simulations. As indicated in the *mpiom_PalMod2_recipes.json, the variable thkcello is present in the file *_mpiom_data_3d_mm_DATE*.nc file. The variable depthois written as depto in _mpiom_data_2d_mm_DATE*. According to the recipe table the variable volcello is then computed as the product of deptho * areacello.

Lmon: rh (heterotrophic respiration) - codes 143, 211 not in veg stream

This variable is not present in the JSBACH version that we used for this set of simulations. But we would like to keep it around as it is present in our current model version.

SImon: sisnconc (% area of sea ice covered with snow) - sisnconc (code 1015) not in mpiom_data_2d_mm stream
EmonZ: sltbasin - global_sltbasin etc. (codes 1112-1114) not in data_moc_mm stream

sisnconc (code 1015) and sltbasin (codes 1112-1114) are not present in any of our model versions and hence will not be cmorised and can be discarded from the variable list.

@m300792 Thanks for the feedback

I think I made a mistake in defining the variable libmassbffl. At the moment the conversion reads libmassbffl=bmelt91786400365. However it should be: libmassbffl=bmelt917 /(86400*365). This should be changed for both hemispheres (IdecAnt and IdecGre)

I updated that in the scripts.

I also think that the variable sftgifIt is computed wrong at the moment. As far as I understand this gives the land_ice_area fraction. So for PISM, it should take the variable mask and wherever the mask is 2 or 3 it should be set to 100% and everywhere else it should be set to zero. I do not understand from the *mpism_PalMod2_recipes.json what is being done to create this field.

For this variable we set up a character dimension with area types as required by the CF conventions. The character axis has 4 entries: CHAR_AXIS_TYPELICE="ice_free_land","ice_sheet","floating_ice","ice_free_sea" these would correspond to ice free land (mask==0), grounded ice (mask==2), floating ice (mask==3), ocean (mask==4). Is this correct? A full list of area types can be found here: https://cfconventions.org/Data/area-type-table/current/build/area-type-table.html In the CMORized data the order of the character dimension was mixed up and some area types were not CF compliant, which I corrected.

I updated all the physics_index/version in the google spreadsheet, where I also added all the other simulations. So the label for the current simulation (pmo0016[a,b,c,d]) has changed anyway. I will also shortly start downloading the data for the other simulations until there is no more space on Levante.

I updated the scripts with p4f2 and the updated variant_info.

Meta data looks good. I only noticed that for both IdecAnt and IdecGre the global attribute nominal resolution is set to 25 km. As written in the source it should rather be 10 km for IdecGre and 15 km for IdecAnt.

If the source description includes this value, I would not worry too much about the nominal_resolution. nominal_resolution is an attribute from CMIP6, setting the closest value of model resolution in [km] from a discrete list of values. So in this case we could set both to "10 km"?

nominal resolution (km)
        0.5,
        1.0,
        2.5,
        5.0,
        10.0,
        25.0,
        50.0,
        100.0,
        250.0,
        500.0,
        1000.0,
        2500.0,
        5000.0,
        10000.0

In this case, it would be better to have the vilma gridarea be calculated from the low resolution data (e.g. rslc data) as this is the native grid of vilma. I believe, the interpolation onto the higher resolution grid is necessary because the bathymetry adjustment that we do is carried out on a much finer grid such that smaller scale features are still being resolved. I will check back with Uwe (who is currently away) and get back to you with a comment.

Ok, I will wait for the comment and then recreate the 100 cmorized years.

I updated the reference for the data in the google spreadsheet. However, in the end we would like to have the peer-reviewed publication as reference. I hope we can arrange that with the journal. How long would it take to change the reference in the cmorised data?

We have the options to wait for the final paper publication to set the citation information as reference attribute, or use the preliminary "in review" citation information if the data needs to be published prior the final paper publication. Once the data is published we cannot change the metadata without a full retraction and republication of all files, which is a full day's work for our colleague maintaining the ESGF (so it's possible to republish with updated references, but not much appreciated on our end). If the data will also be archived within the WDCC long term archive at some point, the final citation information could be added then. But I do not know if this is planned in PalMod.

@k204212 Thanks for getting back to me.

For this variable we set up a character dimension with area types as required by the CF conventions. The character axis has 4 entries: CHAR_AXIS_TYPELICE="ice_free_land","ice_sheet","floating_ice","ice_free_sea" these would correspond to ice free land (mask==0), grounded ice (mask==2), floating ice (mask==3), ocean (mask==4). Is this correct? A full list of area types can be found here: https://cfconventions.org/Data/area-type-table/current/build/area-type-table.html In the CMORized data the order of the character dimension was mixed up and some area types were not CF compliant, which I corrected.

Apologies, this is all correct. For some reason I did not realise that I could cycle through "type" in ncview.

If the source description includes this value, I would not worry too much about the nominal_resolution. nominal_resolution is an attribute from CMIP6, setting the closest value of model resolution in [km] from a discrete list of values. So in this case we could set both to "10 km"?

I see. Yes, I guess to be precise we should change this to 10km.

We have the options to wait for the final paper publication to set the citation information as reference attribute, or use the preliminary "in review" citation information if the data needs to be published prior the final paper publication. Once the data is published we cannot change the metadata without a full retraction and republication of all files, which is a full day's work for our colleague maintaining the ESGF (so it's possible to republish with updated references, but not much appreciated on our end). If the data will also be archived within the WDCC long term archive at some point, the final citation information could be added then. But I do not know if this is planned in PalMod.

I will have to discuss this with the rest of our group, what the best option is for this. But the goal is to have the "dois" listed in the data availability section, when it gets published. That said, we will not be able to provide a full paper citation (including doi) until it is published. I will inquire what the best way forward is and how other people have done this in the past. I will get back to you on that.

@m300792 The ESGF-publication does not come with a DOI. DOIs are only an option for a WDCC publication. So we can publish via the ESGF with the preliminary (in review) DOI of the paper in the netCDF metadata, and then publish the data additionally via WDCC. The WDCC metadata can then include the DOI of the published paper - the paper DOI can be added to the WDCC metadata even after the data DOI has been issued - but the files will remain unchanged.

The problem will be the timeline, since the data is not processed (or even on disk) yet and a WDCC publication takes some time as well, even though publishing ESGF published data via WDCC is comparably uncomplicated and quick (but still the tape system has to be accessed). Also I will be on a 4-week vacation in November/Dezember.

@k204212 OK. We have decided that we need a DOI for each of the simulations which means that we would like to publish this through the WDCC eventually. I have now started to retrieve all necessary data from the archive for the cmorisation of the other 7 simulations with the hope that we can push ahead. Is is a bit of work, but my expectation is that this will be finished within the next two weeks. My hope is that we can have these runs cmorised by the end of the year. Can we keep this issue open or should I open a new issue for each of the simulations?

As for the comment on the different resolutions for topo, glac, and rslc. My suggestion would be: "The higher resolution for the topography and glacier mask is required to account for smaller spatial-scale variations."

@m300792 The simulations are all registered in the spreadsheet so this issue should be sufficient.

I would alter the comment to something like:

"The topography and glacier mask are provided on a higher resolution grid than the other output parameters of the solid Earth model component to account for smaller spatial-scale variations."

Is that ok?

I will try to cmorize at least one of the model runs completely until my vacation in November, so they can be ESGF and WDCC published sooner, which will then also allow my colleagues to confirm the ESGF->WDCC publication workflow for PalMod (hopefully then making things faster for the remaining runs).

@k204212

"The topography and glacier mask are provided on a higher resolution grid than the other output parameters of the solid Earth model component to account for smaller spatial-scale variations."

Is that ok?

Yes, I am happy with that.

@m300792 I again created 100 years of cmorized output: /work/bk1192/k204212/palmod_CS/transient-deglaciation-interactive_r1i1p4f2-CR/PalMod2

Please have a quick look at whatever was not ok previously and also at the global attributes. When you give me your OK, I can start the full standardization process for this run.

@k204212 This looks OK to me. All of the comments I raised last time have been resolved and also the other data that I checked looked correct. So please go ahead and start a full standardization of the run.

@m300792 Thanks for getting back to me so quickly. Just in case it was you trying to access the recipes table via the WebGUI: there was a problem that has now been addressed.

@k204212 I was indeed. I just wanted to check one more time one of the mPISM variables. Thanks for fixing it.

@m300792 There is one problem regarding the VILMA model: The timeaxis (or timestamps for the output files) should be the same as for mPISM, correct? So, for pmo0016a, a timestamp of "-24990" would correspond to the jsbach/echam years 5000-5009 or absolute years -24999 to -24990 of the simulation. That would mean, that for the echam6/jsbach years 8990, mPISM/vilma output with timestamp "-21000" would have to be read. But the vilma output for that timestamp (/work/bk1192/WP1.1/MPIM_transient_deglaciation_synchronous/pmo0016a/outdata/vilma/vilma_-021000/delat_rsl.nc) does not exist. Same goes for the first and last files I would expect for pmo0016b-d.

@k204212 This should be fixed now. Only the first timestep (-26000) has no delta_rsl.nc as we would have to compute this partly from the asynchronous spinup. But this should not be a problem as we discard the first 1,000 years anyway, right?

@m300792 Yes, the first 1000 years are discarded. There are still some directories that do not include a delta_rsl.nc:

pmo0016b/outdata/vilma/vilma_-020990
pmo0016d/outdata/vilma/vilma_-007000
pmo0016d/outdata/vilma/vilma_-006990

Registration of synchronously coupled transient simulation of the last deglaciation with interactive ice sheets and solid earth dynamics

Designs

Child items ...

Activity