Maximum number of variables per GRIBOUT block – in #8: General Questions

in #8: General Questions

<p> I am using the <span class="caps"> CCLM </span> 4.8_clm19 version and encountered an unexpected behaviour of <span class="caps"> CCLM </span> : </p> <p> If I define only one <span class="caps"> GRIBOUT </span> block with default variables, then everything is ok and about 70 variables are written to the netcdf output. <br/> But if I define several blocks, than the maximum number of variables for the second block seems to be 15? </p> <p> Does anyone know about this problem? The model crashes with this message: </p> <pre> *------------------------------------------------------------* * PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED * IN ROUTINE: organize_data: input-init * * ERROR CODE is 6105 * ERROR *** while reading namelist /GRIBOUT/: 2 *** </pre> <p> Here the definitions of the <span class="caps"> GRIBOUT </span> blocks (with ngribout=2). <br/> <pre><br/> !out01: 3d variables<br/> &amp;GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=‘<span class="caps">FRESHSNW</span>’,‘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’,‘<span class="caps">CLC</span>’,‘P’,‘QH’, yvarpl=’‘, yvarzl=’‘, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out01/’, ytunit=‘d’, /END</pre> </p> <p> !out02: 2d variables (often used) &amp;GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=’‘, yvarpl=’‘, yvarzl=‘ <span class="caps"> RAIN </span> _CON’,‘ <span class="caps"> SNOW </span> _CON’,‘ <span class="caps"> RAIN </span> _GSP’,‘ <span class="caps"> SNOW </span> _GSP’,‘ <span class="caps"> GRAU </span> _GSP’,‘ <span class="caps"> TOT </span> _PREC’,‘ <span class="caps"> CLCT </span> ’,‘ <span class="caps"> CLCH </span> ’,‘ <span class="caps"> CLCL </span> ’,‘ <span class="caps"> CLCM </span> ’,‘ <span class="caps"> HPBL </span> ’,‘ <span class="caps"> DURSUN </span> ’,‘ <span class="caps"> PMSL </span> ’,‘PS’,‘QV_2M’,‘T_2M’, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out02/’, ytunit=‘d’, /END </p> <p> </p> <p> If I remove “T_2M” from block 2, then there are 15 variables and the model runs… </p> <p> Thanks for help! </p>

  @redc_migration in #56981e8

<p> I am using the <span class="caps"> CCLM </span> 4.8_clm19 version and encountered an unexpected behaviour of <span class="caps"> CCLM </span> : </p> <p> If I define only one <span class="caps"> GRIBOUT </span> block with default variables, then everything is ok and about 70 variables are written to the netcdf output. <br/> But if I define several blocks, than the maximum number of variables for the second block seems to be 15? </p> <p> Does anyone know about this problem? The model crashes with this message: </p> <pre> *------------------------------------------------------------* * PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED * IN ROUTINE: organize_data: input-init * * ERROR CODE is 6105 * ERROR *** while reading namelist /GRIBOUT/: 2 *** </pre> <p> Here the definitions of the <span class="caps"> GRIBOUT </span> blocks (with ngribout=2). <br/> <pre><br/> !out01: 3d variables<br/> &amp;GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=‘<span class="caps">FRESHSNW</span>’,‘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’,‘<span class="caps">CLC</span>’,‘P’,‘QH’, yvarpl=’‘, yvarzl=’‘, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out01/’, ytunit=‘d’, /END</pre> </p> <p> !out02: 2d variables (often used) &amp;GRIBOUT ysystem=‘file’, hcomb= 0.0,29.0,1.0, l_p_filter=.FALSE., l_z_filter=.FALSE., yvarml=’‘, yvarpl=’‘, yvarzl=‘ <span class="caps"> RAIN </span> _CON’,‘ <span class="caps"> SNOW </span> _CON’,‘ <span class="caps"> RAIN </span> _GSP’,‘ <span class="caps"> SNOW </span> _GSP’,‘ <span class="caps"> GRAU </span> _GSP’,‘ <span class="caps"> TOT </span> _PREC’,‘ <span class="caps"> CLCT </span> ’,‘ <span class="caps"> CLCH </span> ’,‘ <span class="caps"> CLCL </span> ’,‘ <span class="caps"> CLCM </span> ’,‘ <span class="caps"> HPBL </span> ’,‘ <span class="caps"> DURSUN </span> ’,‘ <span class="caps"> PMSL </span> ’,‘PS’,‘QV_2M’,‘T_2M’, luvmasspoint=.FALSE., lcheck =.TRUE., lwrite_const=.TRUE., ydir=’${outpath}/out02/’, ytunit=‘d’, /END </p> <p> </p> <p> If I remove “T_2M” from block 2, then there are 15 variables and the model runs… </p> <p> Thanks for help! </p>

Maximum number of variables per GRIBOUT block

re wrote

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!

View in channel
<p> You have chosen the wrong level option. It should be <code> yvarml </code> not <code> yvarzl </code> . It does not make sense to interpolate 2D-Variables to z-levels, which may give some very interesting results ;-) <br/> The maximum number of variables that can be chosen are as follows (this holds at least for cclm4.8_clm19) <br/> <pre> nzmxml = 150, &amp; ! maximum number of output model-level variables nzmxpl = 50, &amp; ! maximum number of pressure-level variables nzmxzl = 15, &amp; ! maximum number of height-level variables nzmxc = 20, &amp; ! maximum number of constant variables </pre> </p>

  @burkhardtrockel in #0835941

<p> You have chosen the wrong level option. It should be <code> yvarml </code> not <code> yvarzl </code> . It does not make sense to interpolate 2D-Variables to z-levels, which may give some very interesting results ;-) <br/> The maximum number of variables that can be chosen are as follows (this holds at least for cclm4.8_clm19) <br/> <pre> nzmxml = 150, &amp; ! maximum number of output model-level variables nzmxpl = 50, &amp; ! maximum number of pressure-level variables nzmxzl = 15, &amp; ! maximum number of height-level variables nzmxc = 20, &amp; ! maximum number of constant variables </pre> </p>
BR replied

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

View in channel
<p> Burkhardt is right. <br/> And why do you store the constant variables in each <span class="caps"> GRIBOUT </span> -block (lwrite_const=.TRUE.)? <br/> Storing them in your 1. Block makes sense, since seems to contain all variables which are necessary for a further downscaling. <br/> But storing them twice is a waste of disk capacity. </p> <p> Hans-Jürgen </p>

  @hans-jürgenpanitz in #511fe02

<p> Burkhardt is right. <br/> And why do you store the constant variables in each <span class="caps"> GRIBOUT </span> -block (lwrite_const=.TRUE.)? <br/> Storing them in your 1. Block makes sense, since seems to contain all variables which are necessary for a further downscaling. <br/> But storing them twice is a waste of disk capacity. </p> <p> Hans-Jürgen </p>
HP replied

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

View in channel
<p> Okay, thank you Burkhardt, that was the error :) </p> <p> @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 <span class="caps"> GRIBOUT </span> s except out01. </p>

  @redc_migration in #700b62f

<p> Okay, thank you Burkhardt, that was the error :) </p> <p> @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 <span class="caps"> GRIBOUT </span> s except out01. </p>
re replied

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.

View in channel