model_TFN_SW_GW #53
Open
model_TFN_SW_GW #53
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 30 commits
March 31, 2021 17:45
"solve is calling back objectiveFunction that calls calibration_initialise, maybe take calibration_initialise ouside of objectiveFunction???
…orcing from "baseflow" instead of "climateTransform_soilMoistureModels"..
…ow and then total flow calculation
…daily obs. head, daily obs. flow data for Brucknell, Ford, Sunday Creek
…uce different obj-function values for the head (SSE) but not to flow, which is constant at 2.3*10^5 (SSE)
…)" in order to include set the "obj.variables.isNewParameters" as true and force the recalculation of quickflow using "forcingTransform_soilMoisture"
…w. Baseflow is sensitive to new parameter sets but most of the inputs result in zero baseflow because of high head_threshold values. When head_threshold is below the simulated GW head, baseflow seems to be too high and produce large RMSE for total flow. No major structural changes to model_TFN_SW_GW were done yet (i.e. gw obj-function is calculated first by running objectiveFunction in model_TFN for the dates with obs. gw head and later getStreamflow solves the soil model using "solve" in model_TFN with "doingCalibration = false" and later extracts both simulated head, which is passed to "baseflow" object to calculate baseflow, and runoff (quickflow) to calculate the total flow. TO DO: try objectiveFunction in model_TFN with "doingCalibration = false" and calculate obj-function for both head and flow (calling "baseflow" obj. and everything else) inside of "objectiveFunction_joint" to see if quckflow becomes sensitive to new parameter sets.
… inside of model_TFN_SW_GW as initially in the code.
…ifferent parameter sets generated by AMALGAM.
…eter sets and performance for the current model structure.
…ntrols soil infiltration rate and runoff production) for all bores in Brucknell to see if differences arise between bores using 100k iterations. Previous test suggest that >300k are necessary to push the Pareto front though.
…t of the suit of options. Started to create a new baseflow object, called baseflow_v2.
…ng setTransformedForcing in getStreamFlow in model_TFN_GW_SW. Need to improve this to automatically call the correct object as we change the climateTransform object/method.
…nsform_soilMoisture.c" and "climateTransform_soilMoistureModels.m" and "climateTransform_soilMoistureModels_2layer.m"
…ld, as per Kavestki 2003, Kalma 1995, Woods 1992, was successfully implemented in the C code and climateTransform_soilMoistureModels.m. Baseflow_m4 was corrected to use 1/head instead of head as input. Now running in Spartan.
…lpha)) to handle eps threshold, in both C code and climateTransform_soilMoistureModels.m. No changes to climateTransform_soilMoistureModels_2layer.m cause eps assumed as zero for deep layer. So, i did not include 'infiltration_fractional_capacity' in L873 in soilmodel_2layer.m cause it is not used in layer-2. Added 'infiltration_fractional_capacity' flux in climateTransform_soilMoistureModels.m to check if new SoilMoisture model is behaving as expected, particularly in terms of eps threshold. This is also used to calculate "infiltration". However, "infiltration_fractional_capacity" is not showing up as a option to plot in the GUI.... Also, eps=zero as default for layer-1 soil model.
…c into folder algorithms/models/TransferNoise/original_MEX_files. Now will compile the new forcingTransform_soilMoisture.c as MEX_file using Build_C_code.m or a different procedure.
…oosing the original MEX files in the case of a bug.
…mpiled into forcingTransform_soilMoisture.mexw64 using the standard MATLAB compiler (MATLAB Support for MinGW-w64 C/C++ Compiler)
…the new C code or compilation software. As the tests, the software runs without any issue is using the old compiled C code.
… soil moisture ODE, which in turn produces the inputs necessary to calculate flow and head objective functions, and also to avoid calling setTransformedForcing multiple times, I will merge getStreamFlow with objectiveFunction_joint in model_TFN_SW_GW. The use of different length of time-points can be causing issues in the results.
…l-moisture model first to obtain the simulated head used to calculate the head objective-function and baseflow, which uses all forcing data prior to obs. head as per the default of HydroSight ("solve", "objectivefunction", "h_star"), and THEN SOLVES AGAIN again the soil-moisture model only for the days with streamflow observations to then obtain the runoff that is used to calculate total flow and flow objective function ("setTransformedForcing"). THEREFORE, I WILL CHANGE THE APPROACH, AND SOLVE THE SOIL-MOISTURE MODEL ONLY ONCE, AS PER THE DEFAULT HYDROSIGHT METHOD (WITH ALL FORCING DATA PRIOR TO OBS. HEAD) AND FROM IT EXTRACT THE RUNOFF FOR THE DAYS WITH OBS. FLOW. CODE ALREADY HAS SOME PRELIMINARY MODIFICATIONS, BUT STILL RUNS WITH THE INITIAL STRUCTURE AFOREMENTIONED.
…esting and later implementation of convolution.
…ey might need adjustment in the range of the plausible and physical range of the parameters but they seem to be working properly. Now starting to implement the convolution of runoff and baseflow using the same flexible pearson III transfer function used for the interpolation of Head hydrographs.
…rst using as much as possible of the current convolution structure and workflow.
…another soil-moisture object for the cases where interflow has storage and losses (using the same code architecture as the deep soil moisture model). Deleted a soil-moisture object that I initially created for adding episilon but which was not necessary as keeping eps=0 is equal to the old soil model.
…thout storage). Now I need to test it, but first, I'll try to implement hypothesis 3-5 (no ET losses and infinite storage, no ET losses and finite storage, with ET losses and finite storage).
…2layer.m". Implemented hypothesis 3-5 for the interflow formulation in "climateTransform_soilMoistureModels_interflow", however, need to do many tests, and particularly double-check if the infiltration/runoff formulation-balance is correct and there is no double-counting of mistake in the formulation, both in terms of code and conceptually.
… to be working properly. Now I need to do test it with different fixed parameters to test hypothesis 3-5. Also, need to test "climateTransform_soilMoistureModels.m" to see if it runs and is possible to test hypothesis 1-2.
…into "climateTransform_soilMoistureModels_interflow" in order to allow ET from interflow to be zero and the option to have a minimum interflow soil moisture threshold that has to be exceeded in order to have saturation excess runoff... Now implementing the mass-balance formulation which will reject paramater sets in AMALGAM by setting the ObJ-Fun to Infinity if total baseflow is larger than free drainage to groundwater.
…ncorrectly set, particularly eps_interflow). Now working on the free-drainage/baseflow mass-balance criteria.
…rainage >= baseflow" in model_TDN_SW_GW. Now, in example_TFN_SW_GW.m, I'm hard-coding the head_threshold parametr in params_upperLimit and params_lowerLimit to be within +- 5m of the observed GW range, that way, we avoid AMALGAM excessively exploring parameters that make baseflow=0.
… be used in AMALGAM according to +-5m of the range of observed GW head. Also included dynamic X-axis date ticks for some plots using Intelligent Dynamic Date Ticks (https://au.mathworks.com/matlabcentral/fileexchange/27075-intelligent-dynamic-date-ticks). Now focusing on how to automatically generate plots for hydrographs and ETC for the paramater set that represents the best-compromise between SW and GW ObjFun in the last iteration of AMALGAM.... Any ideas from Keir?
…automatic generation of plots is make ObsFlow as an input to model_TFN_SW_GW in the form of a double-table array the same way as ObsHead, and include two flags into objectiveFunction_joint method (GeneratePlot (0,1), ScenarioName (string)) which will activate the generation of plots and store them according to ScenarioName and current datetime (i.e., Brucknell_Scenario1_ 07-27-2021 20-37). ScenarioName will be the flag to choose both the ObsFLow data (obsFlow_Brucknell.csv, obsFlow_Sunday.csv), ObsHead data (e.g. bore_WRK961324), baseflow method (i.e. baseflow_m7, baseflow_m9) , soil moisture model hypothesis (i.e., if climateTransform_soilMoistureModels_v2 or climateTransform_soilMoistureModels_interflow, and their respective parameters for the different interflow formulations). Main risk: can i change model_TFN_SW_GW accordingly without breaking its inheritance from model_TFN?
…at was assigning the incorrect lower-upper bounds to alpha_interflow as well as incorrectly transforming to 10^parameter in the case of eps_interflow and alpha_interflow. This was creating incorrect estimations of parameters by AMALGAM as well as producing mostly invalid parameters according to the physical validity criteria.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi Tim,
Hope all is well. :)
As promised, this is a clean version of the current state of HydroSight_SW_GW. Hopefully, it is not messy and possible to use in the master branch.
The main differences are:
Many thanks,
Giancarlo