wflow calibration problem

[Xervou]

I used wflow julia to build a model with a 20-meter resolution.

I selected the Taiwan government's open 20-meter DEM data for creation.

The wflow version is 0.6.2. After importing it into FEWS to check the peak runoff, I found a significant difference compared to the observed values. Subsequently, I tried changing the values of f, soil thickness, KsatHorFrac, and infiltcapsoil, but only when modifying soil thickness did the simulation values change. When the other values were modified and re-simulated, the results remained the same as the original default settings.
I have read the previous questions but found that the problem has not been solved and want to ask where the problem might be?

Since I'm not very familiar with the necessary content, please let me know if there's any missing information, and I will add it.

[verseve]

Hi @Xervou , Thanks for your question.

The model has a quite high resolution. If slope values are high (for a large part) in your model domain it may be possible that model cells are drained (too) quickly by large lateral subsurface flow fluxes., mainly controlled by high slope values.

You could check the water table depth zi or satwaterdepth variables to see if this occurs. However, I would expect that higher f values or lower KsatHorFrac values (resulting in lower lateral subsurface flow fluxes) would have an impact on the hydrograph. Is only peak runoff not changing, or is this the case for the complete hydrograph when you change f, KsatHorFrac, and infiltcapsoil? For the complete hydrograph it is expected that f and KsatHorFrac have an effect (these are sensitive parameters). In what range did you modify these two parameters? Additionally it may be good to check if wflow picked up the modified parameters f and KsatHorFrac correctly (to check if there is not a issue with mapping these parameters in the TOML file).

Soilthickness estimated with hydromt_wflow (maximum thickness is 2.0 m) can be considered as a first estimate, and for areas with a 2.0 m thickness it may be useful/appropriate to increase the thickness, especially if soil storage is limiting, which could also cause too high peak values. Also, the estimate of the residual water content in hydromt_wflow has been fixed recently (these values were too high for clayey soils), which could also result in limiting soil storage if your model was setup with an older version of hydromt_wflow.

[Xervou]

Hi, I am currently confirming if the model is unchanged only on the peak traffic part. In addition, I noticed that only during periods of heavy rainfall did the runoff deviate significantly from the observed values, and the runoff dropped very quickly. I wonder if the problem is caused by the soil absorbing and draining water too quickly. I wonder if you can ask me how to confirm this problem and further adjust the parameters related to soil drainage?

In addition, I did not find the two parameters zi and satwaterdepth in the toml file and outstatic.nc files. I wonder if I can ask how to view and use these two parameters?

[verseve]

zi and satwaterdepth are model output variables, You can add these to the TOML file:

[output.vertical]   # Mapping of names between internal model components and external netCDF variables
satwaterdepth = "satwaterdepth"
zi= "zi"

If land slope values are large, the soil is indeed probably draining too quickly, especially with the default parameter of ksathorfrac (100.0). Besides decreasing ksathorfrac, increasing the f parameter also may help.

If during peak runoff also flooding occurs, the kinematic wave approximation is not the best choice as flooding is not (yet) possible with this solution. To include flooding, you could consider to switch to the local inertial method that has an optional 1D floodplain schematization for river flow (added in v0.6.3).

I also would advice to use the latest version of wflow (v0.8.1).

Finally, you are using a model resolution of 20.0 m. At what model timestep are you running the simulations? The kinematic wave for lateral subsurface flow is solved at the model timestep (no internal timestep) and may give less accurate results for certain dt/dx combinations.