problem with COSMO-CLM forced by IFS at 0.075° – in #9: CCLM

in #9: CCLM

<p> Dear all, I am trying to run <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> at 0.009° resolution using the <span class="caps"> ECMWF </span> <span class="caps"> IFS </span> files at 0.075° as forcing. Int2lm works properly, but when I run <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> I get the following error message: </p> <p> <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** 2 </p> <p> The unusual situation is that if I use the <span class="caps"> IFS </span> files at 0.125°, <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> works… <br/> Could you please help me ? <br/> Best regards <br/> Edoardo Bucchignani </p>

  @edoardobucchignani in #891f6ad

<p> Dear all, I am trying to run <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> at 0.009° resolution using the <span class="caps"> ECMWF </span> <span class="caps"> IFS </span> files at 0.075° as forcing. Int2lm works properly, but when I run <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> I get the following error message: </p> <p> <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** 2 </p> <p> The unusual situation is that if I use the <span class="caps"> IFS </span> files at 0.125°, <span class="caps"> COSMO </span> - <span class="caps"> CLM </span> works… <br/> Could you please help me ? <br/> Best regards <br/> Edoardo Bucchignani </p>

problem with COSMO-CLM forced by IFS at 0.075°

EB wrote

Dear all, I am trying to run COSMO - CLM at 0.009° resolution using the ECMWF IFS files at 0.075° as forcing. Int2lm works properly, but when I run COSMO - CLM I get the following error message:

ERROR *** Vertical coordinates not descending for type *** 2

The unusual situation is that if I use the IFS files at 0.125°, COSMO - CLM works…
Could you please help me ?
Best regards
Edoardo Bucchignani

View in channel
<p> Can you provide an <br/> <pre> ncdump -h -v vcoord laf.... </pre> and the files <code> OUTPUT </code> of the INT2LM and <code> YUSPECIF </code> of the <span class="caps"> CCLM </span> ? </p>

  @burkhardtrockel in #aaa47a8

<p> Can you provide an <br/> <pre> ncdump -h -v vcoord laf.... </pre> and the files <code> OUTPUT </code> of the INT2LM and <code> YUSPECIF </code> of the <span class="caps"> CCLM </span> ? </p>
BR replied

Can you provide an 

ncdump -h -v vcoord laf....
and the files OUTPUT of the INT2LM and YUSPECIF of the CCLM ?

View in channel
<p> I have attached the requested files. The output of ncdump -h -v vcoord…. is in the file “ncd_out.txt”. <br/> Thanks <br/> Edoardo </p>

  @edoardobucchignani in #f775b1a

<p> I have attached the requested files. The output of ncdump -h -v vcoord…. is in the file “ncd_out.txt”. <br/> Thanks <br/> Edoardo </p>
EB replied

I have attached the requested files. The output of ncdump -h -v vcoord…. is in the file “ncd_out.txt”.
Thanks
Edoardo

View in channel
<p> The ncd_out.txt file does not contain the vcoord listing. I made a typo in the ncdump call above, sorry! Please try again with <code> ncdump -v vcoord .. </code> , i.e. by not using the <code> -h </code> option. </p> <p> Is the error message you send: <br/> <code> ERROR * Vertical coordinates not descending for type * 2 </code> <br/> complete? From the source code listing there should be two more parameters: <br/> <pre> <span class="caps">ELSEIF</span> (vcoord%ivctype == 2) <span class="caps">THEN</span></pre> </p> ! For this type the vertical coordinates should be descending IF ( vcoord%vert_coord(2) &gt; vcoord%vert_coord(1) ) THEN <span class="caps"> WRITE </span> (yerrmsg,’(A,I5,2F10.5)’) &amp; ‘ <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** ‘, &amp; vcoord%ivctype, vcoord%vert_coord(1), vcoord%vert_coord(2) istatus = 2008 RETURN <span class="caps"> ENDIF </span> <p> </p>

  @burkhardtrockel in #2dcddea

