Silly question on PF time control and CLM time control when restarting

[felipe9023]

Dear all

I am currently working with PARFLOW-CLM in a West African domain. I have a silly question regarding time control in a CLM-PF simulation when I want to restart a simulation. 

Originally, I run a simulation with 0.5 h time step, with outputs every 24h for PF and CLM. I decided to change and run an alternative sim. with 3h time step, to save on computational time, while maintaining all the rest.

My original simulation with restart uses then as configuration:

pfset TimingInfo.BaseUnit        0.5
pfset TimingInfo.StartCount      100
pfset TimingInfo.StartTime       2400
pfset TimingInfo.DumpInterval    24
pfset TimeStep.Type              Constant
pfset TimeStep.Value             0.5
pfset TimingInfo.StopTime        2800

pfset Solver.CLM.IstepStart                              4801  ##(StartTime*2  + 1)

For copy restart CLM files, I use 4800 as well, i.e. I copy CONWA.2015.rst.00000.No_CPU  to  CONWA.2015.rst.04800.No_CPU.

For my 3h time step simulation then, I change pfset TimeStep.Value  from 0.5 to 3.0. Not other change. It means that I kept using the 0.5 time step number for CLM.IstepStart .

When I tried to restart the 3h simulation from day 100, I got an error message saying that time step 04800 was not found on the meteo forcing files (actually, it doesn't find file.DSWR.004801_to_005040.pfb). It is obvious, as I have far less time steps now that I am using 3h.

The question is then: Does IstepStart control the file Id that PF-CLM will use to look for inside the meteo folder ? Should I use the actual time-step number (in this case, 100 * 8 + 1 = 801)? Or the easiest thing to do is to give it a 1 as value ? 

Sorry for this silly question. Currently I am using the actual time step as IstepStart  and  IstepStart-1  as ID for the restart rst files. It works fine, the simulation run and the restart seem to be read just fine. But I want to be sure that it is calling the correct meteo file.

Best,

Pedro ARBOLEDA

Postdoc

CECC Project

IGE -IRD/UGA

Grenoble, France

[Reed M. Maxwell]

Hi Pedro,

 

Not a silly question. This trips people up the first time they change the time step on a restart, and the root of it is that two different counters both get called "istep."

 

There is a ParFlow counter and a CLM counter, on different clocks in your example (often to avoid confusion like this we set them to be the same, e.g. 1h).

 

The ParFlow counter is TimingInfo.StartCount. It counts dumps, advances by one every DumpInterval of real time, and names the press.NNNNN files. On a restart you set it to the last dump number.  In your case (positive) 24 which is real hours, e.g. 1d.

 

The CLM counter is Solver.CLM.IstepStart. It counts forcing records, names the CLM output, and drives the met file lookup. It advances by one every forcing interval, where the forcing interval is ReuseCount * TimeStep.

 

  forcing interval = ReuseCount * TimeStep      (must equal the real spacing of your met files, I can’t tell if this is 3h or 0.5h, see below)

  IstepStart       = StartTime / forcing interval + 1

  StartCount       = StartTime / DumpInterval

 

The important part for your change: IstepStart depends only on the forcing interval, not on how you split that interval between the time step and ReuseCount.

 

What I can’t figure out from your keys is the forcing interval itself, because you did not send the time spacing of your met files or ReuseCount. Two possibilities fit what you described, and they conflict with your original keys:

 

- Your forcing is 0.5 h. Then ReuseCount was 1, and 2400 / 0.5 + 1 = 4801 was right. You cannot drive a 3 h step from 0.5 h forcing, so for the new run you regenerated to 3 h forcing, ReuseCount stays 1, and 2400 / 3 + 1 = 801. This matches what you are doing.

 

- Your forcing was 3 h all along. Then the original 0.5 h run needed ReuseCount = 3 / 0.5 = 6, not 1, and IstepStart should have been 2400 / 3 + 1 = 801 there too, not 4801. In that case the original deck was reading the wrong records and just never threw an error (this can happen sometimes with forcing files).

 

So please send three numbers so we can help figure this out: the real time spacing of your forcing files, MetFileNT, and ReuseCount. Then apply ReuseCount * TimeStep = forcing interval and IstepStart = StartTime / forcing interval + 1. For a 3 h forcing interval that lands on 801 either way, so if your new files really are 3 h you are fine.

 

Two more consistency checks you can always do. The time step should divide DumpInterval evenly, 24 / 3 = 8, so you are fine, and check Solver.CLM.CLMDumpInterval the same way since it runs on its own clock (positive for time in h, negative for timesteps). The start date and hour in drv_clmin.dat should still point to the beginning of your forcing series.

 

To confirm the resolved indexing without guessing, two output files carry it in the open. The <runname>.out.log has a plain-text table, Sequence number, Time, dt, Dumpfile number, so you can read off the model time and dump number for any step. The <runname>.pfmetadata is JSON and records the timing along with, for 3D forcing, the CLM met indexing it actually used (istep start, MetFileNT, path, file, and the from_to range it builds the file name from). Both these files can help you figure this out and confirm timing.

 

Reed

--
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/4f74abea-a197-4a44-8797-b44ae4719559n%40googlegroups.com.

[felipe9023]

Thanks for your help Reed

So to be clear, each meteo file has 5 days data, but every one has more or less NT, depending on its time step. Below a table that summarize  all the important data by simulation :

                                                                         TimeStep 0.5h                                           TimeStep 3.0h

MetFileNT                                                      240                                                               40

ReuseCount                                                   1                                                                   1

ForcInterval=ReuseCount * TimeStep       0.5                                                                3       

StartTime                                                        2400                                                            2400                    

IstepStart                                                        4801                                                             801                   

So your guess was correct, and 801 is the correct IstepStart when using 3h time step. Thanks for the ReuseCount explanation, I haven't understood this part of the model. I will try to "automatize" these calculations to avoid errors.

Two additional questions regarding the restart:

First, regarding the .rst. files. I currently copy-paste the .rst. files using something like <Simulation>.rst.XXXXX.YYYYY where XXXXX is IstepStart -1 and YYYYY is the CPU number. Is it OK? Can I just use any number of the restart file number depends on IstepStart?

Second, is it possible to look for the exact name of the meteo files it will use ? I cannot access this info. on the pfmetadata file, and it would be a nice final check to do. After checking the pfmetadata, I just found:

"Solver.CLM.MetFileNT": "40",
                                "Solver.CLM.MetFileName":       "conwa",
                                "Solver.CLM.MetFilePath":       "/ccc/store/cont003/gen10147/arboledp/Reproj_3h_ERA5_L_2015",
                                "Solver.CLM.MetFileSubdir":     "True",
                                "Solver.CLM.MetForcing":        "3D",

Not sure if I must activate another key in the configuration to have more info.

Thanks for your help

Best,

Pedro