List of variables from PalMod CMOR table which are not yet added to mapping tables.

assigned to @k204212

changed the description

@k204227 Here the list of new standard_names, compared to CMIP6 v01.00.30 (I will keep this list up-to-date as we add more variables to the CMOR tables or edit the CMOR tables):

not in CMIP6 (but CF):

atmosphere_mass_content_of_methane
backscattering_ratio_in_air
effective_radius_of_cloud_liquid_water_particles
effective_radius_of_convective_cloud_ice_particles
mass_fraction_of_methane_in_air
mole_concentration_of_diazotrophic_phytoplankton_expressed_as_carbon_in_sea_water
reference_air_pressure_for_atmosphere_vertical_coordinate
tendency_of_atmosphere_mass_content_of_methane_due_to_emission
tendency_of_mole_concentration_of_particulate_organic_matter_expressed_as_carbon_in_sea_water_due_to_net_primary_production_by_diazotrophic_phytoplankton

not yet an official standard_name:

mole_concentration_of_dissolved_organic_13C_in_sea_water (similar to already existing mole_concentration_of_dissolved_inorganic_13C_in_sea_water)
surface_upward_mass_flux_of_methane_due_to_emission_from_fires
surface_upward_mass_flux_of_methane_due_to_emission_from_herbivores
surface_upward_mass_flux_of_methane_due_to_emission_from_termites
surface_net_upward_mass_flux_of_methane_due_to_soil_uptake
tendency_of_atmosphere_mass_content_of_methane_due_to_chemical_destruction

@k204227 @k204212 Can you please add variables 5-9,18-21 to the mapping table?

@m300792 I tried to find CMIP6 variables to what you are requesting. Please note down the differences if there are so we can go ahead and add the variables (alternative standard_names can be searched here if required):

usurf or surface topography (PISM) (CF surface_altitude TBC) - Link
temp_pa or ice temperature (PISM) - Link or Link
mask or Ice mask (PISM) - Link
ice_surf_temp (PISM) - Link
topg or bedrock surface elevation (PISM) (CF bedrock_altitude) - does not exist, please provide the information according to what information is given under the links for the varying variables
shelfbmassflux (CF land_ice_basal_specific_mass_balance_flux) - Link
thk or land ice shelf thickness (CF land_ice_thickness) - Link
temp or ocean potential temperature (TBC) - Link

@k204212 Thanks Martin! I think we have more look at the ISMIP variables. So I would use the following

usurf or surface topography (PISM) (CF surface_altitude TBC) - Link
temp_pa or ice temperature (PISM) - This is a 3D variable field of the ice temperature. ISMIP did not use it and I did not find it anywhere else. Can we create it?
mask or Ice mask (PISM) - This also does not exist. This is an integer mask with values 0,2,3,4 where the integers correspond to ice-free land, grounded ice, floating ice, ocean
topg or bedrock surface elevation (PISM) (CF bedrock_altitude) -
then we also need ocean salinity which is this quantity: However, while our ocean model writes this at every depth level, PISM uses an averaged value for ocean salinity and ocean potential temperature. So I think these need to be adjusted. All variables not listed here are good to go.

@m300792

temp_pa or ice temperature (PISM) - This is a 3D variable field of the ice temperature. ISMIP did not use it and I did not find it anywhere else. Can we create it? - I did not find any 3D variable related to sea or land ice in CMIP6. Could you give some information about the vertical axis please? Would it be similar to the soil depth in the jsbach/land model (certain number of layers with fixed depth in m)? There is just one vertical axis that is similar for antarctic and arctic and all 3d variables coming out of this model? It might be necessary to provide bounds for the vertical axis.
mask or Ice mask (PISM) - This also does not exist. This is an integer mask with values 0,2,3,4 where the integers correspond to ice-free land, grounded ice, floating ice, ocean - Such a variable can be created in two different ways:
- Combine all 4 masks into a single variable with additional character axis, as it is done for land variables like landCoverFrac. One then has for example the dimensions time lat lon typeice. typeice can then hold the values ice-free land, grounded ice, floating ice, ocean, and for each value a regular binary (0-1) mask would be provided.
- Same as above, but have all 4 masks as separate variables and not concatenated along a character axis.
ocean salinity - This would then be provided as a 3D variable on the PISM grid, like the temp_pa variable above?

