NaN values in YUPRMASS etc – in #9: CCLM

in #9: CCLM

<p> Dear colleagues, I have faced with a problem concerning NaN values in <span class="caps"> YUPRHUMI </span> and <span class="caps"> YUPRMASS </span> logs (attached, as a <span class="caps"> YUCHDAT </span> ). At first sight, I have started this run with the standard options from <span class="caps"> ERAI </span> nterim to 0.12 domain (for other 0.12 domain it worked correctly) – (cclm-SF_0.12.sh). However, my job finished successfully (slurm-553007.out), but the next nesting simulation (0.12 to 0.025) int2lm crashes (slurm-552588.out, <span class="caps"> INPUT </span> , <span class="caps"> OUTPUT </span> ). Moreover, the QV_S values are NaN in output of the base domain simulation (see the ‘aa’ file) – and perhaps it causes crash. Since, I have suggested any inconsistences of lan-, lana- parameters of water content, but it was to no avail. <br/> So, I suggest any simple causes, but can’t find it quickly and evidently… I will be very grateful to you for any hints in this case! Thanks! </p>

  @vladimirplatonov in #a69922c

<p> Dear colleagues, I have faced with a problem concerning NaN values in <span class="caps"> YUPRHUMI </span> and <span class="caps"> YUPRMASS </span> logs (attached, as a <span class="caps"> YUCHDAT </span> ). At first sight, I have started this run with the standard options from <span class="caps"> ERAI </span> nterim to 0.12 domain (for other 0.12 domain it worked correctly) – (cclm-SF_0.12.sh). However, my job finished successfully (slurm-553007.out), but the next nesting simulation (0.12 to 0.025) int2lm crashes (slurm-552588.out, <span class="caps"> INPUT </span> , <span class="caps"> OUTPUT </span> ). Moreover, the QV_S values are NaN in output of the base domain simulation (see the ‘aa’ file) – and perhaps it causes crash. Since, I have suggested any inconsistences of lan-, lana- parameters of water content, but it was to no avail. <br/> So, I suggest any simple causes, but can’t find it quickly and evidently… I will be very grateful to you for any hints in this case! Thanks! </p>

NaN values in YUPRMASS etc

VP wrote

Dear colleagues, I have faced with a problem concerning NaN values in YUPRHUMI and YUPRMASS logs (attached, as a YUCHDAT ). At first sight, I have started this run with the standard options from ERAI nterim to 0.12 domain (for other 0.12 domain it worked correctly) – (cclm-SF_0.12.sh). However, my job finished successfully (slurm-553007.out), but the next nesting simulation (0.12 to 0.025) int2lm crashes (slurm-552588.out, INPUT , OUTPUT ). Moreover, the QV_S values are NaN in output of the base domain simulation (see the ‘aa’ file) – and perhaps it causes crash. Since, I have suggested any inconsistences of lan-, lana- parameters of water content, but it was to no avail.
So, I suggest any simple causes, but can’t find it quickly and evidently… I will be very grateful to you for any hints in this case! Thanks!

View in channel
<p> Adhoc I see that you use <code> itype_gscp=4 </code> for the 0.12 simulation. I do not know if this namelist setting works for such a large grid width (always) properly. At the German Weather Service they use <code> itype_gscp=4 </code> in the cosmo-de settings with 0.025 degrees grid width. For cosmo-eu (0.0675 degrees grid width) they use <code> itype_gscp=3 </code> . The standard setup for a <span class="caps"> CCLM </span> simulations at 0.11 is also <code> itype_gscp=3 </code> . Does your 0.12 simulation run with these standard settings or does it also crash? </p>

  @burkhardtrockel in #856b7f0

<p> Adhoc I see that you use <code> itype_gscp=4 </code> for the 0.12 simulation. I do not know if this namelist setting works for such a large grid width (always) properly. At the German Weather Service they use <code> itype_gscp=4 </code> in the cosmo-de settings with 0.025 degrees grid width. For cosmo-eu (0.0675 degrees grid width) they use <code> itype_gscp=3 </code> . The standard setup for a <span class="caps"> CCLM </span> simulations at 0.11 is also <code> itype_gscp=3 </code> . Does your 0.12 simulation run with these standard settings or does it also crash? </p>
BR replied

Adhoc I see that you use itype_gscp=4 for the 0.12 simulation. I do not know if this namelist setting works for such a large grid width (always) properly. At the German Weather Service they use itype_gscp=4 in the cosmo-de settings with 0.025 degrees grid width. For cosmo-eu (0.0675 degrees grid width) they use itype_gscp=3 . The standard setup for a CCLM simulations at 0.11 is also itype_gscp=3 . Does your 0.12 simulation run with these standard settings or does it also crash?

View in channel
<p> Dear Burkhardt, thanks for your hint. I have changed to itype_gscp=3. Unfortunately, there are no changes in YU* (attached). Maybe, cause is associated with some options of analyzing qi, qv etc. variables? <br/> Thank you for assistance. </p>

  @vladimirplatonov in #703a3e5

<p> Dear Burkhardt, thanks for your hint. I have changed to itype_gscp=3. Unfortunately, there are no changes in YU* (attached). Maybe, cause is associated with some options of analyzing qi, qv etc. variables? <br/> Thank you for assistance. </p>
VP replied

Dear Burkhardt, thanks for your hint. I have changed to itype_gscp=3. Unfortunately, there are no changes in YU* (attached). Maybe, cause is associated with some options of analyzing qi, qv etc. variables?
Thank you for assistance.

View in channel
<p> Can you provide the related <span class="caps"> YUSPECIF </span> file, too? Which versions of <span class="caps"> CCLM </span> and INT2LM do you use? </p>

  @burkhardtrockel in #0cf4487

<p> Can you provide the related <span class="caps"> YUSPECIF </span> file, too? Which versions of <span class="caps"> CCLM </span> and INT2LM do you use? </p>
BR replied

Can you provide the related YUSPECIF file, too? Which versions of CCLM and INT2LM do you use?

View in channel
<p> I’m attaching <span class="caps"> YUSPECIF </span> . I use int2lm_131101_2.00_clm4 and cosmo_131108_5.00_clm6 versions. </p>

  @vladimirplatonov in #6becb99

<p> I’m attaching <span class="caps"> YUSPECIF </span> . I use int2lm_131101_2.00_clm4 and cosmo_131108_5.00_clm6 versions. </p>
VP replied

I’m attaching YUSPECIF . I use int2lm_131101_2.00_clm4 and cosmo_131108_5.00_clm6 versions.

View in channel
<p> There are several differences to the 0.11 version I use, see the attached <span class="caps"> YUSPECIF </span> and compare it with yours. However, I have no idea, which of the differences in the namelist settings causes the problem. I assume that your input files created by INT2LM are ok? <br/> By the way, please change dt to dt=75. Hans-Jürgen found some problem in using dt=100 for 0.11. This may also apply to 0.12. However, that is likely not there reason for your program crash. </p>

  @burkhardtrockel in #4bac94a

<p> There are several differences to the 0.11 version I use, see the attached <span class="caps"> YUSPECIF </span> and compare it with yours. However, I have no idea, which of the differences in the namelist settings causes the problem. I assume that your input files created by INT2LM are ok? <br/> By the way, please change dt to dt=75. Hans-Jürgen found some problem in using dt=100 for 0.11. This may also apply to 0.12. However, that is likely not there reason for your program crash. </p>
BR replied

There are several differences to the 0.11 version I use, see the attached YUSPECIF and compare it with yours. However, I have no idea, which of the differences in the namelist settings causes the problem. I assume that your input files created by INT2LM are ok?
By the way, please change dt to dt=75. Hans-Jürgen found some problem in using dt=100 for 0.11. This may also apply to 0.12. However, that is likely not there reason for your program crash.

View in channel
<p> I have changed the most options to the suggested <span class="caps"> YUSPECIF </span> file except lana_qr_qs and llb_qr_qs – i have set it to <span class="caps"> FALSE </span> , because of crash (model couldn’t find QR and QS in files). Unfortunately, there are no general changes in YU* files (attached). <br/> Yes, it seemes int2lm went ok, so in lffd files there are no NaNs in QV_S etc. <br/> I have changed dt now and earlier, but it didn’t affect results. </p>

  @vladimirplatonov in #18e9e88

