### 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

`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
```
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 #511fe02Burkhardt 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!