Our site saves small pieces of text information (cookies) on your
device in order to verify your login. These cookies are essential
to provide access to resources on this website and it will not
work properly without.
Learn more
<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>
<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>
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!
<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>
<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>
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?
<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>
<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>
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.
<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>
<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>
<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>
<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>
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.
<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>
<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>
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.
<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>
<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>
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.
<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>
<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>
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!
<p>
Dear Vladimir, dear Burkhadt,
</p>
<p>
the lstomata paramater is related to variable
<a href="">
<span class="caps">
RSMIN
</span>
</a>
INT2LM: “RSMIN” > prs_min_lm, see "src_gribtabs.f90"
CCLM: "RSMIN" > 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>
<p>
Dear Vladimir, dear Burkhadt,
</p>
<p>
the lstomata paramater is related to variable
<a href="">
<span class="caps">
RSMIN
</span>
</a>
INT2LM: “RSMIN” > prs_min_lm, see "src_gribtabs.f90"
CCLM: "RSMIN" > 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>
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
<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>
<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>
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?
<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>
<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>
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
<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>
<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>
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.
NaN values in YUPRMASS etc
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!
Adhoc I see that you use
itype_gscp=4for 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 useitype_gscp=4in the cosmo-de settings with 0.025 degrees grid width. For cosmo-eu (0.0675 degrees grid width) they useitype_gscp=3. The standard setup for a CCLM simulations at 0.11 is alsoitype_gscp=3. Does your 0.12 simulation run with these standard settings or does it also crash?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.
Can you provide the related YUSPECIF file, too? Which versions of CCLM and INT2LM do you use?
I’m attaching YUSPECIF . I use int2lm_131101_2.00_clm4 and cosmo_131108_5.00_clm6 versions.
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.
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.
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.
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!
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
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?
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
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