Maximum number of variables per GRIBOUT block
I am using the CCLM 4.8_clm19 version and encountered an unexpected behaviour of CCLM :
If I define only one
GRIBOUT
block with default variables, then everything is ok and about 70 variables are written to the netcdf output.
But if I define several blocks, than the maximum number of variables for the second block seems to be 15?
Does anyone know about this problem? The model crashes with this message:
*------------------------------------------------------------* * PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED * IN ROUTINE: organize_data: input-init * * ERROR CODE is 6105 * ERROR *** while reading namelist /GRIBOUT/: 2 ***
Here the definitions of the
GRIBOUT
blocks (with ngribout=2).
!out01: 3d variables
&GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=‘FRESHSNW’,‘PP’,‘QC’,‘QS’,‘QG’,‘QR’,‘QI’,‘QV’,‘QV_S’,‘T’,‘T_S’,‘T_SNOW’,‘T_SO’,‘U’,‘V’,‘W_I’, ‘W_SNOW’,‘W_SO’,‘W_SO_ICE’,‘CLC’,‘P’,‘QH’, yvarpl=’‘, yvarzl=’‘, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out01/’, ytunit=‘d’, /END
!out02: 2d variables (often used) &GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=’‘, yvarpl=’‘, yvarzl=‘ RAIN _CON’,‘ SNOW _CON’,‘ RAIN _GSP’,‘ SNOW _GSP’,‘ GRAU _GSP’,‘ TOT _PREC’,‘ CLCT ’,‘ CLCH ’,‘ CLCL ’,‘ CLCM ’,‘ HPBL ’,‘ DURSUN ’,‘ PMSL ’,‘PS’,‘QV_2M’,‘T_2M’, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out02/’, ytunit=‘d’, /END
If I remove “T_2M” from block 2, then there are 15 variables and the model runs…
Thanks for help!
You have chosen the wrong level option. It should be
yvarml
not
yvarzl
. It does not make sense to interpolate 2D-Variables to z-levels, which may give some very interesting results ;-)
The maximum number of variables that can be chosen are as follows (this holds at least for cclm4.8_clm19)
nzmxml = 150, & ! maximum number of output model-level variables nzmxpl = 50, & ! maximum number of pressure-level variables nzmxzl = 15, & ! maximum number of height-level variables nzmxc = 20, & ! maximum number of constant variables
You have chosen the wrong level option. It should be
yvarmlnotyvarzl. It does not make sense to interpolate 2D-Variables to z-levels, which may give some very interesting results ;-)
The maximum number of variables that can be chosen are as follows (this holds at least for cclm4.8_clm19)nzmxml = 150, & ! maximum number of output model-level variables nzmxpl = 50, & ! maximum number of pressure-level variables nzmxzl = 15, & ! maximum number of height-level variables nzmxc = 20, & ! maximum number of constant variables
You have chosen the wrong level option. It should be
yvarml
not
yvarzl
. It does not make sense to interpolate 2D-Variables to z-levels, which may give some very interesting results ;-)
The maximum number of variables that can be chosen are as follows (this holds at least for cclm4.8_clm19)
nzmxml = 150, & ! maximum number of output model-level variables nzmxpl = 50, & ! maximum number of pressure-level variables nzmxzl = 15, & ! maximum number of height-level variables nzmxc = 20, & ! maximum number of constant variables
Burkhardt is right.
And why do you store the constant variables in each
GRIBOUT
-block (lwrite_const=.TRUE.)?
Storing them in your 1. Block makes sense, since seems to contain all variables which are necessary for a further downscaling.
But storing them twice is a waste of disk capacity.
Hans-Jürgen
@hans-jürgenpanitz in #511fe02
Burkhardt is right.
And why do you store the constant variables in each GRIBOUT -block (lwrite_const=.TRUE.)?
Storing them in your 1. Block makes sense, since seems to contain all variables which are necessary for a further downscaling.
But storing them twice is a waste of disk capacity.Hans-Jürgen
Burkhardt is right.
And why do you store the constant variables in each
GRIBOUT
-block (lwrite_const=.TRUE.)?
Storing them in your 1. Block makes sense, since seems to contain all variables which are necessary for a further downscaling.
But storing them twice is a waste of disk capacity.
Hans-Jürgen
Okay, thank you Burkhardt, that was the error :)
@Hans-Jürgen: you are right, that doesn’t make sense. That was an old relict of a former configuration, but I set lwrite_const=.FALSE. for all GRIBOUT s except out01.
Okay, thank you Burkhardt, that was the error :)
@Hans-Jürgen: you are right, that doesn’t make sense. That was an old relict of a former configuration, but I set lwrite_const=.FALSE. for all GRIBOUT s except out01.
Okay, thank you Burkhardt, that was the error :)
@Hans-Jürgen: you are right, that doesn’t make sense. That was an old relict of a former configuration, but I set lwrite_const=.FALSE. for all GRIBOUT s except out01.
I am using the CCLM 4.8_clm19 version and encountered an unexpected behaviour of CCLM :
If I define only one GRIBOUT block with default variables, then everything is ok and about 70 variables are written to the netcdf output.
But if I define several blocks, than the maximum number of variables for the second block seems to be 15?
Does anyone know about this problem? The model crashes with this message:
Here the definitions of the GRIBOUT blocks (with ngribout=2).
!out02: 2d variables (often used) &GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=’‘, yvarpl=’‘, yvarzl=‘ RAIN _CON’,‘ SNOW _CON’,‘ RAIN _GSP’,‘ SNOW _GSP’,‘ GRAU _GSP’,‘ TOT _PREC’,‘ CLCT ’,‘ CLCH ’,‘ CLCL ’,‘ CLCM ’,‘ HPBL ’,‘ DURSUN ’,‘ PMSL ’,‘PS’,‘QV_2M’,‘T_2M’, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out02/’, ytunit=‘d’, /END
If I remove “T_2M” from block 2, then there are 15 variables and the model runs…
Thanks for help!