<p> The ncd_out.txt file does not contain the vcoord listing. I made a typo in the ncdump call above, sorry! Please try again with <code> ncdump -v vcoord .. </code> , i.e. by not using the <code> -h </code> option. </p> <p> Is the error message you send: <br/> <code> ERROR * Vertical coordinates not descending for type * 2 </code> <br/> complete? From the source code listing there should be two more parameters: <br/> <pre> <span class="caps">ELSEIF</span> (vcoord%ivctype == 2) <span class="caps">THEN</span></pre> </p> ! For this type the vertical coordinates should be descending IF ( vcoord%vert_coord(2) &gt; vcoord%vert_coord(1) ) THEN <span class="caps"> WRITE </span> (yerrmsg,’(A,I5,2F10.5)’) &amp; ‘ <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** ‘, &amp; vcoord%ivctype, vcoord%vert_coord(1), vcoord%vert_coord(2) istatus = 2008 RETURN <span class="caps"> ENDIF </span> <p> </p>
BR replied

The ncd_out.txt file does not contain the vcoord listing. I made a typo in the ncdump call above, sorry! Please try again with ncdump -v vcoord .. , i.e. by not using the -h option.

Is the error message you send:
ERROR * Vertical coordinates not descending for type * 2
complete? From the source code listing there should be two more parameters: 

ELSEIF (vcoord%ivctype == 2) THEN

! For this type the vertical coordinates should be descending IF ( vcoord%vert_coord(2) > vcoord%vert_coord(1) ) THEN WRITE (yerrmsg,’(A,I5,2F10.5)’) & ‘ ERROR *** Vertical coordinates not descending for type *** ‘, & vcoord%ivctype, vcoord%vert_coord(1), vcoord%vert_coord(2) istatus = 2008 RETURN ENDIF

View in channel
<p> I have attached the new ncd_out.txt file. </p> <p> The error message I get is: </p> <p> <span class="caps"> OPEN </span> : ncdf-file: /u1/bued185/RUN_URBAN/lm_input/2015070100/laf2015070100.nc <strong> —————————————————————————————— </strong> * <span class="caps"> PROGRAM </span> <span class="caps"> TERMINATED </span> <span class="caps"> BECAUSE </span> OF <span class="caps"> ERRORS </span> DETECTED * IN <span class="caps"> ROUTINE </span> : organize_input * * <span class="caps"> ERROR </span> <span class="caps"> CODE </span> is 8102 * <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** 2************** ****** <strong> —————————————————————————————— </strong> <br/> application called <span class="caps"> MPI </span> _Abort( <span class="caps"> MPI </span> _COMM_WORLD, 8102) – process 0 <br/> APPLICATION <span class="caps"> TERMINATED </span> <span class="caps"> WITH </span> <span class="caps"> THE </span> <span class="caps"> EXIT </span> <span class="caps"> STRING </span> : Hangup (signal 1) </p> <p> Thanks <br/> Edoardo </p>

  @edoardobucchignani in #da15ed5

<p> I have attached the new ncd_out.txt file. </p> <p> The error message I get is: </p> <p> <span class="caps"> OPEN </span> : ncdf-file: /u1/bued185/RUN_URBAN/lm_input/2015070100/laf2015070100.nc <strong> —————————————————————————————— </strong> * <span class="caps"> PROGRAM </span> <span class="caps"> TERMINATED </span> <span class="caps"> BECAUSE </span> OF <span class="caps"> ERRORS </span> DETECTED * IN <span class="caps"> ROUTINE </span> : organize_input * * <span class="caps"> ERROR </span> <span class="caps"> CODE </span> is 8102 * <span class="caps"> ERROR </span> *** Vertical coordinates not descending for type *** 2************** ****** <strong> —————————————————————————————— </strong> <br/> application called <span class="caps"> MPI </span> _Abort( <span class="caps"> MPI </span> _COMM_WORLD, 8102) – process 0 <br/> APPLICATION <span class="caps"> TERMINATED </span> <span class="caps"> WITH </span> <span class="caps"> THE </span> <span class="caps"> EXIT </span> <span class="caps"> STRING </span> : Hangup (signal 1) </p> <p> Thanks <br/> Edoardo </p>
EB replied

I have attached the new ncd_out.txt file.

The error message I get is:

OPEN : ncdf-file: /u1/bued185/RUN_URBAN/lm_input/2015070100/laf2015070100.nc —————————————————————————————— * PROGRAM TERMINATED BECAUSE OF ERRORS DETECTED * IN ROUTINE : organize_input * * ERROR CODE is 8102 * ERROR *** Vertical coordinates not descending for type *** 2************** ****** ——————————————————————————————
application called MPI _Abort( MPI _COMM_WORLD, 8102) – process 0
APPLICATION TERMINATED WITH THE EXIT STRING : Hangup (signal 1)

Thanks
Edoardo

