Replacing 1-hourly precipitation data with daily precipitation data from another source in CLM5 simulation

[Chiru]

Hello everyone, I am currently running a CLM5 simulation using my own atmospheric forcing data at 0.1-degree resolution with a 1-hour temporal resolution. I would like to replace the 1-hourly precipitation data with daily precipitation data from another source.

My question is, do I need to change the temporal resolution of the other forcing variables from hourly to daily before running the simulation? Or can I keep all other variables except precipitation at an hourly resolution and still run the model? I would appreciate any insights on this matter.

 

[oleson]

It seems like one way to do this is to simply replace the hourly precip data in the forcing file with your daily data, right? (replace each hourly value in a day with the daily value).
Otherwise, is all of your forcing data in one stream? If so, you'd need to separate out the precipitation stream from the other forcing variables. For example, this is what is done with GSWP3V1 forcing data, where precipitation is its own stream, solar is its own stream, and temperature, humidity, etc is another stream.

 

[erik]

As @oleson points out you can have different temporal frequencies on forcing variables if they are on different files (streams). So if you have a separate stream for your daily precipitation data you'll be fine. You'll need to adjust the list of variables on the streams for what you have on your files.

 

[Chiru]

Dear @olsen and @erik,

Thank you for your previous insights. I have another question related to my CLM5 model. I am using the GSWP3V1 forcing data format with 0.1 degree resolution and 1 hourly temporal scale, and I have separate stream files for precipitation, solar, temperature, humidity, etc. I recently changed the precipitation forcing data in the 'user_datm.streams.txt.CLMGSWP3v1.Precip' file to include 0.1 degree with daily temporal scale instead of 0.1 degree with hourly temporal scale. However, I received an error message while running the model: 'ERROR: (shr_stream_getCalendar) ERROR: nf90_inq_varid'.

I performed ncdump -k on my forcing data and found that 'Solar' and 'TPHW' were in netCDF-4 classic model, while 'Precip' was in classic format. I have attached the ncdump -h of my forcing files for reference.

I would appreciate any suggestions on how to resolve this issue. Thank you in advance for your help.

 

[Chiru]

I am also attaching stream files.

 

[Chiru]

I am attaching the error files that are relevant to the issue I am facing.

 

[oleson]

What version of CESM/CLM are you using (what is the output of git describe in your code base?)?
In more recent versions of CESM/CLM, files must not be in netCDF4 format.

 

[oleson]

I see that your precip file has "TIME" instead of "time". Not sure if this is a problem, but you might try changing this to "time". The other forcing files have "time".

 

[Chiru]

Dear @oleson,

What you said is that right, now, I changed the time in my Precip files like the rest of the data set and ran the model, however, now I am getting a different error as

WARNING: water balance error nstep= 1 local indexc= 373213 WARNING: water balance error nstep= 1 local indexc= 260093 WARNING: water balance error nstep= 1 local indexc= 267871 WARNING: water balance error nstep= 1 local indexc= 313442 WARNING: water balance error nstep= 1 local indexc= 366992 WARNING: water balance error nstep= 1 local indexc= 319450 errh2o= 1.340911683200829E-005 errh2o= -4.134822290779994E-006 errh2o= 6.627283894999891E-006 errh2o= 2.022933500711588E-007 errh2o= 3.174309924247609E-006 errh2o= 2.134833025024818E-006 WARNING: water balance error nstep= 1 local indexc= 39656 errh2o= 2.444304982418544E-006 ERROR: capping procedure failed (negative mass remaining) c = 164222 h2osoi_ice_bottom = 2.773862797766924E-005 h2osoi_liq_bottom = -1.011345033326977E-012 calling getglobalwrite with decomp_index= 164222 and clmlevel= column local column index = 164222 global column index = 327961 global landunit index = 141927 global gridcell index = 49997 ERROR: capping procedure failed (negative mass remaining) c = 370694 h2osoi_ice_bottom = 3.272210233262740E-005 h2osoi_liq_bottom = -7.320955907469395E-014 calling getglobalwrite with decomp_index= 370694 and clmlevel= column


"I think the water balance errors in my model might be due to the precipitation data only covering the area within the India shapefile." I am unsure how to include my precipitation data, which is limited to this area, in the rest of the domain of my model. I would appreciate suggestions on generating precipitation data that covers the entire domain of my simulation.

I am attaching error files, ncview images of precipitation, and the rest of the data for your reference.

I am using cesm2.2.0 (CLM 5 for my simulations).

 

[Chiru]

error files

 

[oleson]

Since your precip data is not "global" (valid data for every grid cell in your domain), you'll need to generate and use a different domain file for the precip stream that has "mask" values of 1 where there is valid data and values of 0 where there is missing data. It looks like you are using the same domain file for all three streams. On the other hand, if the domain you are trying to model has land points that are outside of the available precip data, you may end up with some strange forcing data for these land points as the datm will interpolate based on the closest grid cells with valid forcing data.

 

[Chiru]

Hello , @Oleson

