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
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 filesOUTPUTof the INT2LM andYUSPECIFof 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
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-hoption.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).
The values of vcoord in the file
OUTPUTare OK in thelmgridnameless 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_ininOUTPUTshows 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
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