View in channel
<p> Hi Edoardo, </p> <p> the vcoord-values are really strange! <br/> They increase from about 50 km to 100 km then suddenly drop to about 2.9 km, and decrease further to zero. <br/> To my knowledge, vcoord values have to be in descending order. <br/> Where are your values coming from? </p> <p> Hans-Juergen </p>

  @hans-jürgenpanitz in #d5311ad

<p> Hi Edoardo, </p> <p> the vcoord-values are really strange! <br/> They increase from about 50 km to 100 km then suddenly drop to about 2.9 km, and decrease further to zero. <br/> To my knowledge, vcoord values have to be in descending order. <br/> Where are your values coming from? </p> <p> Hans-Juergen </p>
HP replied

Hi Edoardo,

the vcoord-values are really strange!
They increase from about 50 km to 100 km then suddenly drop to about 2.9 km, and decrease further to zero.
To my knowledge, vcoord values have to be in descending order.
Where are your values coming from?

Hans-Juergen

View in channel
<p> The values of vcoord in the file <code> OUTPUT </code> are OK in the <code> lmgrid </code> nameless settings, but in the laf only the 21 lowest level of the 61 are OK. 21 is the default value for ke_tot+1. It seems that during the output process of int2lm something went wrong. You use <span class="caps"> GRIB </span> - <span class="caps"> API </span> as input and netCDF as output. This combination has not yet been fully tested and may cause problems. I have never used <span class="caps"> GRIB </span> - <span class="caps"> API </span> . Marie Piazza from Graz has some experience in using <span class="caps"> IFS </span> with <span class="caps"> GRIB </span> - <span class="caps"> API </span> and maybe someone from the <span class="caps"> DWD </span> . </p> <p> By the way: <code> zhhl_in </code> in <code> OUTPUT </code> shows also a strange behavior. It increases for level 2 to 15 and decreases then to the last level (137). </p>

  @burkhardtrockel in #483dc96

<p> The values of vcoord in the file <code> OUTPUT </code> are OK in the <code> lmgrid </code> nameless settings, but in the laf only the 21 lowest level of the 61 are OK. 21 is the default value for ke_tot+1. It seems that during the output process of int2lm something went wrong. You use <span class="caps"> GRIB </span> - <span class="caps"> API </span> as input and netCDF as output. This combination has not yet been fully tested and may cause problems. I have never used <span class="caps"> GRIB </span> - <span class="caps"> API </span> . Marie Piazza from Graz has some experience in using <span class="caps"> IFS </span> with <span class="caps"> GRIB </span> - <span class="caps"> API </span> and maybe someone from the <span class="caps"> DWD </span> . </p> <p> By the way: <code> zhhl_in </code> in <code> OUTPUT </code> shows also a strange behavior. It increases for level 2 to 15 and decreases then to the last level (137). </p>
BR replied

The values of vcoord in the file OUTPUT are OK in the lmgrid nameless settings, but in the laf only the 21 lowest level of the 61 are OK. 21 is the default value for ke_tot+1. It seems that during the output process of int2lm something went wrong. You use GRIB - API as input and netCDF as output. This combination has not yet been fully tested and may cause problems. I have never used GRIB - API . Marie Piazza from Graz has some experience in using IFS with GRIB - API and maybe someone from the DWD .

By the way: zhhl_in in OUTPUT shows also a strange behavior. It increases for level 2 to 15 and decreases then to the last level (137).

View in channel
<p> Dear colleagues, <br/> I have checked that the problem is related to the specific version of INT2LM (including terra_urb) ed in particular to the combination “ <span class="caps"> GRIB </span> - <span class="caps"> API </span> as input and netCDF as output”. In fact, when using grib both as input and as output, it seems working properly. <br/> Thanks for the support. <br/> Edoardo </p>

  @edoardobucchignani in #176424b

<p> Dear colleagues, <br/> I have checked that the problem is related to the specific version of INT2LM (including terra_urb) ed in particular to the combination “ <span class="caps"> GRIB </span> - <span class="caps"> API </span> as input and netCDF as output”. In fact, when using grib both as input and as output, it seems working properly. <br/> Thanks for the support. <br/> Edoardo </p>
EB replied

Dear colleagues,
I have checked that the problem is related to the specific version of INT2LM (including terra_urb) ed in particular to the combination “ GRIB - API as input and netCDF as output”. In fact, when using grib both as input and as output, it seems working properly.
Thanks for the support.
Edoardo

View in channel