Problem when writing averaged variables for multiple temporal resolutions – in #9: CCLM

in #9: CCLM

<p> Setting time range 3 and 4 quantities to zero at the output steps has been introduced especially for the climate mode <code> lbdclim=.TRUE. </code> . This has been done to prevent numeric overflows due to summing up over long time periods. Up to now it is not possible to use time range 3 and 4 quantities in more than one gribout namelist section. There are two work arounds that come to my mind you may consider: </p> <p> 1. If you are using a chain job that runs month by month, use a 15 min output for the whole region and write some lines to cut out the time (hourly for the whole region) and space (for the 15min output) you need in a post processing at the end of each month (preferably using the <code> ncks </code> program from the <span class="caps"> NCO </span> -Libray, you may also use <span class="caps"> CDO </span> commands, but be aware that <span class="caps"> CDO </span> corrupts your netCDF CF-Conventions.). If you are using <code> subchain </code> you can do this in the <code> post.job.tmpl </code> . </p> <p> 2. If your simulation period is not too long you may comment out the <code> lbdclim=.TRUE. </code> if-branches in <code> src_output.f90 </code> . Hope this works (haven’t tried this myself, though) </p>

  @burkhardtrockel in #fe06958

<p> Setting time range 3 and 4 quantities to zero at the output steps has been introduced especially for the climate mode <code> lbdclim=.TRUE. </code> . This has been done to prevent numeric overflows due to summing up over long time periods. Up to now it is not possible to use time range 3 and 4 quantities in more than one gribout namelist section. There are two work arounds that come to my mind you may consider: </p> <p> 1. If you are using a chain job that runs month by month, use a 15 min output for the whole region and write some lines to cut out the time (hourly for the whole region) and space (for the 15min output) you need in a post processing at the end of each month (preferably using the <code> ncks </code> program from the <span class="caps"> NCO </span> -Libray, you may also use <span class="caps"> CDO </span> commands, but be aware that <span class="caps"> CDO </span> corrupts your netCDF CF-Conventions.). If you are using <code> subchain </code> you can do this in the <code> post.job.tmpl </code> . </p> <p> 2. If your simulation period is not too long you may comment out the <code> lbdclim=.TRUE. </code> if-branches in <code> src_output.f90 </code> . Hope this works (haven’t tried this myself, though) </p>
BR replied

Setting time range 3 and 4 quantities to zero at the output steps has been introduced especially for the climate mode lbdclim=.TRUE. . This has been done to prevent numeric overflows due to summing up over long time periods. Up to now it is not possible to use time range 3 and 4 quantities in more than one gribout namelist section. There are two work arounds that come to my mind you may consider:

1. If you are using a chain job that runs month by month, use a 15 min output for the whole region and write some lines to cut out the time (hourly for the whole region) and space (for the 15min output) you need in a post processing at the end of each month (preferably using the ncks program from the NCO -Libray, you may also use CDO commands, but be aware that CDO corrupts your netCDF CF-Conventions.). If you are using subchain you can do this in the post.job.tmpl .

2. If your simulation period is not too long you may comment out the lbdclim=.TRUE. if-branches in src_output.f90 . Hope this works (haven’t tried this myself, though)

View in channel