CCLM simulations fail on Mistral - floating point exception C – in #9: CCLM

in #9: CCLM

<p> Dear Hans-Juergen, </p> <p> Thank you very much for your support and sorry for the late reply but it took me a few days to go back to the roots of the problem. <br/> I agree that there’s something wrong with those temperature, therefore I went back to the previous downscaling step to see where these weird values came from. </p> <p> I wanted to repeat the simulation driven with <span class="caps"> ERA </span> -Interim obtained from the <span class="caps"> DKRZ </span> directory /pool/data/CCLM/reanalyses/ERAInterim. I adapted the run_int2lm script for the gcm2cclm case. Again, I wanted to test that it was working fine for 24 hours. </p> <p> Unfortunately the situation does not seem to have changed at all. The “floating point exception” error is still causing the program to quit. So it seems that the problem goes beyond the T_SO values. I am really losing the focus on what the problem is right now. I have checked and double-checked but clearly there’s something wrong that I can’t find. </p> <p> Please find attached the run_int2lm, the .out, <span class="caps"> YUCHKDAT </span> , <span class="caps"> INPUT </span> , <span class="caps"> OUTPUT </span> and <span class="caps"> YUDEBUG </span> files. </p> <p> Best wishes, </p> <p> Edoardo </p>

  @redc_migration in #b140824

<p> Dear Hans-Juergen, </p> <p> Thank you very much for your support and sorry for the late reply but it took me a few days to go back to the roots of the problem. <br/> I agree that there’s something wrong with those temperature, therefore I went back to the previous downscaling step to see where these weird values came from. </p> <p> I wanted to repeat the simulation driven with <span class="caps"> ERA </span> -Interim obtained from the <span class="caps"> DKRZ </span> directory /pool/data/CCLM/reanalyses/ERAInterim. I adapted the run_int2lm script for the gcm2cclm case. Again, I wanted to test that it was working fine for 24 hours. </p> <p> Unfortunately the situation does not seem to have changed at all. The “floating point exception” error is still causing the program to quit. So it seems that the problem goes beyond the T_SO values. I am really losing the focus on what the problem is right now. I have checked and double-checked but clearly there’s something wrong that I can’t find. </p> <p> Please find attached the run_int2lm, the .out, <span class="caps"> YUCHKDAT </span> , <span class="caps"> INPUT </span> , <span class="caps"> OUTPUT </span> and <span class="caps"> YUDEBUG </span> files. </p> <p> Best wishes, </p> <p> Edoardo </p>
re replied

Dear Hans-Juergen,

Thank you very much for your support and sorry for the late reply but it took me a few days to go back to the roots of the problem.
I agree that there’s something wrong with those temperature, therefore I went back to the previous downscaling step to see where these weird values came from.

I wanted to repeat the simulation driven with ERA -Interim obtained from the DKRZ directory /pool/data/CCLM/reanalyses/ERAInterim. I adapted the run_int2lm script for the gcm2cclm case. Again, I wanted to test that it was working fine for 24 hours.

Unfortunately the situation does not seem to have changed at all. The “floating point exception” error is still causing the program to quit. So it seems that the problem goes beyond the T_SO values. I am really losing the focus on what the problem is right now. I have checked and double-checked but clearly there’s something wrong that I can’t find.

Please find attached the run_int2lm, the .out, YUCHKDAT , INPUT , OUTPUT and YUDEBUG files.

Best wishes,

Edoardo

View in channel