5-Minute vs Hourly ParFlow.CLM Simulations

16 views
Skip to first unread message

Zahra Amiri

unread,
Sep 8, 2025, 5:58:14 PMSep 8
to ParFlow

Hi everyone,

I’m a postdoc at CU Boulder and I've been using ParFlow.CLM with weather forcing inputs at both hourly and 5-minute intervals. The reason we wanted to use 5-minute forcing was to incorporate urban irrigation occurring at a sub-hourly timescale.  To test the setup, I ran the model for a month with each time scale, and found higher water balance errors at the 5-minute timescale than the hourly timescale, which we suspect is related to the time setting of CLM.  Specifically:

1. Hourly forcing dataset: The cumulative water balance error for both CLM and ParFlow is very low. At 189 h:

CLMabsErr_cum (Cumulative absolute error calculated from CLM outputs) = 0 mm, CLMrelErr_cum (Cumulative relative error calculated from CLM outputs) = 0

 

I calculated the CLM error as follows:

CLMforce_cum = precip_cum (cumulative precipitation)

CLMcalc_cum = dcan_cum (cumulative canopy interception) + dsno_cum (cumulative snow water equivalent)  + ev_cum (cumulative evaporation) + tr_cum (cumulative transpiration)  + etS_cum (cumulative EvapTranssum output)

CLMabsErr_cum = CLMforce_cum - CLMcalc_cum

CLMrelErr_cum = CLMabsErr_cum/CLMforce_cum

 

2. 5-minute forcing dataset: The input is based on 5-minute forcing dataset and the model printed hourly outputs. At 189 h:

CLMabsErr_cum = 0.04 mm, CLMrelErr_cum = 0.004

For ParFlow with the 5-minute simulation, we used these time settings:

#------------------------------------------------------------------------------------------

# Timing Information

#------------------------------------------------------------------------------------------

pfset TimingInfo.BaseUnit                             0.08333333 #(5min/60 min)

pfset TimingInfo.StartCount                           0

pfset TimingInfo.StartTime                            0

pfset TimingInfo.StopTime                             744 # (31 days *24 h)

pfset TimingInfo.DumpInterval                           1

pfset TimeStep.Type                                   Constant

pfset TimeStep.Value                                  0.08333333

 

For CLM, the only adjustment I made was:

 

pfset Solver.CLM.CLMDumpInterval                      1 # hourly output

 

In both cases, the ParFlow time unit in the tcl is hour. I couldn't find a key in the manual that explicitly defines the CLM time step, and assumed initially that the CLM time step comes from the ParFlow time step. I am wondering if CLM can properly handle sub-hourly weather forcing.  I found only 2 examples of previous work that used sub-hourly ParFlow.CLM simulations:

1 – Gupta, A., et al. (2019), with tcl file and repository we referred to.  2- Baroni, G., et al. (2019).

 I would appreciate any suggestions or recommendations on using sub-hourly weather forcing for CLM.

I've also attached the tcl file, and drv files for your reference.

 

Thank you,

Zahra Amiri

Postdoctoral Associate

Department of Civil, Environmental, and Architectural Engineering

University of Colorado Boulder

drv_clmin.dat
PF_P1_M5_2017_5min_1D.tcl
drv_vegm.dat
drv_vegp.dat

Reed M. Maxwell

unread,
Sep 8, 2025, 7:38:37 PMSep 8
to ParFlow
CLM runs at whatever time step parflow uses, so if you set the TimeStep value key to something less than an hour CLM will run with that timing.  You probably need to set both your DumpInterval values (for parflow and for clm) to something other than 1.0 (the default).  A negative value of the DumpInterval keys will write output in every n times, so -1 writes at every tilmestep, -2 every other etc.  Example:
<runname>.TimeStep.Value          = 0.25
<runname>.TimingInfo.DumpInterval = -1
<runname>.Solver.CLM.CLMDumpInterval = -1

image.png

My guess is that you are running at 5min time steps but outputting every hour, so you will miss dynamics (irrigation etc) by skipping the output times and this will lead to the increased water balance errors you are seeing.  If you output every time step you wont miss changes in the fluxes and pressures and this should reduce the error.

Note that the python parflow key database may try to check your keys and has an incorrect lower value for the CLMDumpInterval and you might have to turn off the key validation.  You do this during the run command using the skip validation option:
skip_validation=True
<runname>.run(working_directory=None, skip_validation=True)

 

--
You received this message because you are subscribed to the Google Groups "ParFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parflow+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/parflow/23194e24-ab03-4123-9fd5-d09024441971n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages