CMIP6 data request: epfy, epfz, utendepfd, vtem, wtem about noresm2cmor HOT 28 CLOSED

Not prioritised in post-process in noresm2cmor due to overall CMOR work load.
But produce these quantity offline, and stored as like model output? Then noresm2cmor can CMOR them.

from noresm2cmor.

Yanchun: At any time, we can publish additional fields (thanks to that each field represents an individual dataset in CMIP6). Concerning the computational bottleneck, I will write to Sigma2 to address this.

from noresm2cmor.

Yes, I will first CMORize what has been supported, and more in the future. CMIP6 is indeed quite flexible with this!

from noresm2cmor.

Just a quick update on this. I got the scripts from NCAR running a while back, but as I've been struggling to find someone with more experience with these particular diagnostics to help me determine if the results look OK or not. But now I've found someone at UiO who can help me, so hopefully we will have more progress soon.

from noresm2cmor.

Good to know! good luck with this!

from noresm2cmor.

We have compared results from NorESM2-LM with results from CESM2, and it looks reasonable, so we believe that we are able to successfully compute the variables epfy, epfz, utendepfd, vtem, and wtem using the scripts from NCAR.

I'm running the scripts on the PAMIP experiments now and storing the five variables in model-output-like files in the following folder:
/projects/NS2345K/noresm/work/lisesg/Eliassen-Palm-diags/noresm/cases/

The script has already processed the case NFHISTnorpddmsbc_PAMIP_1p1_pdSST-pdSIC_mem1-25_f19_mg17_20190819. Please take a look and let me know if it will be possible to CMOR-ize this, or if I should change something related to the files or the path (or something else).

from noresm2cmor.

Good to hear this! I will first try to add support to the EdayZ table, and then test on your visual model output. I will keep you updated.

from noresm2cmor.

Sounds good! Just to be clear, we only have the available output to do the monthly fields (the EmonZ table) for these specific variables.

from noresm2cmor.

OK, thanks for the clarification!

from noresm2cmor.

I see these fields are defined on the 'ilev', instead of on 'lev', is this correct?

And as a result of that, the 'lev', 'hyam','hybm' are also not included in the output-like files. I can tweak the cmor tool to bypass reading 'lev' etc, but should confirm that epfy, etc are on ilev instead of lev?

from noresm2cmor.

The fields epfy etc are indeed defined on the ilev pressure levels. As you know, to compute epfy etc, first zonal-mean fields (VTHzm etc) are computed during the model run (in the ctem.F90 routine), and then epfy etc are computed from those as a post-processing step. The protocol for computing epfy etc dictates that the input fields should be interpolated to constant pressure levels that are close to the average model levels before any zonal- or temporal means are taken, so the interpolation to ilev is actually already done during the model run when the zonal-mean variables are computed (in the ctem.F90 routine).

from noresm2cmor.

I see, thanks!

from noresm2cmor.

I see there is significant difference between TS(time,lat,lon) and T(time, lev,lat,lon) if lev is the bottom level (i.e the last level, lev=32).

in the cmor tool, the bottom T is used while you have TS in the output-like netcdf file.

Wondering If it matters if I use TS to replace the bottom T.

from noresm2cmor.

Surface temperature TS (affected by surface boundary layer processes) is qualitatively very different from layer temperature T and in my opinion should therefore be not used for extrapolation into orography. If you replace bottom T with TS then you should make sure that it scientifically makes sense.

from noresm2cmor.

Thanks Ingo!

1, These fields now can be cmorized.

If the CMIP6 required target pressure level in above the pressure level of the model output, linear extrapolation is used; if the target pressure level is below the lowest model pressure level (i.e. like underground), no extrapolation is applied but set with missing values; if the target pressure levels are between the model pressure level, linear interpolation is also applied.

Therefore, no TS/T and orography data is used, thus not needed.

2, sample cmorized output are put under:
/scratch/yanchun/cmorout/NorESM2-LM/pdSST-pdSIC/v20190815/EmonZ

epfy_EmonZ_NorESM2-LM_pdSST-pdSIC_r1i1p1f1_gn_200006-200006.nc
epfy_EmonZ_NorESM2-LM_pdSST-pdSIC_r2i1p1f1_gn_200006-200006.nc
epfz_EmonZ_NorESM2-LM_pdSST-pdSIC_r1i1p1f1_gn_200006-200006.nc
epfz_EmonZ_NorESM2-LM_pdSST-pdSIC_r2i1p1f1_gn_200006-200006.nc
utendepfd_EmonZ_NorESM2-LM_pdSST-pdSIC_r1i1p1f1_gn_200006-200006.nc
utendepfd_EmonZ_NorESM2-LM_pdSST-pdSIC_r2i1p1f1_gn_200006-200006.nc
vtem_EmonZ_NorESM2-LM_pdSST-pdSIC_r1i1p1f1_gn_200006-200006.nc
vtem_EmonZ_NorESM2-LM_pdSST-pdSIC_r2i1p1f1_gn_200006-200006.nc
wtem_EmonZ_NorESM2-LM_pdSST-pdSIC_r1i1p1f1_gn_200006-200006.nc
wtem_EmonZ_NorESM2-LM_pdSST-pdSIC_r2i1p1f1_gn_200006-200006.nc

3, Sample figure of original model output (left) and cmorized (interpolated to plev39) figure (right):

please have a look if it is correct. @lisesg

commit: 93d775f

from noresm2cmor.

I had a look, and it seems like values are mostly missing below 700 hPa, so I'm wondering if something has gone wrong. Just a wiled guess from my side, but maybe it's associated with using 39 pressure levels (plev39), I'm not aware of any other CMOR-ized fields from NorESM that are outputted on 39 levels. A challenge with plev39 is that quite a lot of the upper pressure levels are above our model top. For PAMIP, it would be OK to exclude the levels that are above 1 hPa if they are causing problems. The PAMIP paper says that the EmonZ variables can be on a subset of plev39 for models that do not contain all the requested levels.

from noresm2cmor.

For those levels above the model levels, linear extrapolation is used.

If you think something is wrong, then I have to debug to see if the interpolation subroutine take those levels below 700 hpa are below the model's lowest levels.

Wondering what is the range of P(j,k)=hyai(k)*P0+hybi(k)*PS(j) ? if maximum of P(j,k) is smaller than 700 hpa... then all below 700hpa are regarded below ground and will be masked as missing.

from noresm2cmor.

I think maybe the problem is that the output in the files is a bit misleading. The zonally-averaged fields derived by the model (the *zm fields) are all interpolated to constant pressure surfaces that match the values in ilev during the model run, so these fields are not on hybrid levels. However, probably because the fields are stored in the h0 files along with all the other model output, the attributes of ilev cannot be changed to reflect this for these specific variables, so it's easy to get the impression that that the zonally-averaged variables are defined on the ilev hybrid levels, even though they are actually defined on the ilev pressure surfaces. The same problem goes for the files I created with the post-processed fields because I let epfy etc inherit dimensions and attributes from the raw model output. So the interpolation from ilev to plev39 is actually a pressure-to-pressure interpolation (not a hybrid-to-pressure) for these specific fields. I'm sorry this is so unclear from the files, I'll see if I can change the attributes of ilev.

from noresm2cmor.

I think maybe the problem is that the output in the files is a bit misleading. The zonally-averaged fields derived by the model (the *zm fields) are all interpolated to constant pressure surfaces that match the values in ilev during the model run, so these fields are not on hybrid levels. However, probably because the fields are stored in the h0 files along with all the other model output, the attributes of ilev cannot be changed to reflect this for these specific variables, so it's easy to get the impression that that the zonally-averaged variables are defined on the ilev hybrid levels, even though they are actually defined on the ilev pressure surfaces. The same problem goes for the files I created with the post-processed fields because I let epfy etc inherit dimensions and attributes from the raw model output. So the interpolation from ilev to plev39 is actually a pressure-to-pressure interpolation (not a hybrid-to-pressure) for these specific fields. I'm sorry this is so unclear from the files, I'll see if I can change the attributes of ilev.

I see the difference now. You have mentioned this in some of your replies, but I did not pay enough attention to it.

This is indeed quite misleading.

But I see that the values of ilev in your output-like files equals 1000*(hyai+hybi), therefore, the ilev is still the 'hybrid pressure levels' instead of your referred 'ilev pressure surfaces".

Currently, the pressure of each 'ilev' is calculated by P(j,k)=hyai(k)*P0+hybi(k)*PS(j), where j is latitude and k is level index.

According to your comments, we do not need to calculate P(j,k) but just use ilev(k) for all the j points of certain k level?

But as I mentioned above, currently, the value of ilev is the same as 1000*(hyai+hybi), so it still reflects the hybrid-pressure coordinates, rather than the pressure surfaces.

I am puzzled with this, and needed to be clear before I can proceed.

from noresm2cmor.

The whole point with hybrid coordinates is to account for spatially varying orography. For interpolation of precomputed zonal mean fields that do not require consideration of orography, I'd try to simply set all a coefficients to ilev/1000 and b coefficients to zero (surface pressure field does not matter then). Pressure coordinates is just a special case of hybrid coordinates...

from noresm2cmor.

OK, this looks like a good solution. I will try this.

from noresm2cmor.

I would be happy to update the files with the new hyai and hybi values if that is helpful.

from noresm2cmor.

Hi Lise, you don't need to do anything now for this. I can override the values of hyai and hybi in the cmor tool. I will let you know when I have done this.

from noresm2cmor.

Have fixed the hyai and hybi with new values, please see the cmorized files again to see if it look OK now.

from noresm2cmor.

Thanks Yanchun! I had a look at the files under /scratch/yanchun/cmorout/NorESM2-LM/pdSST-pdSIC/v20190815/ for member 2, and the results look much better now! I think the problem has been solved. :)

from noresm2cmor.

Sounds very good! I just tested on the member 2 this time, so that is OK.

Then I will use the current setting to cmorize the output-like EP-flux fields.

They will be available in the second-round cmorization of existing experiments with additionally-supported fields (will start soon in the coming days). You will be notified when this is done.

from noresm2cmor.

Excellent! Thanks again Yanchun! :)

Looking at the CMIP6 data request spreadsheet, these variables are also priority 1 for the DAMIP simulations, and now that we have things up and running, it would be nice to be able to provide CMOR-ized EP-flux fields for these experiments as well. I would be happy to do the post-processing to create the model-like files containing the EP-flux fields for the DAMIP experiments (and off course other experiments if there is interest). What do you think?

from noresm2cmor.

Yes, you can make the diagnostics for the DAMIP in addition to PAMIP experiments.

I am thinking about how to organise the workflow of redoing the cmorization for the existing experiments with additional fields. Maybe one just reopens the [cmor and ESGF publish request] issue and put the necessary information. I will contact with you later.

from noresm2cmor.