Implementing calibratable parameters in tomodel, using bmi.

[Ben-Choat]

Calibratable parameters in topmodel have secondary variables that need to be udpated when calibratable parameters are updated. This was not being done correctly. A first step in this direction was captured in a previous pull request where the init() function was refactored to smaller, clearer, and better organized functions. This PR applies those refactored functions within the Set_value function in bmi_topmodel.c to ensure secondary variables are correctly updated.

Additions

• Refactored init() functions were applied within the Set_value() function in bmi_topmodel.c to update secondary variables that are dependent on calibratable parameters.
• Print statements were added in topmodel.c and bmi_topmodel.c so they user can confirm the parameters are being read from the realization.json file and the values are as expected.
• the rv and chv parameters were added to the topmodel_model data structure so that they are accessible beyond the init function.

Removals

• NA

Changes

• reorder refactored functions to make better logical sense.
• reordered function inputs so that inputs come first and outputs come last
• improved commenting within edited regions

Testing

1. Results with new build (this PR) and results from original build (master branch) were identical.
2. Edited calibratable parameters one at a time within input params.dat file and produced results.
3. Edited calibratable parameters one at a time within realization.json file and produced results.
4. Results were identical indicating successful implementation.
5. Tested that multiple calibratable parameters can be edited at once using same approach and results were identical.

Screenshots

Column descriptions:
“Param (original value -> test value)”: the parameter name and in (), the original value used (default) and the new value used.
“Param.dat: edited diff original?”: Did editing the parameters in the param.dat file cause results to change using the original build? (should be yes if working)
“Real: same as param.dat?”: Under the original build, does editing the parameter in the realization file result in the same output as editing in params.data? (if working, should be yes)
“Param.data”: edited same as org build edited”: Does editing the parameter in the param.dat file under the new build match the original build? (should be yes if working)
“Real: same as new param.dat?”: Under the new build, does editing the parameter in the realization file result in the same output as editing in params.data? (if working, should be yes)
“Fixed?”: Does the new build correctly update calibratable parameters and secondary variables that depend on them when using the realization.json file? (y indicates working as expected)

Notes

• After making several edits running several tests a memory allocation issue began to appear. The issue is specically related to the chv parameter. If the parameter is edited to certain values then errors either occur before or after the model is ran. Reverting to master branch showed that the memory allocation error is still present. So, the memory allocation issue is not related to edits made for this PR, but to the original code. I will address this for a future PR.

Todos

• address memory allocation issue. (Buffer overwrite in topmodel initialization #36)
• if ever desired, green-ampt parameters will need to be included so that calibration works as expected with them.

Checklist

• [x ] PR has an informative and human-readable title
• [x ] Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• [ x] Passes all existing automated tests
• [ x] Any change in functionality is tested
• [x ] New functions are documented (with a description, list of inputs, and expected output)
• [ x] Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Target Environment support

• Windows
• [x ] Linux
• Browser

Accessibility

• Keyboard friendly
• Screen reader friendly

Other

• [ x] Is useable without CSS
• [ x] Is useable without JS
• Flexible from small to large screens
• No linting errors or warnings
• JavaScript tests are passing

[madMatchstick]

@Ben-Choat - Very thorough PR description. Okay to merge after resolving conflicts. -thx

[madMatchstick]

believe I resolved all merge conflicts. okay to push forward.