<p> I have changed the most options to the suggested <span class="caps"> YUSPECIF </span> file except lana_qr_qs and llb_qr_qs – i have set it to <span class="caps"> FALSE </span> , because of crash (model couldn’t find QR and QS in files). Unfortunately, there are no general changes in YU* files (attached). <br/> Yes, it seemes int2lm went ok, so in lffd files there are no NaNs in QV_S etc. <br/> I have changed dt now and earlier, but it didn’t affect results. </p>
VP replied

I have changed the most options to the suggested YUSPECIF file except lana_qr_qs and llb_qr_qs – i have set it to FALSE , because of crash (model couldn’t find QR and QS in files). Unfortunately, there are no general changes in YU* files (attached).
Yes, it seemes int2lm went ok, so in lffd files there are no NaNs in QV_S etc.
I have changed dt now and earlier, but it didn’t affect results.

View in channel
<p> I run a test on 0.12 for your San Francisco region with cosmo_131108_5.00_clm10. I encountered no problems. <br/> Please find the <span class="caps"> OUTPUT </span> and <span class="caps"> YUSPECIF </span> files attached. </p>

  @burkhardtrockel in #24080d2

<p> I run a test on 0.12 for your San Francisco region with cosmo_131108_5.00_clm10. I encountered no problems. <br/> Please find the <span class="caps"> OUTPUT </span> and <span class="caps"> YUSPECIF </span> files attached. </p>
BR replied

I run a test on 0.12 for your San Francisco region with cosmo_131108_5.00_clm10. I encountered no problems.
Please find the OUTPUT and YUSPECIF files attached.

View in channel
<p> Dear Burkhardt, thanks you a lot! I have changed the most of parameters as you have suggested. It is not finally clear, where was a problem, but it seems generally to be in lstomata option – I have changed it to <span class="caps"> FALSE </span> . Could you explain, could it be a reason and if yes, how it can affect on QV_S NaN values? <br/> Thank you very much! </p>

  @vladimirplatonov in #8eb92d6

<p> Dear Burkhardt, thanks you a lot! I have changed the most of parameters as you have suggested. It is not finally clear, where was a problem, but it seems generally to be in lstomata option – I have changed it to <span class="caps"> FALSE </span> . Could you explain, could it be a reason and if yes, how it can affect on QV_S NaN values? <br/> Thank you very much! </p>
VP replied

Dear Burkhardt, thanks you a lot! I have changed the most of parameters as you have suggested. It is not finally clear, where was a problem, but it seems generally to be in lstomata option – I have changed it to FALSE . Could you explain, could it be a reason and if yes, how it can affect on QV_S NaN values?
Thank you very much!

View in channel
<p> Dear Vladimir, dear Burkhadt, </p> <p> the lstomata paramater is related to variable <a href=""> <span class="caps"> RSMIN </span> </a> INT2LM: “RSMIN” &gt; prs_min_lm, see "src_gribtabs.f90" CCLM: "RSMIN" &gt; rsmin2d, see “src_setup_vartab.f90” </p> <p> In both codes the sea-land-dependency-flag “l” is set, see the aformementioned modules. </p> <p> In INT2LM, “prs_min_lm” is initialized with the value “zero”, and obviously also above water bodies where it is not used. <br/> Question: might it be possible that the sea-land-dependency of <span class="caps"> RSMIN </span> is not taken into account coorectly in <span class="caps"> CCLM </span> ? </p> <p> I only found one place in the code (module src_soil_multlay.f90, abount line 2382) where <span class="caps"> RSMIN </span> (=rsmin2d) is used if lstomate=.TRUE., <br/> and there we have it in the denominator of an expression; division by zero might lead to NaN. </p> <p> However, the expression is excecuted only <br/> - IF (lstomata) THEN <br/> and <br/> - IF (llandmask(i,j)) <span class="caps"> THEN </span> ! land points only </p> <p> and two further conditions. </p> <p> Vladimir, you should check the distribution and values of <span class="caps"> RSMIN </span> in your laf-file of your 0.12 simulation. <br/> It must not be equal to zero at any gridpoint over land </p> <p> Hans-Juergen </p>

  @hans-jürgenpanitz in #895020e

