Issue of the TERRA_URB version of INT2LM? – in #10: INT2LM

in #10: INT2LM

<p> Dear all, </p> <p> I have tried to rerun model (cclm-sp_2.4_terra_urb_2.3) with corrected ERA5 converted cas data (stored at <span class="caps"> DKRZ </span> under /pool/data/CCLM/reanalyses/ERA5). <br/> Unfortunately INT2LM stops when opening these files. I’ve attached all log files. </p> <p> Regards <br/> Adam </p>

  @adamjaczewski in #26ca205

<p> Dear all, </p> <p> I have tried to rerun model (cclm-sp_2.4_terra_urb_2.3) with corrected ERA5 converted cas data (stored at <span class="caps"> DKRZ </span> under /pool/data/CCLM/reanalyses/ERA5). <br/> Unfortunately INT2LM stops when opening these files. I’ve attached all log files. </p> <p> Regards <br/> Adam </p>

Issue of the TERRA_URB version of INT2LM?

AJ wrote

Dear all,

I have tried to rerun model (cclm-sp_2.4_terra_urb_2.3) with corrected ERA5 converted cas data (stored at DKRZ under /pool/data/CCLM/reanalyses/ERA5).
Unfortunately INT2LM stops when opening these files. I’ve attached all log files.

Regards
Adam

View in channel
<p> I recently also had problems with int2lm crashing while processing ERA5 data. The problem turned out to be as described here: https://redc.clm-community.eu/boards/12/topics/728 </p> <p> I notice that you’ve got 98 vertical levels in your coarse grid data (ERA5), which is above the maximum allowed (see link). In my case, the problem went away by first pre-processing the ERA5 data with ncks to remove the highest few levels of ERA5 data (e.g. ncks -d level,4,97 -d level1,4,98 ifile.nc ofile.nc). That brought the number of vertical levels below the allowed limit. Maybe this would work for you too. </p> <p> Another point to note is that (as you probably read here /pool/data/CCLM/reanalyses/ERA5/README.md), the ERA5 data need to be decompressed before running with int2lm. I’ve found in the past that if I copy the data from <span class="caps"> DKRZ </span> and do the decompression in another computing centre that it can still causes int2lm to crash. Therefore, if possible, it’s best to do the decompression at <span class="caps"> DKRZ </span> (where the the original compression was performed) before copying the data to your own computing centre. </p> <p> Good luck! </p>

  @edmundmeredith in #1c53973

<p> I recently also had problems with int2lm crashing while processing ERA5 data. The problem turned out to be as described here: https://redc.clm-community.eu/boards/12/topics/728 </p> <p> I notice that you’ve got 98 vertical levels in your coarse grid data (ERA5), which is above the maximum allowed (see link). In my case, the problem went away by first pre-processing the ERA5 data with ncks to remove the highest few levels of ERA5 data (e.g. ncks -d level,4,97 -d level1,4,98 ifile.nc ofile.nc). That brought the number of vertical levels below the allowed limit. Maybe this would work for you too. </p> <p> Another point to note is that (as you probably read here /pool/data/CCLM/reanalyses/ERA5/README.md), the ERA5 data need to be decompressed before running with int2lm. I’ve found in the past that if I copy the data from <span class="caps"> DKRZ </span> and do the decompression in another computing centre that it can still causes int2lm to crash. Therefore, if possible, it’s best to do the decompression at <span class="caps"> DKRZ </span> (where the the original compression was performed) before copying the data to your own computing centre. </p> <p> Good luck! </p>
EM replied

I recently also had problems with int2lm crashing while processing ERA5 data. The problem turned out to be as described here: https://redc.clm-community.eu/boards/12/topics/728

I notice that you’ve got 98 vertical levels in your coarse grid data (ERA5), which is above the maximum allowed (see link). In my case, the problem went away by first pre-processing the ERA5 data with ncks to remove the highest few levels of ERA5 data (e.g. ncks -d level,4,97 -d level1,4,98 ifile.nc ofile.nc). That brought the number of vertical levels below the allowed limit. Maybe this would work for you too.

Another point to note is that (as you probably read here /pool/data/CCLM/reanalyses/ERA5/README.md), the ERA5 data need to be decompressed before running with int2lm. I’ve found in the past that if I copy the data from DKRZ and do the decompression in another computing centre that it can still causes int2lm to crash. Therefore, if possible, it’s best to do the decompression at DKRZ (where the the original compression was performed) before copying the data to your own computing centre.

Good luck!

View in channel