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

in #9: CCLM

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

  @edoardobucchignani in #891f6ad

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

problem with COSMO-CLM forced by IFS at 0.075°

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

Can you provide an

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

  @burkhardtrockel in #aaa47a8

Can you provide an

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

Can you provide an

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

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

  @edoardobucchignani in #f775b1a

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

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

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

  @burkhardtrockel in #2dcddea

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

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

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

  @edoardobucchignani in #da15ed5

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

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

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

  @hans-jürgenpanitz in #d5311ad

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

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

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).

  @burkhardtrockel in #483dc96

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).

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).

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

  @edoardobucchignani in #176424b

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

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