<p> Dear Vladimir, dear Burkhadt, </p> <p> the lstomata paramater is related to variable <a href=""> <span class="caps"> RSMIN </span> </a> INT2LM: “RSMIN” &gt; prs_min_lm, see "src_gribtabs.f90" CCLM: "RSMIN" &gt; rsmin2d, see “src_setup_vartab.f90” </p> <p> In both codes the sea-land-dependency-flag “l” is set, see the aformementioned modules. </p> <p> In INT2LM, “prs_min_lm” is initialized with the value “zero”, and obviously also above water bodies where it is not used. <br/> Question: might it be possible that the sea-land-dependency of <span class="caps"> RSMIN </span> is not taken into account coorectly in <span class="caps"> CCLM </span> ? </p> <p> I only found one place in the code (module src_soil_multlay.f90, abount line 2382) where <span class="caps"> RSMIN </span> (=rsmin2d) is used if lstomate=.TRUE., <br/> and there we have it in the denominator of an expression; division by zero might lead to NaN. </p> <p> However, the expression is excecuted only <br/> - IF (lstomata) THEN <br/> and <br/> - IF (llandmask(i,j)) <span class="caps"> THEN </span> ! land points only </p> <p> and two further conditions. </p> <p> Vladimir, you should check the distribution and values of <span class="caps"> RSMIN </span> in your laf-file of your 0.12 simulation. <br/> It must not be equal to zero at any gridpoint over land </p> <p> Hans-Juergen </p>
HP replied

Dear Vladimir, dear Burkhadt,

the lstomata paramater is related to variable RSMIN INT2LM: “RSMIN” > prs_min_lm, see "src_gribtabs.f90" CCLM: "RSMIN" > rsmin2d, see “src_setup_vartab.f90”

In both codes the sea-land-dependency-flag “l” is set, see the aformementioned modules.

In INT2LM, “prs_min_lm” is initialized with the value “zero”, and obviously also above water bodies where it is not used.
Question: might it be possible that the sea-land-dependency of RSMIN is not taken into account coorectly in CCLM ?

I only found one place in the code (module src_soil_multlay.f90, abount line 2382) where RSMIN (=rsmin2d) is used if lstomate=.TRUE.,
and there we have it in the denominator of an expression; division by zero might lead to NaN.

However, the expression is excecuted only
- IF (lstomata) THEN
and
- IF (llandmask(i,j)) THEN ! land points only

and two further conditions.

Vladimir, you should check the distribution and values of RSMIN in your laf-file of your 0.12 simulation.
It must not be equal to zero at any gridpoint over land

Hans-Juergen

View in channel
<p> Dear Hans-Juergen, thanks a lot for your broad hint. I have forgotten to mark out in my previous message, that my run had finished successfully. :) <br/> As for <span class="caps"> RSMIN </span> , I didn’t find it in my laf-file of 0.12 simulation, evidently because of lstomata=.FALSE., isn’t it? </p>

  @vladimirplatonov in #8a349dc

<p> Dear Hans-Juergen, thanks a lot for your broad hint. I have forgotten to mark out in my previous message, that my run had finished successfully. :) <br/> As for <span class="caps"> RSMIN </span> , I didn’t find it in my laf-file of 0.12 simulation, evidently because of lstomata=.FALSE., isn’t it? </p>
VP replied

Dear Hans-Juergen, thanks a lot for your broad hint. I have forgotten to mark out in my previous message, that my run had finished successfully. :)
As for RSMIN , I didn’t find it in my laf-file of 0.12 simulation, evidently because of lstomata=.FALSE., isn’t it?

