Questions about calibration using PyWrfHydroCalib

[ERICK RAUL OLVERA PRADO]

Dear WRF-Hydro Community,

I have started setting up a calibration exercise using the PyWrfHydroCalib tool in my region of study (Papaloapan river watershed), which I described in a previous email. During the process, I came out with a question and a technical issue, and I'd like to know if you could provide feedback on it:

1. What would be more convenient when setting up the date ranges for spinup, calibration and validation periods, when the time period of my simulation is only one month (June 2012)? I have seen other cases when simulation times are, for example, 2 months (or longer) that the time can be splitted into ~2 months for spinup, ~1 month (first month) for calibration and  ~1 month (second month) for validation. Is it advisable to run at least for another month? or is it still feasible to do it with one?

2. I have been able to 1) Initialize a database, 2) input the domain meta and 3) initialize the batch job. When I run the PyWrfHydroCalib/spinOrchestrator.py, an error message appears in the WH_4_1.err file about “Cannot match namelist object name imperv_option” between, it seems, the setup.parm and namelist.hrldas files. I noticed that my original namelist.hrdlas does not have the “IMPERV_OPTION” line in the Physics option section, since I am using the WRF-Hydro v5.2.0 version of the source code (compared to the newest one), but I am not sure if this is the real reason of the problem. Is it necessary to use the last version of the wrf-hydro source code (v5.4.0) with PyWrfHydroCalib? or is there any way to solve this issue with my current setup? 

I have attached some relevant configuration and log files in case they are of some help to better diagnose this problem.

Please let me know if I need to provide further information about my experiment.

Many thanks in advance for your help.

Best,

Erick Olvera

[Arezoo RafieeiNasab]

Hello, 

As for the first question regarding the duration, we usually do multiple years for spinup, calibration and validation individually. At least a couple of years for each. If you are interested in fine tuning an event, maybe just a month works, however, there is a high chance transferring the parameters to a different time period results in poor model performance or strange behaviour, as you fine tune the model only to a single or a few short events. We recommend the calibration should be long enough that the model sees different conditions during the calibration process. However, many users limit the calibration period due to the computation cost and the time needed. 

As for your second question, if you do not want to use the most recent WRF-Hydro code you could use this version of the calibration code attached here. This version does not have the new capabilities, but will be compatible with the model version you are using. Please use the example setup file in this code, which has less options compared to the one you are currently using. Please let me know if you run into any issues!

Thanks!

Arezoo

--
You received this message because you are subscribed to the Google Groups "wrf-hydro_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wrf-hydro_use...@ucar.edu.
To view this discussion visit https://groups.google.com/a/ucar.edu/d/msgid/wrf-hydro_users/05b06f22-9c0d-455b-8cc7-a417c8a30809n%40ucar.edu.

--

-------------------------------------------------------------------------------------------------

My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.

-------------------------------------------------------------------------------------------------

Arezoo Rafieei Nasab, Ph.D.

Project Scientist II

NCAR Research Applications Laboratory

are...@ucar.edu

[ERICK RAUL OLVERA PRADO]

Hello Arezo,

Many thanks for your responses. I have defined longer spinup, calibration and validation time periods to 2 months each (may-october 2012) for now, but will be working on generate a longer record

of atmospheric forcing input files. 

On the other hand, I have been able to run the spinup step using the beta version of the calibration code. When I run calibration step with calibOrchestrator.py, a first run is conducted but then in the 

WH_CALIB_7_1.err log file appears the error message:

 Error in quantile.default(x_archive$obj, 0.9) :
  missing values and NaN's not allowed if 'na.rm' is FALSE
Calls: quantile -> quantile.default

After a little research, I found that it may be due to icompatibility between the no_site field in the obsStrData.Rdata observation file and the featured_id field related to the streamflow gauge location.

For now, the no_site is an arbitrary label that correspond to the gauge number, but it is not the same as the featured_id defined in the CHANOBS output file, and wanted to ask your opinion before

modifying the obsStrData.Rdata.

Do you think this is the reason of the issue? As I mentioned above, I know the featured_id of my gauge from the CHANOBS output file but I am not sure if this parameter is the same as in 

the CHRTOUT_DOMAIN*.nc output files.

I attach the obsStrData.Rdata file and the log file in case they are useful. Please let me know if I can provide more information about the experiment.

Best,

Erick

[Arezoo RafieeiNasab]

Hi Erick, 

I checked the setup file you shared earlier, and that indicates you are using the diffusive wave routing option for channel routing. 

# Channel Routing    
# 1: Muskingam-reach
# 2: Muskingam-Cunge-reach
# 3: Diffusive Wave-gridded
chanRtOpt = 3

In this case, the feature_id in the CHANOBS files is the integer numbers in the variable "frxst_pts" in the Fulldom_hires.nc file. Therefore, the site_no in the obsStrData.Rdata file should match the "frxst_pts" value for the location of interest. CHANOBS file only has the streamflow values at the gauge location, whereas the CHRTOUT files provide the streamflow estimates at all the channel grids in the domain. In case of calibration workflow, we only need and read the CHANOBS files, so you could ignore CHRTOUT files and not output them. 

I hope this helps! Please let me know if you have any questions, or there is any confusion. 

Arezoo

[ERICK RAUL OLVERA PRADO]

Hi Arezo,

Many thanks for the clarification. I modified the site_no in the obsStrData.Rdata file to match the feature_id defined in my "frxst_pts". After the modification, another message error about 

"Incompatible data types: x.site_no (double) and i.site_no (character)" appeared, then, I changed the data type of the site_no from num to char and the message dissapeared. However, the

old message "Error in quantile.default(x_archive$obj, 0.9) :" appeared again. At this point I am not sure what could be the reason, I share some simulation specifications in case they are 

relevant to find the issue:

• My observational data (obsStrData) is daily streamflow (see the obsStrData.Rdata file attached previously), while the model output frequency is hourly.
• Therefore, the POSIXct field is something like "2012-07-01", I show the output of the str(obsStrData) command so you can see the datatypes. I am not an R user and searched for some help to convert from my original csv file to .Rdata. Perhaps in some step something funky happened:

> str(obsStrData) tibble [184 × 3] (S3: tbl_df/tbl/data.frame) $ site_no: chr [1:184] "1" "1" "1" "1" ... $ POSIXct: POSIXct[1:184], format: "2012-05-01" "2012-05-02" "2012-05-03" "2012-05-04" ... $ obs : num [1:184] 186 185 184 184 182 ...

Many thanks in advance, let me know i f I can provide further information.

Best,

Erick