an issue when running regional climate projections on Mistral – 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 colleagues,
</p>
<p>
Wish you a happy new year.
</p>
<p>
Recently I encounter a problem when running regional climate projections on Mistral at
<span class="caps">
DKRZ
</span>
. Several simulations were performed using
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
driven by different
<span class="caps">
GCM
</span>
forcings (
<span class="caps">
CNRM
</span>
-CM5 and EC-
<span class="caps">
EARTH
</span>
). The historical runs are from 1950 to 2005, and the future projections continue running from 2006 under different scenarios (RCP4.5 and RCP8.5). I found that all simulations stop running at the same time, which is 207312190900
</p>
<p>
In order to find the error source, I have conducted another two experiments: one is warm start from 2073 Dec. 01; another one is cold start from 2073 Dec. 01. The warm-start one has the same error as the long-term simulatiosn, while the cold-start one runs well with no problem. I have no idea how does this issue come. Does anyone has experience? The error information is attached for your reference. I would appreciate it if you could kindly help me.
</p>
<p>
Best regards,
<br/>
Delei Li
</p>
<p>
Dear colleagues,
</p>
<p>
Wish you a happy new year.
</p>
<p>
Recently I encounter a problem when running regional climate projections on Mistral at
<span class="caps">
DKRZ
</span>
. Several simulations were performed using
<span class="caps">
COSMO
</span>
-
<span class="caps">
CLM
</span>
driven by different
<span class="caps">
GCM
</span>
forcings (
<span class="caps">
CNRM
</span>
-CM5 and EC-
<span class="caps">
EARTH
</span>
). The historical runs are from 1950 to 2005, and the future projections continue running from 2006 under different scenarios (RCP4.5 and RCP8.5). I found that all simulations stop running at the same time, which is 207312190900
</p>
<p>
In order to find the error source, I have conducted another two experiments: one is warm start from 2073 Dec. 01; another one is cold start from 2073 Dec. 01. The warm-start one has the same error as the long-term simulatiosn, while the cold-start one runs well with no problem. I have no idea how does this issue come. Does anyone has experience? The error information is attached for your reference. I would appreciate it if you could kindly help me.
</p>
<p>
Best regards,
<br/>
Delei Li
</p>
an issue when running regional climate projections on Mistral
Recently I encounter a problem when running regional climate projections on Mistral at
DKRZ
. Several simulations were performed using
COSMO
-
CLM
driven by different
GCM
forcings (
CNRM
-CM5 and EC-
EARTH
). The historical runs are from 1950 to 2005, and the future projections continue running from 2006 under different scenarios (RCP4.5 and RCP8.5). I found that all simulations stop running at the same time, which is 207312190900
In order to find the error source, I have conducted another two experiments: one is warm start from 2073 Dec. 01; another one is cold start from 2073 Dec. 01. The warm-start one has the same error as the long-term simulatiosn, while the cold-start one runs well with no problem. I have no idea how does this issue come. Does anyone has experience? The error information is attached for your reference. I would appreciate it if you could kindly help me.
<p>
Hello Delei
<br/>
this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
</p>
<p>
<pre><br/>
! And for computing the amount of seconds of the whole forecast time,<br/>
! an 8-Byte <span class="caps">INTEGER</span> has to be used. Otherwise the computation fails after<br/>
! approx. 68 years!!</pre>
</p>
<p>
<span class="caps">
INTEGER
</span>
(
<span class="caps">
KIND
</span>
=int_dp) :: insec
<br/>
</p>
<p>
And from 2005 to 2073, these are just 68 years!
</p>
<p>
The parameter int_dp is defined in data_parameters.f90 with
<br/>
<pre>
int_dp = <span class="caps">SELECTED</span>_INT_KIND (12), &</pre>
</p>
<p>
<br/>
This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
</p>
<p>
Ciao
<br/>
Uli
</p>
<p>
Hello Delei
<br/>
this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
</p>
<p>
<pre><br/>
! And for computing the amount of seconds of the whole forecast time,<br/>
! an 8-Byte <span class="caps">INTEGER</span> has to be used. Otherwise the computation fails after<br/>
! approx. 68 years!!</pre>
</p>
<p>
<span class="caps">
INTEGER
</span>
(
<span class="caps">
KIND
</span>
=int_dp) :: insec
<br/>
</p>
<p>
And from 2005 to 2073, these are just 68 years!
</p>
<p>
The parameter int_dp is defined in data_parameters.f90 with
<br/>
<pre>
int_dp = <span class="caps">SELECTED</span>_INT_KIND (12), &</pre>
</p>
<p>
<br/>
This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
</p>
<p>
Ciao
<br/>
Uli
</p>
Hello Delei
this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
! And for computing the amount of seconds of the whole forecast time,
! an 8-Byte INTEGER has to be used. Otherwise the computation fails after
! approx. 68 years!!
INTEGER
(
KIND
=int_dp) :: insec
And from 2005 to 2073, these are just 68 years!
The parameter int_dp is defined in data_parameters.f90 with
int_dp = SELECTED_INT_KIND (12), &
This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
<p>
Ulrich Schättler wrote:
<br/>
> Hello Delei
<br/>
> this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
<br/>
>
<br/>
> […]
<br/>
>
<br/>
> And from 2005 to 2073, these are just 68 years!
<br/>
>
<br/>
> The parameter int_dp is defined in data_parameters.f90 with
<br/>
> […]
<br/>
> This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
<br/>
>
<br/>
> Ciao
<br/>
> Uli
</p>
<p>
Dear Uli,
</p>
<p>
Thanks again for your suggestion, it works very well.
</p>
<p>
Regards,
<br/>
Delei
</p>
<p>
Ulrich Schättler wrote:
<br/>
> Hello Delei
<br/>
> this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
<br/>
>
<br/>
> […]
<br/>
>
<br/>
> And from 2005 to 2073, these are just 68 years!
<br/>
>
<br/>
> The parameter int_dp is defined in data_parameters.f90 with
<br/>
> […]
<br/>
> This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
<br/>
>
<br/>
> Ciao
<br/>
> Uli
</p>
<p>
Dear Uli,
</p>
<p>
Thanks again for your suggestion, it works very well.
</p>
<p>
Regards,
<br/>
Delei
</p>
Ulrich Schättler wrote:
> Hello Delei
> this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
>
> […]
>
> And from 2005 to 2073, these are just 68 years!
>
> The parameter int_dp is defined in data_parameters.f90 with
> […]
> This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
>
> Ciao
> Uli
Dear Uli,
Thanks again for your suggestion, it works very well.
an issue when running regional climate projections on Mistral
Dear colleagues,
Wish you a happy new year.
Recently I encounter a problem when running regional climate projections on Mistral at DKRZ . Several simulations were performed using COSMO - CLM driven by different GCM forcings ( CNRM -CM5 and EC- EARTH ). The historical runs are from 1950 to 2005, and the future projections continue running from 2006 under different scenarios (RCP4.5 and RCP8.5). I found that all simulations stop running at the same time, which is 207312190900
In order to find the error source, I have conducted another two experiments: one is warm start from 2073 Dec. 01; another one is cold start from 2073 Dec. 01. The warm-start one has the same error as the long-term simulatiosn, while the cold-start one runs well with no problem. I have no idea how does this issue come. Does anyone has experience? The error information is attached for your reference. I would appreciate it if you could kindly help me.
Best regards,
Delei Li
Hello Delei
this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
INTEGER ( KIND =int_dp) :: insec
And from 2005 to 2073, these are just 68 years!
The parameter int_dp is defined in data_parameters.f90 with
int_dp = SELECTED_INT_KIND (12), &This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
Ciao
Uli
Dear Uli,
Thanks a lot for your kind help. I will try your suggestion and see if it works.
Regards,
Delei
Ulrich Schättler wrote:
> Hello Delei
> this sounds like something is going wrong in subroutine get_utc_date (in module utilities.f90), which computes the actual time: This subroutine defines a special integer, which has to be a long integer: quoting from the code:
>
> […]
>
> And from 2005 to 2073, these are just 68 years!
>
> The parameter int_dp is defined in data_parameters.f90 with
> […]
> This worked on all machines and compilers up to now. Maybe for Mistral and the compiler you are using you should try a higher number than 12. You could try with 18. Then you have to recompile the model!
>
> Ciao
> Uli
Dear Uli,
Thanks again for your suggestion, it works very well.
Regards,
Delei