View in channel
<p> Dear Vladimir, </p> <p> now I am a little bit confused. </p> <p> I looked into the files you provided with your very first contribution. </p> <p> File cclm_SF_0.12.sh shows the settings of your 0.12 degree simulation, right? <br/> And it contains “lstomata=.TRUE”. <br/> The file <span class="caps"> YUCHKDAT </span> also belongs to this 0.12 degree simulation, doesn’t it? </p> <p> In this <span class="caps"> YUCHKDAT </span> file I see the at the very beginning the checks for the laf-file <br/> /mnt/scratch/users/vplatonov/COSMO- <span class="caps"> CLM </span> /EXPERIMENTS/SanFrancisco/LM_Jan/laf2017011500.nc </p> <p> which contains a <span class="caps"> RSMIN </span> -field. </p> <p> If you now, in a new 0.122 degree <span class="caps"> CCLM </span> run, put lstomata=.FALSE., then <span class="caps"> RSMIN </span> is still in your laf-file, provided you did not re-run INT2LM with lstomata=.FALSE., <br/> but the <span class="caps"> RSMIN </span> field is not read by <span class="caps"> CCLM </span> and the values would not appear in the <span class="caps"> YUCHKDAT </span> file of the new <span class="caps"> CCLM </span> run. </p> <p> And I have furhter hints, which I forgot to mention. <br/> Coming back again to your very first contribution: <br/> The file “ <span class="caps"> INPUT </span> ” shows the INT2LM namelist settings for the further downscaling to your final resolution, right? <br/> In this namelist there are a few mistakes: <br/> group <a href=""> <span class="caps"> CONTRL </span> </a> <br/> - luse_t_skin must be .FALSE., not .TRUE., since <span class="caps"> TSKIN </span> is not provided by a “mother” <span class="caps"> CCLM </span> simulation <br/> - itype_t_cl should be zero, not one </p> <p> group <a href=""> <span class="caps"> GRID </span> _IN </a> <br/> - lushift_in=.TRUE. is o.k.; correctly, it should be lushift=.TRUE.,.FALSE. <br/> but: <br/> - lvshift=.TRUE. is wrong!!! It must be lvshift=.FALSE.,.TRUE. <br/> since the v-component of the wind of your 0.12 degree output is staggered wiht respect to the (rotated) south-north direction and not with respect to the <br/> (rotated) west-east direction as you indicated in your setting </p> <p> Hans-Juergen </p>

  @hans-jürgenpanitz in #7591d26

<p> Dear Vladimir, </p> <p> now I am a little bit confused. </p> <p> I looked into the files you provided with your very first contribution. </p> <p> File cclm_SF_0.12.sh shows the settings of your 0.12 degree simulation, right? <br/> And it contains “lstomata=.TRUE”. <br/> The file <span class="caps"> YUCHKDAT </span> also belongs to this 0.12 degree simulation, doesn’t it? </p> <p> In this <span class="caps"> YUCHKDAT </span> file I see the at the very beginning the checks for the laf-file <br/> /mnt/scratch/users/vplatonov/COSMO- <span class="caps"> CLM </span> /EXPERIMENTS/SanFrancisco/LM_Jan/laf2017011500.nc </p> <p> which contains a <span class="caps"> RSMIN </span> -field. </p> <p> If you now, in a new 0.122 degree <span class="caps"> CCLM </span> run, put lstomata=.FALSE., then <span class="caps"> RSMIN </span> is still in your laf-file, provided you did not re-run INT2LM with lstomata=.FALSE., <br/> but the <span class="caps"> RSMIN </span> field is not read by <span class="caps"> CCLM </span> and the values would not appear in the <span class="caps"> YUCHKDAT </span> file of the new <span class="caps"> CCLM </span> run. </p> <p> And I have furhter hints, which I forgot to mention. <br/> Coming back again to your very first contribution: <br/> The file “ <span class="caps"> INPUT </span> ” shows the INT2LM namelist settings for the further downscaling to your final resolution, right? <br/> In this namelist there are a few mistakes: <br/> group <a href=""> <span class="caps"> CONTRL </span> </a> <br/> - luse_t_skin must be .FALSE., not .TRUE., since <span class="caps"> TSKIN </span> is not provided by a “mother” <span class="caps"> CCLM </span> simulation <br/> - itype_t_cl should be zero, not one </p> <p> group <a href=""> <span class="caps"> GRID </span> _IN </a> <br/> - lushift_in=.TRUE. is o.k.; correctly, it should be lushift=.TRUE.,.FALSE. <br/> but: <br/> - lvshift=.TRUE. is wrong!!! It must be lvshift=.FALSE.,.TRUE. <br/> since the v-component of the wind of your 0.12 degree output is staggered wiht respect to the (rotated) south-north direction and not with respect to the <br/> (rotated) west-east direction as you indicated in your setting </p> <p> Hans-Juergen </p>
HP replied

Dear Vladimir,

now I am a little bit confused.

I looked into the files you provided with your very first contribution.

File cclm_SF_0.12.sh shows the settings of your 0.12 degree simulation, right?
And it contains “lstomata=.TRUE”.
The file YUCHKDAT also belongs to this 0.12 degree simulation, doesn’t it?

