problem with COSMO-CLM forced by IFS at 0.075° – in #9: CCLM
in #9: CCLM
Cookies disclaimer
Our site saves small pieces of text information (cookies) on your
device in order to verify your login. These cookies are essential
to provide access to resources on this website and it will not
work properly without.
Learn more
<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>
<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>
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
<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>
<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>
<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) > vcoord%vert_coord(1) ) THEN
<span class="caps">
WRITE
</span>
(yerrmsg,’(A,I5,2F10.5)’) &
‘
<span class="caps">
ERROR
</span>
*** Vertical coordinates not descending for type *** ‘, &
vcoord%ivctype, vcoord%vert_coord(1), vcoord%vert_coord(2)
istatus = 2008
RETURN
<span class="caps">
ENDIF
</span>
<p>
</p>
<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) > vcoord%vert_coord(1) ) THEN
<span class="caps">
WRITE
</span>
(yerrmsg,’(A,I5,2F10.5)’) &
‘
<span class="caps">
ERROR
</span>
*** Vertical coordinates not descending for type *** ‘, &
vcoord%ivctype, vcoord%vert_coord(1), vcoord%vert_coord(2)
istatus = 2008
RETURN
<span class="caps">
ENDIF
</span>
<p>
</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
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
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)
<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>
<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>
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?
<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>
<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>
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).
<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>
<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>
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
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
and the filesOUTPUTof the INT2LM andYUSPECIFof the CCLM ?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-hoption.Is the error message you send:
! 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 ENDIFERROR * Vertical coordinates not descending for type * 2complete? From the source code listing there should be two more parameters:
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
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).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