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

in #9: CCLM

<p> Hi everyone, </p> <p> I have the following problem with <span class="caps"> CCLM </span> (5.0): </p> <p> For our project, we want to store certain variables on a high temporal resolution for a subdomain, while simultaneously storing these same variables on a lower temporal resolution for the full model domain. This would save us a considerable amount of storage space. </p> <p> However, when configuring the model output like this, the output for averaged variables (like <span class="caps"> TOT </span> _PREC, or <span class="caps"> ASHFL </span> _S) is incorrect. E.g., when asking the output every 15 minutes in folder out02 and every hour in folder out03, output values are correct for the out02 files but are empty for the out03 files. Similarly, when asking the output every hour in out02 and every 15 minutes in out03, every fourth out03 file is empty and the hourly out02 files only contain the values for the past 15 minutes. </p> <p> Apparently, <span class="caps"> CCLM </span> resets all averaged variables (probably every variable on this list [http://www.clm-community.eu/frames/vartab/vartab4.8_clm19/index.php] that does not have have a Time Range Indicator of 0) to zero every time they are written to an output stream. </p> <p> Does anyone know a way to circumvent this problem? I’m sure others have wanted to do something similar with their output (i.e. store variables on a smaller domain for a higher temporal resolution). </p> <p> Thanks, </p> <p> Sam Vanden Broucke <br/> PhD student, KU Leuven </p>

  @samvandenbroucke in #8a6bf00

<p> Hi everyone, </p> <p> I have the following problem with <span class="caps"> CCLM </span> (5.0): </p> <p> For our project, we want to store certain variables on a high temporal resolution for a subdomain, while simultaneously storing these same variables on a lower temporal resolution for the full model domain. This would save us a considerable amount of storage space. </p> <p> However, when configuring the model output like this, the output for averaged variables (like <span class="caps"> TOT </span> _PREC, or <span class="caps"> ASHFL </span> _S) is incorrect. E.g., when asking the output every 15 minutes in folder out02 and every hour in folder out03, output values are correct for the out02 files but are empty for the out03 files. Similarly, when asking the output every hour in out02 and every 15 minutes in out03, every fourth out03 file is empty and the hourly out02 files only contain the values for the past 15 minutes. </p> <p> Apparently, <span class="caps"> CCLM </span> resets all averaged variables (probably every variable on this list [http://www.clm-community.eu/frames/vartab/vartab4.8_clm19/index.php] that does not have have a Time Range Indicator of 0) to zero every time they are written to an output stream. </p> <p> Does anyone know a way to circumvent this problem? I’m sure others have wanted to do something similar with their output (i.e. store variables on a smaller domain for a higher temporal resolution). </p> <p> Thanks, </p> <p> Sam Vanden Broucke <br/> PhD student, KU Leuven </p>

Problem when writing averaged variables for multiple temporal resolutions

SV wrote

Hi everyone,

I have the following problem with CCLM (5.0):

For our project, we want to store certain variables on a high temporal resolution for a subdomain, while simultaneously storing these same variables on a lower temporal resolution for the full model domain. This would save us a considerable amount of storage space.

However, when configuring the model output like this, the output for averaged variables (like TOT _PREC, or ASHFL _S) is incorrect. E.g., when asking the output every 15 minutes in folder out02 and every hour in folder out03, output values are correct for the out02 files but are empty for the out03 files. Similarly, when asking the output every hour in out02 and every 15 minutes in out03, every fourth out03 file is empty and the hourly out02 files only contain the values for the past 15 minutes.

Apparently, CCLM resets all averaged variables (probably every variable on this list [http://www.clm-community.eu/frames/vartab/vartab4.8_clm19/index.php] that does not have have a Time Range Indicator of 0) to zero every time they are written to an output stream.

Does anyone know a way to circumvent this problem? I’m sure others have wanted to do something similar with their output (i.e. store variables on a smaller domain for a higher temporal resolution).

Thanks,

Sam Vanden Broucke
PhD student, KU Leuven

View in channel
<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
<p> Thanks for that clarification! </p> <p> It seems like adding a post-processing step is the best option for us. </p>

  @samvandenbroucke in #dc06fa6

<p> Thanks for that clarification! </p> <p> It seems like adding a post-processing step is the best option for us. </p>
SV replied

Thanks for that clarification!

It seems like adding a post-processing step is the best option for us.

View in channel