@k204212

Apologies for the late reply, but I have been on holiday for the last few weeks.

temp_pa or ice temperature (PISM) - I did not find any 3D variable related to sea or land ice in CMIP6. Could you give some information about the vertical axis please? Would it be similar to the soil depth in the jsbach/land model (certain number of layers with fixed depth in m)? There is just one vertical axis that is similar for antarctic and arctic and all 3d variables coming out of this model? It might be necessary to provide bounds for the vertical axis. The vertical axis in the ice-sheet model is not related to the soil depth in the jsbach/land model. In our model configuration (for both hemispheres), it consists of 121 equally spaced layers in the vertical spanning the range from 0 to 6000 m. This means that each layer has a thickness of 50 m. This would be the same for all 3D variables. However, other modelling groups may have chosen different vertical as well as horizontal grid parameters.
mask or Ice mask (PISM) - I would be in favour of your first suggestion, meaning to combine it to have the dimensions time lat lon typeice
ocean salinity - This would then be provided as a 3D variable on the PISM grid, like the temp_pa variable above? I think the best way of doing this is to provide this as a 2d field which is on the same horizontal grid as the ice sheet model and if possible mention in the description that it is a mean between ~200 and ~400 m depth

@m300792 Is the "ocean salinity" related to the ocean as the name suggests or maybe to the sea ice, like in this variable: https://clipc-services.ceda.ac.uk/dreq/u/7113f7b2-faa7-11e6-bfb7-ac72891c3257.html

In the first case it would look like a very model specific variable (output of PISM, not the ocean model, also that specific averaging range), not really suitable for the ESGF (where the focus lies on model intercomparison). I do not know how to add this variable to the CMOR tables in a way that would allow it to be submitted by other models as well.

I think for your requested ocean potential temperature it is then the similar problem. In how far would this one be different from the MPIOM version of the variable?

I added the other variables to the CMOR tables, please have a close look and tell me if anything requires to be altered (frequency, standard_name, modeling realm, cell_methods, cell_measures, ...). Please ask if anything is unclear: LINK

LImon: orogIs, tsIs, sftgif, libmassbffl, tlIs, sftgiflIt
Emon: dtb
fx: dtb, sftgif
coordinates: isdepth (vertical axis of an ice sheet model)

A general question related to this variables: in CMIP6 it was distinguished between arctic and antarctic. Should this be the case here as well? Or can / shall the variables be provided globally. Also I was not so sure if we talk about only land ice or only sea ice or both.

@k204212

In the first case it would look like a very model specific variable (output of PISM, not the ocean model, also that specific averaging range), not really suitable for the ESGF (where the focus lies on model intercomparison). I do not know how to add this variable to the CMOR tables in a way that would allow it to be submitted by other models as well

OK in this case, I think it is enough to just standardise the corresponding ocean variables (sao,tho in the excel spreadsheet).

As for the added variables,

