Project

General

Profile

NaN values in YUPRMASS etc

Added by Vladimir Platonov almost 4 years ago

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 ERAInterim 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!


Replies (12)

RE: NaN values in YUPRMASS etc - Added by Burkhardt Rockel almost 4 years ago

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?

RE: NaN values in YUPRMASS etc - Added by Vladimir Platonov almost 4 years ago

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.

RE: NaN values in YUPRMASS etc - Added by Burkhardt Rockel almost 4 years ago

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

RE: NaN values in YUPRMASS etc - Added by Vladimir Platonov almost 4 years ago

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

RE: NaN values in YUPRMASS etc - Added by Burkhardt Rockel almost 4 years ago

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.

YUSPECIF YUSPECIF 54.4 KB

RE: NaN values in YUPRMASS etc - Added by Vladimir Platonov almost 4 years ago

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.

RE: NaN values in YUPRMASS etc - Added by Burkhardt Rockel almost 4 years ago

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.

YUSPECIF YUSPECIF 53.8 KB
OUTPUT OUTPUT 438 KB

RE: NaN values in YUPRMASS etc - Added by Vladimir Platonov over 3 years ago

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!

RE: NaN values in YUPRMASS etc - Added by Hans-Juergen Panitz over 3 years ago

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

RE: NaN values in YUPRMASS etc - Added by Vladimir Platonov over 3 years ago

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?

RE: NaN values in YUPRMASS etc - Added by Hans-Juergen Panitz over 3 years ago

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

RE: NaN values in YUPRMASS etc - Added by Vinod Kumar about 3 years ago

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

    (1-12/12)