As suggested by you I have made the mask =0 where I don't have valid precipitation data which can seen from below images and I have given same domain file in 3 stream files. Now When I am trying to run the simulation from 2001-07-01 to 2001-07-20 for 20 days the model ran for 14 days after that my simulation failed by showing the following error

WARNING: water balance error nstep= 308 local indexc= 223897
errh2o= 3.608874976634979E-009
WARNING: water balance error nstep= 308 local indexc= 215753
errh2o= 1.352964318357408E-008
WARNING: water balance error nstep= 308 local indexc= 99471
errh2o= -5.238689482212067E-009
WARNING: water balance error nstep= 308 local indexc= 80195
errh2o= -4.154571797698736E-009
WARNING: water balance error nstep= 308 local indexc= 118342
errh2o= 1.084117684513330E-008

my cesm.log.* file is size is more so I am sharing the link to the life please find it.

https://csciitd-my.sharepoint.com/:f:/g/personal/cez218275_iitd_ac_in/EqMN6HVbMetAgd7pW7SSvPAB1vhsGdxsUORot-iEW0UrsQ?e=giJum5

Kindly help me in overcoming this error. Thanks

 

[Chiru]

PFA

 

[slevis]

Dear @Chiru,

1) The "WARNING: water balance error" message appears to be a model warning (not an error that causes a crash), which distracts from the real problem. Here is how I determined that:

a) The warnings appear in the cesm.log from the beginning of the simulation, long before the crash.

b) The traceback at the end of the cesm.log points you to line 3561 of SnowHydrologyMod.

c) Scroll some lines up in the cesm.log and you will see:

ERROR: capping procedure failed (negative mass remaining) c = 159876
h2osoi_ice_bottom = 1.746391353663057E-005 h2osoi_liq_bottom =
-4.059418274617033E-013
calling getglobalwrite with decomp_index= 159876 and clmlevel= column
local column index = 159876
global column index = 241284
global landunit index = 94112
global gridcell index = 28563
gridcell longitude = 75.8500000000000
gridcell latitude = 36.1500000000000
column type = 215
landunit type = 2
ENDRUN:
ERROR: ERROR in SnowHydrologyMod.F90 at line 3561

I don't know if the lon/lat are within the domain that you intended to simulate.
I don't know what may cause the negative h2osoi_liq_bottom.

d) The atm.log ends with:

(shr_dmodel_readstrm) file ub: /scratch/civil/phd/cez218275/IMDAA_025_deg_2000_2001/Solar/Regrid_ncum_imdaa_reanl_HR_DSWRF-sfc_2000010100-2000123123.nc 4686
(shr_dmodel_readstrm) file ub: /scratch/civil/phd/cez218275/IMDAA_025_deg_2000_2001/TPWL/regrid_ncum_imdaa_reanl_HR_TPWL_2000010100-2000123123.nc 4686
(datm_comp_run) atm: model date 20000714 19800s
(datm_comp_run) atm: model date 20000714 21600s
(shr_dmodel_readstrm) file ub: /scratch/civil/phd/cez218275/IMDAA_025_deg_2000_2001/Solar/Regrid_ncum_imdaa_reanl_HR_DSWRF-sfc_2000010100-2000123123.nc 4687
(shr_dmodel_readstrm) file ub: /scratch/civil/phd/cez218275/IMDAA_025_deg_2000_2001/TPWL/regrid_ncum_imdaa_reanl_HR_TPWL_2000010100-2000123123.nc 4687
(datm_comp_run) atm: model date 20000714 23400s

If this is truly the last output from the atmosphere (which it may NOT be if some output remained in a buffer and didn't make it to the atm.log), then the negative h2osoi_liq_bottom may be caused by some inconsistency in one or more of the last datm files read by the model.

2) The investigation in (1) is an example of the first steps of troubleshooting that you may need to perform to resolve this and other model errors.

@Chiru I would like to take this opportunity to make a kind request of everyone on the CESM forum:
Please spend time troubleshooting things yourself before turning to the forum for help. I say this for two reasons:
1) All model users and model developers (including the most experienced) run into problems when they try new things. The way you become truly experienced is by troubleshooting things that don't work. This forum is good for posting questions if you have spent time troubleshooting and are still stuck.
2) The number of model users is constantly increasing (this is good) and @oleson and I already answer dozens of questions per week. Ideally we should only need to answer questions for users who cannot make progress in their work after all their troubleshooting.

@Chiru I apologize if my comment does not apply to you and you already did significant troubleshooting before posting the last question, and please understand that I am trying to make this point as tactfully as possible.

Sincerely,
Sam Levis

 

[Chiru]

Dear @Sam Levis,

I want to express my sincere gratitude for your detailed response and troubleshooting guidance. Your efforts in addressing my query are greatly appreciated.

I apologize if my question appeared premature, and I do understand the importance of troubleshooting before seeking assistance on the forum. Despite my attempts to troubleshoot, I couldn't find a solution, which led me to seek help. However, the troubleshooting steps you provided have been incredibly valuable, and I'm grateful for your guidance. I will keep them in mind for future reference.

Once again, thank you very much for your support and expertise.

Best regards,
DEVAVAT CHIRU NAIK