In this YUCHKDAT file I see the at the very beginning the checks for the laf-file
/mnt/scratch/users/vplatonov/COSMO- CLM /EXPERIMENTS/SanFrancisco/LM_Jan/laf2017011500.nc

which contains a RSMIN -field.

If you now, in a new 0.122 degree CCLM run, put lstomata=.FALSE., then RSMIN is still in your laf-file, provided you did not re-run INT2LM with lstomata=.FALSE.,
but the RSMIN field is not read by CCLM and the values would not appear in the YUCHKDAT file of the new CCLM run.

And I have furhter hints, which I forgot to mention.
Coming back again to your very first contribution:
The file “ INPUT ” shows the INT2LM namelist settings for the further downscaling to your final resolution, right?
In this namelist there are a few mistakes:
group CONTRL
- luse_t_skin must be .FALSE., not .TRUE., since TSKIN is not provided by a “mother” CCLM simulation
- itype_t_cl should be zero, not one

group GRID _IN
- lushift_in=.TRUE. is o.k.; correctly, it should be lushift=.TRUE.,.FALSE.
but:
- lvshift=.TRUE. is wrong!!! It must be lvshift=.FALSE.,.TRUE.
since the v-component of the wind of your 0.12 degree output is staggered wiht respect to the (rotated) south-north direction and not with respect to the
(rotated) west-east direction as you indicated in your setting

Hans-Juergen

View in channel
<p> Hello, <br/> I am also facing similar issues as that of Valdimir with my <span class="caps"> COSMO </span> DE runs at 0.02 Degree resolution. I use the online coupled <acronym title="n"> <span class="caps"> MECO </span> </acronym> system. For the 0.02 Degree resolution domain, I have adapted to the namelist settings of “cosmo-DE-2015022500_5.1.txt”. I get the boundary data online from the 0.0625 Degree domain, which doesnot have any problem. As I checked from the previous discussion, I use the default “lstomata” (False) and itype_gscp=4 for 0.02 Degree domain. <br/> It would be great if you suggest the issue with my setup. I have attached the <span class="caps"> OUTPUT </span> , <span class="caps"> YUPRHUMI </span> , <span class="caps"> YUPRMASS </span> , <span class="caps"> YUSPECIF </span> and <span class="caps"> YUCHKDAT </span> corresponding to my 0.02 degree simulation herewith. <br/> I will be thankful to your suggestions. </p> <p> Best Regards, <br/> Vinod </p>

  @vinodkumar in #01ba316

<p> Hello, <br/> I am also facing similar issues as that of Valdimir with my <span class="caps"> COSMO </span> DE runs at 0.02 Degree resolution. I use the online coupled <acronym title="n"> <span class="caps"> MECO </span> </acronym> system. For the 0.02 Degree resolution domain, I have adapted to the namelist settings of “cosmo-DE-2015022500_5.1.txt”. I get the boundary data online from the 0.0625 Degree domain, which doesnot have any problem. As I checked from the previous discussion, I use the default “lstomata” (False) and itype_gscp=4 for 0.02 Degree domain. <br/> It would be great if you suggest the issue with my setup. I have attached the <span class="caps"> OUTPUT </span> , <span class="caps"> YUPRHUMI </span> , <span class="caps"> YUPRMASS </span> , <span class="caps"> YUSPECIF </span> and <span class="caps"> YUCHKDAT </span> corresponding to my 0.02 degree simulation herewith. <br/> I will be thankful to your suggestions. </p> <p> Best Regards, <br/> Vinod </p>
VK replied

Hello,
I am also facing similar issues as that of Valdimir with my COSMO DE runs at 0.02 Degree resolution. I use the online coupled MECO system. For the 0.02 Degree resolution domain, I have adapted to the namelist settings of “cosmo-DE-2015022500_5.1.txt”. I get the boundary data online from the 0.0625 Degree domain, which doesnot have any problem. As I checked from the previous discussion, I use the default “lstomata” (False) and itype_gscp=4 for 0.02 Degree domain.
It would be great if you suggest the issue with my setup. I have attached the OUTPUT , YUPRHUMI , YUPRMASS , YUSPECIF and YUCHKDAT corresponding to my 0.02 degree simulation herewith.
I will be thankful to your suggestions.

Best Regards,
Vinod

View in channel