an issue when running regional climate projections on Mistral – in #9: CCLM

in #9: CCLM

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

  @deleili in #f161b0d

<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

DL wrote

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

View in channel
<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), &amp;</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>

  @ulrichschättler in #29da6e0

<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), &amp;</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>
US replied

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!

Ciao
Uli

View in channel
<p> Dear Uli, </p> <p> Thanks a lot for your kind help. I will try your suggestion and see if it works. </p> <p> Regards, <br/> Delei </p>

  @deleili in #c9313d6

<p> Dear Uli, </p> <p> Thanks a lot for your kind help. I will try your suggestion and see if it works. </p> <p> Regards, <br/> Delei </p>
DL replied

Dear Uli,

Thanks a lot for your kind help. I will try your suggestion and see if it works.

Regards,
Delei

View in channel
<p> Ulrich Schättler wrote: <br/> &gt; Hello Delei <br/> &gt; 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/> &gt; <br/> &gt; […] <br/> &gt; <br/> &gt; And from 2005 to 2073, these are just 68 years! <br/> &gt; <br/> &gt; The parameter int_dp is defined in data_parameters.f90 with <br/> &gt; […] <br/> &gt; 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/> &gt; <br/> &gt; Ciao <br/> &gt; Uli </p> <p> Dear Uli, </p> <p> Thanks again for your suggestion, it works very well. </p> <p> Regards, <br/> Delei </p>

  @deleili in #9efded3

<p> Ulrich Schättler wrote: <br/> &gt; Hello Delei <br/> &gt; 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/> &gt; <br/> &gt; […] <br/> &gt; <br/> &gt; And from 2005 to 2073, these are just 68 years! <br/> &gt; <br/> &gt; The parameter int_dp is defined in data_parameters.f90 with <br/> &gt; […] <br/> &gt; 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/> &gt; <br/> &gt; Ciao <br/> &gt; Uli </p> <p> Dear Uli, </p> <p> Thanks again for your suggestion, it works very well. </p> <p> Regards, <br/> Delei </p>
DL replied

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

View in channel