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:
! 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
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
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
Dear Uli,
Thanks a lot for your kind help. I will try your suggestion and see if it works.
Regards,
Delei
Dear Uli,
Thanks a lot for your kind help. I will try your suggestion and see if it works.
Regards,
Delei
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
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
> UliDear Uli,
Thanks again for your suggestion, it works very well.
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
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