orogIs - frequency should be changed to decadal, the rest looks fine!
tsIs - frequency should be changed to decadal, the rest looks fine!
sftgif - I do not know what variable this is? This is not something we write from the ice-sheet model
libmassbffl - frequency again should be decadal, also the dimensions changed from lat/lon to xant/yant. We can provide both: either lat/lon or polar stereographic coordinates which correspond to xant/yant
tlIs - frequency should be decadal, the rest looks fine!
sftgiflIt - Is this the mask variable we discussed above? If so, frequency needs to be changed to decadal, then the variable is unitless, suggestion for long_name would be: long_name="Type of Land Ice", comment: Mask of land ice type (ice sheet, ice shelf, ocean,ice-free land).`
dtb - There the frequency should also be changed to decadal. Also why is this also in fx? At least in our simulations this always varies with time

A general question related to this variables: in CMIP6 it was distinguished between arctic and antarctic. Should this be the case here as well? Or can / shall the variables be provided globally. Also I was not so sure if we talk about only land ice or only sea ice or both.

This is a good point. You are right, arctic and antarctic should always be distinguished! The variables are not global! All variables I'm talking about is land ice only.
One additional variables that would be worth standardising would be the surface mass balance like HERE. Our frequency would again be decadal for this variable.

@m300792 I moved the variables to the dec table and added acabfIs. dtb_fx I added because I thought for model runs without Vilma someone might provide the time invariant field for this variable. sftgif is the land ice area fraction on the echam/jsbach grid.

So, shall I then create tables for Arctic and Antarctic? All of the above variables (beside dtb and sftgif) are provided separate for Arctic and Antarctic, or are there exceptions?

Whether we will use xant/yant / xgre/ygre or lat/lon we can make dependent on how both grids behave with cdo cmor, and in case that doesn't matter, we can choose whatever is more convenient for you to provide.

@k204212 I moved the variables to the dec table and added acabfIs. dtb_fx I added because I thought for model runs without Vilma someone might provide the time invariant field for this variable. Yes, I think this is indeed a good idea.

So, shall I then create tables for Arctic and Antarctic? All of the above variables (beside dtb and sftgif) are provided separate for Arctic and Antarctic, or are there exceptions? Yes, but inlcude dtb also into that list please.

Whether we will use xant/yant / xgre/ygre or lat/lon we can make dependent on how both grids behave with cdo cmor, and in case that doesn't matter, we can choose whatever is more convenient for you to provide. Sounds good to me.

@m300792 The CMOR tables have been updated and the new variables have been added to the online mapping table, so you can enter the mapping information. If you notice any problems in the variable descriptions, please let me know.

@k204212 I have now added the mapping information into the online mapping table

@m300792 Thank you for adding the mapping information. I updated the mapping information and scripts, however, the CMORization does not work so far, since there is an issue with cdo cmor or CMOR3. It fails setting up the axes for the projection when reformatting/rewriting the data. I will notify the colleague in charge of cdo cmor, who is however absent for a couple more weeks.

Meanwhile I have a question regarding the time axis: For which time interval the respective pism output files are valid? So for example, the first output file of the experiment is "pism_-25990.nc". The timestamp in the file says "-25989 January 1st 00:00". So is this file valid for "-25989 to -25980" or "-25990 to -25981" or which interval exactly? Also, there is no output file for the first decade of the experiment ("-26000"), unless "pism_-25990.nc" is meant to be valid for the interval "-26000 to 25991" with the time stamp being misleading.

@k204212 PISM computes in seconds, so the date that cdo sinfo or also ncview provide is always one year off. I don not know why. When you run a ncdump "pism_-25990.nc" | grep time, you will find that the time variable is in seconds. If you convert this to years by dividing through (365*86400), you should see that instead of -25989, it is -25990. Maybe the easiest way to fix this is to always add one year to the cdo output?

To your second question: If your time stamp is -25989 (or rather -25990), then this covers the period -26600--25990, because the output is always written at the last timestep of the run.

mentioned in issue #8

mentioned in issue #6 (closed)

@m300792

Maybe the easiest way to fix this is to always add one year to the cdo output?

We avoid negative time values completely by flipping the time axis, so instead from -26k to 0 it will run from 1 to 26k. At least this was what we agreed on with Marie for her data and we would like to keep it this way for all publications.

If your time stamp is -25989 (or rather -25990), then this covers the period -26600--25990, because the output is always written at the last timestep of the run.

Sth seems not right. So in the file tagged with "-25990" the interval "-25999 to -25990" is included (or "-26000 to -25991" or "-25998 to -25989")?

`Sth seems not right. So in the file tagged with "-25990" the interval "-25999 to -25990" is included (or "-26000 to -25991" or "-25998 to -25989")?

Apologies, this was indeed not correct. The interval goes from "-25999 to -25990" in that case.

@m300792 I have a (hopefully final) question regarding the mPISM time axis. While the remaining MPI-ESM time axis ranges from 26000 BP to 1 BP, mPISM's time axis ranges from 25999 BP to 0 BP (since there is no output file labeled "-26000" but just one "-25990" which includes "-25999 to -25990"). Is this correct?

@k204212 Yes, this is correct.

List of variables from PalMod CMOR table which are not yet added to mapping tables.

Designs

Child items ...

Activity

not in CMIP6 (but CF):

not yet an official standard_name: