More flexible soil temperature correction based on the difference between CRU and ICON model topography

[ChristianSteger]

These changes allow for a more flexible soil temperature correction with it_cl_type = 2.
With this change, the user chan provide an own lapse rate (t_lapse_rate) and temperature offset (t_offset) for the correction. At MeteoSwiss, we use t_lapse_rate = 0.006 K/m and t_offset = 1.0 K in the operational setting, which represent tuned values. A few further points (and questions):

• The correction is computed in extpar_cru_to_buffer.py, but for COSMO some part also seems to be computed in extpar_consistency_check.f90, which is a bit counter-intuitive, because I would expect that extpar_consistency_check.f90 only deals with consistency checks. However, as the COSMO part will anyway become obsolete at one point, this is not such a pressing issue.
• The impact of it_cl_type is very difficult to understand from the documentation (https://c2sm.github.io/extpar/user_manual/EXTPAR_User_Manual_5_14.pdf). The impact also seems to have somehow changed between COSMO and ICON. For ICON, the switch has the following effect:
  it_cl_type = 1: no lapse rate correction of soil temperature based on difference between CRU and ICON model topography
  it_cl_type = 2: lapse rate correction (lapse rate and additional temperature offset can be specified with t_lapse_rate and t_offset)
• I included two run script (extpar_mch.aster.sh and extpar_mch.aster_soiltemp_elev_cor.sh) to test the new parameters (extpar_mch.aster.sh is actually an update to make it work with the most recent EXTPAR version). However, I'm not sure if these run script should go in the final commit. Is it actually planned to maintain the run scripts in extpar/run_scripts/?

@stelliom: Finally, it would be very useful for us if we could generate our operational EXTPAR files via the Zonda web-interface. For this, it would be necessary to enable the two newly introduced parameters (t_lapse_rate and t_offset) in Zonda as well. Would that be possible?

[stelliom]

Hi @ChristianSteger ,

Thank you for these changes! Regarding your points:

• Yes, I agree with you. My guess is that extpar_cru_to_buffer was originally written in Fortran and then ported to Python, then probably because COSMO will become obsolete soon (as you also said) these sections were not moved into the Python code to avoid doing unnecessary work. But this is just a guess. Anyway, I would keep it like this for now and remove it together with other COSMO related code once a decision is taken.
• Mmh, not sure which part of the text you are referring to here. Would you mind pointing me to it in the new web-based documentation for EXTPAR. Anyway, if it's the description of it_cl_type you are referring to, I agree it's not very well formulated. As a side note: I would refrain from looking at the old LaTeX documentation, this is not updated anymore (or at least it shouldn't). I suggest looking at the web-based one (see previous link), which as far as I know was initially copied from the old one.
• To be honest, I was not told anything about these run scripts (or at least I don't remember), so I am discovering them now. I think Jonas was trying to transition to the Python EXTPAR wrapper (WrapExtpar.py), which is also what Zonda uses. In my opinion, we should try to slowly stop supporting these runscripts in favor of the new Zonda workflow, which aims at being more user-friendly and also accessible by external users. I would say, if Zonda already supports all the options that you require for your use cases, then we don't merge these new runscripts. Otherwise, we can merge them temporarily until Zonda can support it. Since now you are also a beta tester of Zonda, it would be great if you could test this during the testing session and provide us with a list of options/features that you require.

Yes, enabling those options in Zonda should not be a problem. However, I am not sure we can make it before the second wave of testing starts (14.04.2025)... It's a bit tight, because I will be on holidays next week and the one after as well. It will probably come with the next EXTPAR release, together with your other PRs. If you need this urgently I could try asking Michael if he can do it. Let me know.

[ChristianSteger]

Hi @stelliom,

Great, thanks for the detailed answer.

• Regarding it_cl_type, there I was referring to the description of this parameter in https://c2sm.github.io/extpar/user_manual/user_manual_06_namelist_input/, which states:
  "switch to choose between the new and fine (1) and the old and coarse over sea and the fine over land (2) raw data set. Note that the fine data set (1) is topographically corrected." I find this rather confusing - at least for ICON. For ICON, it seems that (1) does not include an additional topographic correction on the higher-resolution ICON topography but (2) does. This does not really align with the current description...
• About introducing the new parameters (t_lapse_rate and t_offset) to Zonda: No problem if they will only be included in a later version of Zonda
• And finally about the run scripts: I will check in the coming days if I'm able to generate our EXTPAR files with the Python wrapper / Zonda. However, it's maybe still useful go keep the MeteSwiss run script maintained for the coming few weeks/months until we completely switch to Zonda...