srlabusask / crhmcode

CRHMcode

CRHMcode is a project to convert the Cold Regions Hydrological Modelling (CRHM) platform from Borland C++ to more modern C++ compilers. Further documentation can be found here: https://wiki.usask.ca/display/CRHMdoc/CRHM+-+Cold+Region+Hydrological+Model

CRHM: The Cold Regions Hydrological Modelling platform

The original version of CRHM can be found here: https://www.dropbox.com/s/19o5oqpw49ko4ia/CRHM_Distribution.zip?dl=0

This version of CRHM uses the Borland C++ compiler and is referred to as Borland CRHM in further documentation in this repository.

CRHMcode GCC and CRHMcode GUI

One of the objectives of the modernization of the CRHM software was to separate the core modeling functionality from the graphical user interface of Borland CRHM. This has been accomplished and two software products have been created. CRHMcode GCC is the core modeling functionality of CRHM with a simple command line interface. It has been made to compile with the GNU Compiler Collection (GCC). The other product is CRHMcode GUI a recreation of the graphical user interface of Borland CRHM built with Microsoft Foundation Class Library and Microsoft Visual Studio. Both products use the same code to run their hydrological simulations and project files and simulation results are compatible between the two.

Both versions support the same command line interface which is described here: https://github.com/srlabUsask/crhmcode/wiki/Using-CRHMcode-Command-Line-Interface

CRHMcode CLI

CRHMcode CLI can be compiled on any system that supports the GCC C++ compiler. Instructions for compiling it can be found here: https://github.com/srlabUsask/crhmcode/wiki/Building-CRHMcode-GCC

It is likely that other C++ compilers can be used to compile and run CRHMcode CLI but only the GCC compiler has been tested.

CRHMcode CLI will be available as a source distribution designed to be built with the CMake set of tools.

CRHMcode GUI

CRHMcode GCC can be built for development by following the instructions found here: https://github.com/srlabUsask/crhmcode/wiki/Building-CRHMcode-GUI-for-development-with-Microsoft-Visual-Studio

CRHMcode GUI will be available as a Windows Installer file (.msi) allowing it to be installed on Windows systems.

crhmcode's Issues

Problems with Classevap_Resist.cpp

Thought I'd add a new issue to keep things cleaner.
All of the issues affect the Penman-Monteith evaporation, (HRUs 2,3,4) not
the Prestley-Taylor (HRU 11).

Note that the same issues are present in ClassevapX

1. In Borland CRHM
   lines 16616-16617

p = soilproperties[soil_type[hh]][AIRENT]*
pow(1.0/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]); // 05/21/20 correcting pow(soilproperties[soil_type[hh]][PORE]/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]);

In crhmcode Classevap_Resist.cpp
lines 202-203

           p = soilproperties[soil_type[hh]][AIRENT]*
             pow(soilproperties[soil_type[hh]][PORE]/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]);

==============================================================================
2. In Borland CRHM
line 16623
f4 = 5000/rcs[hh]; // 05/21/20 correcting f4 = 5000/50;

In crhmcode Classevap_Resist.cpp
line 209
f4 = 5000/50;

=============================================================================

3. In Borland CRHM
   line 16662
   pow(1.0/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]); // 05/21/20 correcting pow(soilproperties[soil_type[hh]][PORE]/Sil_Moist, soilproperties[soil_type[hh]][PORESZ]);

In crhmcode Classevap_Resist.cpp
line 248
pow(soilproperties[soil_type[hh]][PORE]/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]);

=============================================================================

CRHMcode GUI menu item Project->"Plot refresh rate" 18 hr

Current Behavior

• Project->"Plot refresh rate" menu item exists but has no behavior.
• Clicking on the plot area while running a project is not possible.

Desired Behavior

• The Project->"Plot refresh rate" menu item has a sub-menu that is a radial dial selector with the following options:
  • daily
  • bi_weekly
  • weekly
  • monthly
  • yearly
  • at end
• This value defaults to "bi_weekly" being selected.
• When a project is run the TEEchart plot updates on the interval specified by the radial dial selection.
• While a project is running clicking on the plot area brings up a modal window with a radial dial selector with the following options:
  • continue
  • terminate run immediately
  • daily update
  • bi-weekly update
  • weekly update
  • monthly update
  • yearly update
  • update at end of run
• The selected item of the menu item Project->"Plot refresh rate" is selected when the modal window opens.
• Project execution pauses when this modal window is open.
• Clicking on the desired refresh rate causes the project to continue with that refresh rate.
• Clicking on continue causes the project to continue with the current refresh rate.
• Clicking on "terminate run immediately" stops the execution of the simulation.

Comments

Currently this feature also has bugs in the Borland version.

Errors in calculation of net solar radiation

crhmcode is returning differing values for net (net solar radiation) from the Borland version.
Both the older and new versions of crhmcode give the same results. In this example, the crhmcode
values are < the Borland values.

A few days previously, the crhmcode values are > the Borland values:

The values of net are determined in Classnetall. I can't find any difference in the code between the versions.
Also, the forcings seem to be the same. The incoming radiation components are the same:

The albedo values are also the same:

as are the number of sun hours:

I don't think that the issue is another if threshold. Note that the if tests are based on values of hru_SunAct and SunMax
which are much greater than zero.

 if(hru_SunAct[hh] > 0.0 && SunMax[hh] > 0.0)

Unfortunately we can't see the internal variables in the Borland code. I'll see if I can get Logan to debug the code to give us internal variables on some of the days in question.

Command line option to override the output file name

There should be a command line option available when invoking CRHM that lets the user specify the name of the output file. This option should override the name specified in the project file if there is one.

memory leaks running release 1.0

I just ran release 1.0 using the attached .prj file and got the following memory leaks
CRHM_memory_leaks.txt

Brandon_all_wetland_hru_0_pct.prj.zip

I can upload the .obs files if you want them, but even zipped, they are > 2 MB.

Difficulty adding a class

I was unable to add the class ClassSoilPrairie successfully. I added the code, which was copied from Peter Lawford's version of CRHM, and it compiled successfully. However, when I attempted to run CRHM using the new code, the program never terminated, even when running for a single day.
I've attached the changed source code files as well as the .prj and .obs files used to test the model.
soil_prairie.zip

Warning compiling release 1.0

Release 1.0 does build but it returns these warnings:
`src/NewModules.cpp:26: warning: "numsubstances" redefined
26 | #define numsubstances 5
|

In file included from src/NewModules.cpp:9:
src/WQ_Soil_NPCcycling.h:9: note: this is the location of the previous definition
9 | #define numsubstances 7
|
`

Extra line in ClassNetroute_M_D.cpp

Line 376 in ClassNetroute_M_D.cpp is not present in the Borland version
gwcumoutflow[hh] += gwoutflow[hh]

crhmcode command line version does not recognize display observation variables in project files.

.prj files have a section for display observations such as in this project file.

MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autob.txt

The display section reads like this:

Display_Observation:

Netroute_M_D basinflow 1 _Tot
Netroute_M_D basingw 1 _Tot
Netroute_M_D ssroutflow 1 2 3 4 5 _Tot
Netroute_M_D runoutflow 1 2 3 4 5 _Tot
Netroute_M_D gwoutflow 1 2 3 4 5 _Tot
obs hru_rain 1 2 3 4 5 _Tot
SnobalCRHM snowmelt_int 1 2 3 4 5 _Tot
SnobalCRHM SWE 1 2 3 4 5 _Avg
SoilDetention soil_moist 1 2 3 4 5 _Dlta
SoilDetention gw 1 2 3 4 5 _Dlta
frozenAyers meltrunoff 1 2 3 4 5 _Tot
frozenAyers runoff 1 2 3 4 5 _Tot
SoilDetention redirected_residual 1 2 3 4 5 _Tot

And running the project produces the following output.

Unknown Variable Netroute_M_D basinflow in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable Netroute_M_D basingw in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable Netroute_M_D ssroutflow in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable Netroute_M_D runoutflow in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable Netroute_M_D gwoutflow in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable obs hru_rain in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable SnobalCRHM snowmelt_int in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable SnobalCRHM SWE in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable SoilDetention soil_moist in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable SoilDetention gw in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable frozenAyers meltrunoff in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable frozenAyers runoff in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file
Unknown Variable SoilDetention redirected_residual in marmotcreek\marmotcreek_uppermiddle_05-20test_modified_26feb21_basinaggregationscheme3autob.prj, Unknown Variable in project file

Number of layers for NDEFN parameters not correct in crhmcode.

Discovered during Issue #26

Logan ran the project: https://github.com/srlabUsask/crhmcode/files/6246671/sub01_distrib_mod_auto1.zip

and encountered the following output:

C:\Research\GitHub\crhm\1Apr2021>crhm sub01_distrib_mod_auto1.prj
Project file: sub01_distrib_mod_auto1.prj

Observation file: E:\Research\BowRiverModel\Met Data\WRF_outputs_extract\WRF4km\UpperBow_atBanff\ctl\UpperBow_atBanff_WRF4km_ctl_Array_OBS.obs

Time of model run: 44287.6 2021 4 1. Program Version: 4.7_16
'XG (XG)' too few layers (nlay) to handle soil_max in hru = 1
'XG (XG)' too few layers (nlay) to handle soil_max in hru = 1
End of model run: 44287.6 2021 4 1. Program Version: 4.7_16

Logan made the following comment.

Basically, this means the total value of porous space in XG module: depth * porosity: does not fully distribute to the soil_max from SoilX module, or in other words, total value for a hru = hh, depths[ll][hh]*por[ll][nn] < soil_moist_max[hh], where ll is the value of layer. I am just wondering if crhm handled the layer parameters properly, such as depths, por in XG module, those parameter has NDEFN is their parameter declaration are like "two-dimensional". Basically, the row dimension is defined by the number of layers, N_Soil_layers parameter for a HRU. Other module using such layer parameters include glacier, and the row dimension is defined by its layer, nlay value.
There are other example of "two-dimensional" parameters also having NDEFN is their parameter declaration: such as distrib_Route parameter in Netroute_M_D module and distrib_SWEslope parameter in SWEslope module; their row dimension is same as the number of HRUs.

CRHMcode GUI menu item Project->"Auto Exit" - 5 hr

Current Behavior

• The Project->"Auto Exit" menu item is not a checkbox.
• When a project with the "Auto_Exit" directive is run it does not exit the program after completion.
• Clicking the Project->"Auto Exit" menu item causes an exception to be thrown.

Desired Behavior

• The Project->"Auto Exit" menu item has an associated checkbox.
• When a project is loaded if the "Auto_Exit" directive is included in the project file then the checkbox becomes checked.
• Clicking on the Project->"Auto Exit" menu item toggles the checkbox state.
• A project with the Project->"Auto Exit" checkbox checked exits the program after running.
• When a project is saved if the Project->"Auto Exit" checkbox is checked the directive "Auto_Exit" is saved in the project file.

CRHMcode GUI menu item Project->SaveChartTemplate

Current Behavior

• The Project->SaveChartTemplate menu item exists but does not do anything when clicked.

Desired Behavior

• The Project->SaveChartTemplate menu item has an associated checkbox.
• Upon being clicked the Project->SaveChartTemplate check box toggles.
• When a project is loaded if the "SaveChartTemplate" directive is included the checkbox becomes checked.
• When a project is loaded if the "SaveChartTemplate" directive is not included the checkbox becomes unchecked.
• When a project is saved if the Project->SaveChartTemplate check box is checked the "SaveChartTemplate" directive is added to the project file.
• When a project is saved if the Project->SaveChartTemplate check box is unchecked the "SaveChartTemplate" directive is removed from the project file.
• When a project is run with the Project->SaveChartTemplate check box checked a TEE chart file is created with the name "[ProjectName].TEE" containing the information needed to recreate the TEE chart.

Comments

Quoting Logan "However, this is not often used and is not really that useful. Often Borland CRHM crashes at the end when this SaveChartTemplate option is chosen."

I believe that unless our user base uses this feature that it should be removed.

crhm group project no output file created

Use crhm to run a group project and at the end of run, there is no output file created, and no End of model run information is shown.

The group project file is: MarmotCreek_05-20test_modified_25Jul18_basinaggregationscheme3autoa.prj

The observation file used by this project is: Marmot_Hourly_ArrayMetData_withT_g_1Oct05-30Sept20_update_22Jan2021.obs

Both prj and obs files are in this zip file:
Marmot_group_prj.zip

The runtime information from screen is as:

**C:\Research\GitHub\crhm\25Mar2021>crhm MarmotCreek_05-20test_modified_25Jul18_basinaggregationscheme3autoa.prj
Project file:

Observation file: E:\Research\Model\CRHM\CRHM Tests\CRHM Marmot Creek\Marmot Creek Hydraulic Conductivity Macro Test\CRHM_OBS\Marmot_Hourly_ArrayMetData_withT_g_1Oct05-30Sept20_update_22Jan2021.obs

Time of model run: 44284.5 2021 3 29. Program Version: 4.7_16

C:\Research\GitHub\crhm\25Mar2021>**

Commented out function in Classpbsm.cpp

This function is commented out - perhaps it's in another file?
It's present in the Borland version - line 1404
float DepthofSnow(float SWE)

CRHMcode GUI Build->Clear Modules button - 3 hr

Current behavior

• The Build->"Clear Modules" menu item exists but does not have any behavior.

Desired Behavior

• Clicking on the Build->"Clear Modules" menu item removes all modules from the project.
• The selected variables box is cleared.
• The variables box is cleared.

CRHMcode GUI menu item Project->"Auto Run" - 5 hr

Current Behavior

• Menu item Project->"Auto Run" does not have a checkbox.
• When a project with "Auto_Run" included is loaded the project does not execute automatically.
• Clicking on the Project->"Auto Run" menu item button opens a printer formatting dialog.

Desired Behavior

• Menu item Project->"Auto Run" has an associated checkbox.
• Clicking on the menu item toggles the checkbox state.
• When a project is loaded if the "Auto_Run" directive is included in the project the checkbox becomes checked.
• When a project is loaded if the "Auto_Run" directive is included the project the simulation executes after loading.
• If a project is saved while the Project->"Auto Run" checkbox is checked the saved project file has the "Auto_Run" directive included.

Water Quality Modules Testing

The water quality modules are integrated into crhmcode gcc but their results are not within tolerance of those produced by the water quality modules in Peter's Implementation.

A comparison of the following project was used:
stc_project.prj.txt

The observation files are as follows:
observations.zip

The results from running this with crhmcode gcc commit c307944 and comparing with results from Peter's implementation of the water quality modules are:

Water Quality Analysis.xlsx

It seems that quite a few outputs are not within tolerance for the entire run.

Error for compiling on Windows

Here is what I did and how the error came out:
1.I installed msys64 on my Windows PC.
2.Packages like of mingw-w32-x86_64-gcc, mingw-w32-x86_64-gdb and mingw-w32-x86_64-make for MinGW were also installed.
3.I downloaded spdlog header files and boost library and put them to the code directory (i.e. \crhmcode)
4. Open cmd, and cd to the code directory of CRHM.
5. Input make or make crhm, then got lots of outputs like
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: obj/ClassXG.o:ClassXG.cpp:(.text+0xbd87): undefined reference to `StandardConverterUtility::GetDateTimeInStringabi:cxx11'],
but failed by the error as
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:94: crhm] Error 1
outfile.txt

Issue when reading observation data from multiple files and using multiple groups (smith creek).

it seems that there is a difference in the code between old and new versions at this location:
in ClassModule.cpp, the declobsfunc routine, (line 1887 in new version)

the old version has:

case CRHM::INIT:  {
  itVar = Global::MapVars.find(Name + " " + variable);
  newVar = (itVar == Global::MapVars.end()) ? NULL : (*itVar).second;

  if((itVar = Global::MapVars.find(declModule + obs)) != Global::MapVars.end()) {
    obsVar = (*itVar).second;

and the new version has:

    itVar = Global::MapVars.find(Name + " " + variable);

    try
    {
        if ((itVar = Global::MapVars.find(declModule + obs)) != Global::MapVars.end()) {
            newVar = (*itVar).second;
            obsVar = (*itVar).second;

In the new version the itVar variable from the first line is immediately overwritten in the if statement.
This change seems to break the connection between observation data and internal variable for some variables.
(newVar and obsVar aren't meant to be the same)

The problem I am experiencing is that the air temperature is not read properly and so it gives invalid numbers.

Weird results running release 1.0

Running release 1.0 with the .prj described in issue #8 gives incorrect results.
I summarised the values for all of the output variables for the current production version of CRHM in this file:

old_crhm_summary.csv.zip

The values for release 1.0 are summarised in this file:
new_crhm_summary.csv.zip

Note that the values are very different, particularly the first variable output.

CRHM .int file, Initial_State and Final_State

I used the following .prj to demonstrate the Initial_State and Final_State from Borland CRHM.

1. I ran the "MarmotCreek_05-06test_modified_25Jul18_basinaggregationscheme3autoa_generateInt.prj" to generate the final state file "MarmotInitialstate06.int" at the end of run.

This project can be found here:
MarmotCreek_05-06test_modified_25Jul18_basinaggregationscheme3autoa_generateInt.zip

The obs file for the prj can be found here:
Marmot_Hourly_ArrayMetData_withT_g_1Oct05-30Sept20_update_22Jan2021.zip

In this prj, I saved the the final state file name "MarmotInitialstate06.int" under Final_State,

Final_State

MarmotInitialstate06.int

This .int file stores all the state variables in this prj. A state variable is declared using declstatvar(...); the state variables include variables such as Albedo, SWE, and so on.

The purpose of .int file is to show information of these state variables at the end of run, but also it can provide initial values of these state variables used by the subsequent model run.

2. For the subsequent model run that uses the "MarmotInitialstate06.int", I ran the "MarmotCreek_06-07test_modified_25Jul18_basinaggregationscheme3autoa_useInt.prj".

This project can be found here:
MarmotCreek_06-07test_modified_25Jul18_basinaggregationscheme3autoa_useInt.zip

This prj reads the "MarmotInitialstate06.int" file under Initial_State:

Initial_State

MarmotInitialstate06.int

It should be noted that value for Time in the "MarmotInitialstate06.int" and Start value for Date in the "MarmotCreek_06-07test_modified_25Jul18_basinaggregationscheme3autoa_useInt.prj" must be the same:

Time:
2006 10 1

Dates:

2006 10 1
2007 10 1

If these do not match, CRHM will have complaint message.

Note that in the "MarmotCreek_06-07test_modified_25Jul18_basinaggregationscheme3autoa_useInt.prj", I also saved the final state file "MarmotInitialstate07.int" so that it could be used by the subsequent model run starting 2007 10 1.

Note that in above prj files, there is no file directory specified for the .int files under Final_State and Initial_State, this saves .int file in same file directory as where .prj files are and assumes both prj files are in the same file directory.
On the other hand, .int file can be placed at specified file directory that is different from where .prj files are, such as C:\Research\MarmotInitialstate06.int. As long as whereabout of the int file under Final_State and Initial_State are specified correctly, the prj file generating and reading the .int file can run without problem.

Better description for soil_rechr, soil_moist variables and parameters in soil, soilDS, soilX and SoilPrairie modules

I noted the description for soil_rechr, soil_moist variables and parameters are not up to date in soil, soilDS, soilX, SoilPrairie and SetSoil modules. This is just a tiny issue, as it is not visible to gcc crhm. A better description for soil_rechr, soil_moist variables and parameters was added on March 31, 2020. Anyway, "available" or "available water" in places where descriptions for these variables and parameters were added. This is to inform CRHM users that these variables and parameters are meant for available water storage (ie. difference between field capacity and wilting point) in soil, not the entire soil storage.

Please add the better description in the files: ClassSoil.cpp, ClassSoilDS.cpp, ClassSoilX.cpp, ClassSetSoil.cpp files.

segfault when running CRHM model 'sub01_distrib_mod_auto.prj'

I pulled the latest version of the master branch and rebuilt it.
When I tried to run it with

sub01_distrib_mod_auto.prj

it segfaulted

ClassVolumetric.cpp

There are very many differences between the classcrhm code and the Borland version
Borland version line 12585 is not present in crhmcode
declgetvar("*", "soil_rechr", "(mm)", &soil_rechr); // 04/14/2020

also Borland lines 12604-12632 are very different

    Volumetric_rechr[hh] = (soil_rechr[hh]/soil_rechr_max[hh]*SetSoilproperties[soil_type[hh]][3] + SetSoilproperties[soil_type[hh]][1])/1000.0;  // 04/14/2020

    if(nstep == 0 && set_fallstat[hh] == Julian || (getstep() == 1 && Julian > set_fallstat[hh])){
      if(Si){
        float X = 1.0;
        if(SetSoilproperties[soil_type[hh]][3] > 0.0){
          if(Volumetric_option[hh])  // 04/14/2020
            X = Volumetric_rechr[hh]/SetSoilproperties[soil_type[hh]][3]*1000.0;
          else
            X = Volumetric[hh]/SetSoilproperties[soil_type[hh]][3]*1000.0;
          X = X - Si_correction[hh];
        }

        if(X < 0.0)
          X = 0.0;
        else if(X > 1.0)
          X = 1.0;

        Si[hh] = X;
        Si_V[hh] = Si[hh];
      }

      if(fallstat[hh]){
        if(SetSoilproperties[soil_type[hh]][3] > 0.0)
          if(Volumetric_option[hh])  // 04/14/2020
            fallstat[hh] = Volumetric_rechr[hh]/SetSoilproperties[soil_type[hh]][3]*100000.0; // ie 100*1000
          else
            fallstat[hh] = Volumetric[hh]/SetSoilproperties[soil_type[hh]][3]*100000.0; // ie 100*1000
        else

Minor compilation issue

When compiling codebase2, I get this warning and note:

src/NewModules.cpp:26: warning: "numsubstances" redefined
26 | #define numsubstances 5
|
In file included from src/NewModules.cpp:9:
src/WQ_Soil_NPCcycling.h:9: note: this is the location of the previous definition
9 | #define numsubstances 7
|

ClassevapD_Resist

I am going through the gcc crhm core modules code and found there are a couple tiny issues in ClassevapD_Resist.cpp:

On Line 158-159 and Line 195-196, the code should be as follows,

       p = soilproperties[soil_type[hh]][AIRENT]*
         pow(1.0/Soil_Moist, soilproperties[soil_type[hh]][PORESZ]); // 05/21/20 correcting 

On Line 202, the code should be as follows,

      f4 = 5000/rcs[hh]; // 05/21/20 correcting

These are corrections on 21 May 2020 in Jarvis resistance scheme used in evap_Resist, evap_ResistD, and evapX modules; I checked both Classevap_Resist.cpp and ClassevapX.cpp files are good and have these corrections.

CRHMcode GUI Build menu pre built projects. - 10 hr

The Borland version of CRHM provides access to pre-built projects under the "Build" menu. Clicking on one of these model descriptions loads the modules associated with the pre-built project and sets values for the parameters.

These menu items are not present in the CRHMcode version. We should find out which models are commonly used enough that providing easy access to them would be beneficial.

Compile issue on MacOS

I had to modify the code to compile on MacOS. The std::fmin and std::fmax routines in WQ_CRHM.cpp and WQSoil_NPcycling.cpp were not found in the listed headers. Solution was to change the line
#include <math.h>
to
#include <cmath>
in those two files, as per https://en.cppreference.com/w/cpp/numeric/math/fmax

CRHMcode GUI does not behave properly when the window is resized. - 6 hr

When clicking the “Maximize” button in the upper right corner, the GUI window increases in size but the content does not. Instead blank margins are added to the bottom and right.

Proper behavior should be for the content of the window to expand to fit the size of the window.

Runtime exception generated when observation files in "wrong order"

When executing the following project:
Brandon_all_wetland_hru_0_pct.prj.txt

If the observation files
Brandon_daily_ppt_1960-2006.obs.txt
Brandon_hourly_t_u_rh_1960-2006.obs.txt

Are ordered in this order the project executes fine:

brandon_all_wetland/Brandon_hourly_t_u_rh_1960-2006.obs
brandon_all_wetland/Brandon_daily_ppt_1960-2006.obs

However if in the opposite order:

brandon_all_wetland/Brandon_daily_ppt_1960-2006.obs
brandon_all_wetland/Brandon_hourly_t_u_rh_1960-2006.obs

After the observation files are loaded the program crashes with the following error: Floating point exception (core dumped)

If run in a debugger the result is this:

Program received signal SIGFPE, Arithmetic exception.
0x00000000080bf113 in CRHMmain::DoObsStatus (this=0x8b24c90, First=@0x7ffffffede58: false)
    at src/core/CRHMmain/CRHMmain.cpp:2460
2460

Problem occurs around this segment of code. in CRHMmain.cpp

2455                            if (FileData->Times[FileData->TimeIndx] != Global::DTnow)
2456                                    FileData->GoodInterval = false;
2457                    }
2458                    else { // normal observation file
2459
2460                            long Index = Global::DTindx / FileData->ModN;
2461
2462                            if (Index < FileData->IndxMin || Index > FileData->IndxMax) {
2463                                    FileData->GoodInterval = false;
2464                                    FileData->GoodDay = false;

Global::DTindx has a value of 0
FileData->ModN has a value of 0

this causes division by zero.

The code seems be be compensating for differences in the obs files

Assessment of CRHMcode GUI

Logan has performed an analysis of the features of the CRHMcode implementation of the Borland CRHM GUI

His analysis can be found here:
CRHM_GUI_23Jun2021 features assessment.pdf

and continued here:
CRHM_GUI_23Jun2021 features assessment_Updated28Jun2021.pdf

I will use this analysis to extract individual issues that I will then address. Some of these issues may not need to be addressed as the feature they relate to is so seldom used that it is not worth the development time.

If you have any further comments on Logan's analysis or any of the individual issues please provide comment.

Classcrack and ClassGreencrack infDays Parameter

In ClassCrack.cpp, line 162 is
infil_index(fallstat[hh]/100.0, SWE[hh], Xinfil[0][hh], Xinfil[1][hh]);

In the original code, line 3974
infil_index(fallstat[hh]/100.0, SWE[hh], Xinfil[0][hh], Xinfil[1][hh], infDays[hh]);

In ClassCrack.cpp, line 178 is
if(crackstat[hh] > 6)

In the original code, line 3990 is
if(crackstat[hh] > infDays[hh])

Originally posted by @KevinShook in #10 (comment)

Moving this out to its own issue. Upon closer examination there is a parameter that is declared in your version of the code that is not present in the gcc version.

Both Classcrack and ClassGreencrack have a parameter declared called infDays with the following code.

decldiagparam("infDays", NHRU, "[6]", "0", "20", " maximum number of days of snowmelt infiltration to frozen soil ", "(d)", &infDays);

Do you know if this is a recent addition? I assume it should be added in both classes?

crhm is left hanging or idle

I was working on testing crhm with a glacier sub-basin project in Bow River. This project has 54 HRUs and uses observation that is fairly large consisting of 49 arrays or columns for 5 variables. I tried to run the project yesterday afternoon and waited for another a couple of hours, it seems that crhm is not responding. I started run again last night and nothing happened this morning, with crhm looking like not responding. I attached a screen shot showing crhm not responding:

It took about 25 minutes for Borland CRHM to finish running this project.

I am wondering if crhm has difficulty in reading this large size observation file. If this is issue, then crhm would have more difficulty in other projects I have using multiple large size observation files.

Due to the size of observation (ie. greater than 10MB), I cannot attach it here. Instead, I have a link below for a zip file containing project and observation files:
https://usaskca1-my.sharepoint.com/:u:/r/personal/xif382_usask_ca/Documents/crhm/30Mar2021/sub01_distrib_mod_auto.zip?csf=1&web=1&e=PLoW7d

CRHMcode GUI Build->Construct window - 28 hr

Current Behavior

• Clicking on the menu item Build->Construct opens a dialog window used to build projects.
• The window cannot be resized.
• Double clicking on a module causes the module information to be displayed in the upper right panel.
• Highlighted modules can be moved to the selected modules box by clicking on the ">>" causing all highlighted modules to be moved to the selected modules box.
• Highlighted modules in the selected modules box can be removed by clicking on the "<<" causing all highlighted selected modules to be removed from the selected modules box.
• There is no way to access module variations.
• The MAXLAY and MAXHRU number selectors do not change the indicated number.
• MAXLAY and MAXHRU indicated by the number selector do not match the numbers in a loaded project file.
• Clicking the build button sets up a project with the selected modules.
• Clicking on the check button checks if the selected modules are able to build a project and outputs information to the lower right panel.
• Clicking on close closes the dialog window.

Desired Behavior

• Clicking on the menu item Build->Construct opens a dialog window used to build projects.
• The window can be resized and has maximize and minimize window buttons.
• Clicking on a module causes it to be highlighted.
• The information for the last clicked module is displayed in the upper right panel.
• Highlighted modules can be moved to the selected modules box by clicking on the ">>" causing all highlighted modules to be moved to the selected modules box.
• Highlighted modules in the selected modules box can be removed by clicking on the "<<" causing all highlighted selected modules to be removed from the selected modules box.
• Selected modules can have their variation selected. (Right click context menu isn't intuitive a better solution should be chosen.)
• The value of MAXLAY and MAXHRU can be set.
• The value of MAXLAY and MAXHRU match the number specified in a loaded project file.
• Clicking the build button sets up a project with the selected modules.
• Clicking on the check button checks if the selected modules are able to build a project and outputs information to the lower right panel.
• Clicking on close closes the dialog window.

hru_snow, hru_rain, SWE_in, SWE_out, SWE from sub01_distrib_mod_auto1.prj

I have done some comparisons for results from crhm and Borland CRHM for project sub01_distrib_mod_auto1.prj.
In case it is needed, it can be found from here:
sub01_distrib_mod_auto1.prj.txt

In this prj, I used Macro 'sub_WBvar_estimate' to output water balance variables for the basin average in addition to the basinflow and basingw variables. The comparisons include hourly time-series plot and scatter plot and can be found here:
sub01_test_plot.zip

Overall, plots show fairly close results between crhm and Borland CRHM for variables:

intcp_evap (Interception evaporation):

Subl_Cpy (Interception sublimation):

hru_rain (Rainfall):

This suggests that for the forest HRUs, interception processes in CanopyClearingGap module are handled fairly consistent by crhm when comparing to Borland CRHM; this is likely true for Canopy and CanopyClearing modules as both share majority of code with CanopyClearingGap module.

Other variables have noticeable differences.

Especially for SWE_in, SWE_out, basinflow variables. To investigate these differences, it is good start with variables according to the module sequence, such as hru_rain and hru_snow variables from obs module, so I ran projects sub01_distrib_mod_auto1_hru_rain.prj and sub01_distrib_mod_auto1_hru_snow.prj to output hru_rain and hru_snow for all 54 HRUs for comparisons. Both project files can be found here:

sub01_distrib_mod_auto1_hru_rain.prj.txt
sub01_distrib_mod_auto1_hru_snow.prj.txt

I have comparison plots for hru_rain and hru_snow here:
sub01_test_plot_hru_rain.zip
sub01_test_plot_hru_snow.zip

The plots show that crhm tends to have a very small numbers of slight overestimation of hru_rain for the lower rainfall events (ie. < 5 mm) for HRUs: 31 to 35 and 48 to 52;
The plots show that crhm tends to have a very small numbers of slight underestimation of hru_snow for the moderate snowfall events (ie. < 10 mm) for HRUs: 1 to 25, 31 to 38, 42, 44, and 48 to 52.

In addition, I have comparison plots for SWE variable as it has strong effect on other variables, and the plots can be found here:
sub01_test_plot_SWE.zip

The plots show some noticeable differences for SWE. In this project sub01_distrib_mod_auto1.prj, SWEslope module is used to model the snow transport by gravity, which could introduced these differences.
I have the plots of SWE_out (ie. outgoing snow transport) variable for HRUs dealing with this process:
sub01_test_plot_SWE_out.zip
I have the plots of SWE_in (ie. incoming snow transport) variable for HRUs dealing with this process:
sub01_test_plot_SWE_in.zip
As shown, crhm has noticeable differences in SWE_out and SWE_in variables for these HRUs.

For other HRUs that do not deal with snow transport by SWEslope module, SWE values tend to lower from crhm compared to Borland CRHM.

Here is a Upper Middle t project I tested earlier, I used this to verify whether crhm catches hru_rain, hru_snow SWE correctly:
I used MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autoa.prj to output hru_rain and SWE for 5 HRUs in Upper Middle, the project file can be found here:
MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autoa.zip

I used MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autoa_hru_snow.prj to output hru_snow for 5 HRUs in Upper Middle, the project file can be found here:
MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autoa_hru_snow.zip

The plots of 5 HRUs hru_rain, hru_snow and SWE can be found here:
UpperMiddle_test_plot.zip

These plots show that hru_rain and hru_snow are very close between crhm and Borland CRHM for Upper Middle project; for SWE, crhm is not always perfectly aliened with Borland CRHM on 1;1 line, but crhm has both very small overestimation and underestimation.

Both sub01_distrib_mod_auto1.prj and MarmotCreek_UpperMiddle_05-20test_modified_26Feb21_basinaggregationscheme3autoa.prj use Macro 'Precip_Elevation_Adjust' to adjust parameter precip_elev_adj for seasonal variations, and sub01_distrib_mod_auto1.prj also has Macro 'lapse_rate_Adjust' to adjust parameter lapse_rate for seasonal variations. This could also be factor for hru_snow in sub01_distrib_mod_auto1.prj.

In summary, for the project sub01_distrib_mod_auto1.prj, issues at the moment:

1. Whether these Macros 'Precip_Elevation_Adjust' and 'lapse_rate_Adjust' are issues in crhm for hru_rain and hru_snow.

2. Whether obs file used by sub01_distrib_mod_auto1.prj causes the issues for hru_rain and hru_snow.

3. Whether there is a precision issues for some parameters in ClassSWEslope.cpp in crhm to cause SWE_out and SWE_in issues, such as following:
   if (use_rho[hh])
   den_snow = rho[hh];
   else
   den_snow = snow_density[hh];

4. Why SWE simulated by crhm tends to be slightly lower than Borland CRHM for those HRUs not affected by SWEslope?

Problem with results from release 1.1

I was able to run release 1.1. The execution time was excellent - about 1/3 of the old Windows version.
The executable file is also very small, which is great to see
Unfortunately, there are very large errors in some of the values. I had noticed similar issues in release 1.0, as well.

As you can see from the figure, the annual depth of annual discharge is orders of magnitude too large in the crhmcode release 1.1 model. This would appear to be because the actual evaporation depths are too small, as the depths of precipitation are identical.

This model uses 2 different methods for calculating evaporation. Penman-Monteith is used by HRUs 2-4, while HRU 11 uses Priestley-Taylor. Both are giving incorrect results.
I checked the snow accumulation from the module PBSM, and it appears to be giving the same results in both models.

Therefore, the issue appears to be either in the module evap_Resist or within one of the modules that it uses.

ClassEvap source code difference.

Found some another difference
In ClassEvap.cpp line 105
if(inhibit_evap[hh] || inhibit_evap_User[hh]){

The Windows CRHM line 3217 is
if(inhibit_evap[hh]){

Originally posted by @KevinShook in #10 (comment)

I am going to separate this issue out as well.

I can make the gcc code match this windows version but I think it is possible that that might lead to unintended results and would like to investigate further.

Leaving this issue open to on not loose track of it.

CRHM output format

I notice that release 1.1 has a strange output header, which breaks my CRHMr package code.
The old CRHM output header looked like this:

Observation file generated by Python v2.5, gp v9.3 from ['C:\\Shawn\\GISdata\\inbox\\ppt.txt', 'C:\\Shawn\\GISdata\\inbox\\rh.txt', 'C:\\Shawn\\GISdata\\inbox\\snodepth.txt', 'C:\\Shawn\\GISdata\\inbox\\temp.txt', 'C:\\Shawn\\GISdata\\inbox\\tmpMax.txt', 'C:\\Shawn\\GISdata\\inbox\\tmpMin.txt'].  Generated 2011-Mar-30 12:19 by Shawn Tse
ppt 18 (mm)
rh 18 (%)
snodepth 18 (mm)
t 18 (°C)
tmax 18 (°C)
tmin 18 (°C)
$ea ea(t, rh) (kPa) vapour pressure
$u const(5) % fake these measurements
$Ts const(-10) % fake these measurements
$snodepth div(snodepth,1000)
############################################################

with a comment line followed by lines for each variable type, terminated with hashes.

The new output header looks like this

time	basinflow(1)	Sd(2)	Sd(3)	Sd(4)	Sd(11)	SWE(2)	SWE(3)	SWE(4)	SWE(11)	hru_p(2)	soil_moist(2)	soil_moist(3)	soil_moist(4)	soil_moist(11)	hru_actet(2)	hru_actet(3)	hru_actet(4)	hru_actet(11)
units	(m^3/int)	(mm)	(mm)	(mm)	(mm)	(mm)	(mm)	(mm)	(mm)	(mm/int)	(mm)	(mm)	(mm)	(mm)	(mm/int)	(mm/int)	(mm/int)	(mm/int)

with 2 lines, one for the variable names and one for the units

The header for release 1.1 looks like this:

Future File Description
basinflow(1) 1 
Sd(2) 1 
Sd(3) 1 
Sd(4) 1 
Sd(11) 1 
SWE(2) 1 
SWE(3) 1 
SWE(4) 1 
SWE(11) 1 
hru_p(2) 1 
soil_moist(2) 1 
soil_moist(3) 1 
soil_moist(4) 1 
soil_moist(11) 1 
hru_actet(2) 1 
hru_actet(3) 1 
hru_actet(4) 1 
hru_actet(11) 1 
##### time	basinflow(1)	Sd(2)	Sd(3)	Sd(4)	Sd(11)	SWE(2)	SWE(3)	SWE(4)	SWE(11)	hru_p(2)	soil_moist(2)	soil_moist(3)	soil_moist(4)	soil_moist(11)	hru_actet(2)	hru_actet(3)	hru_actet(4)	hru_actet(11)

Which is a strange combination of the old and new formats. Did anyone ask for this format?

Complicated projects possibly run out of memory and crash.

Some have reported that complicated projects run out of memory and crash before completing.

This project is one such project.

Upper_Bow_at_Banff_crash_test.prj.txt

https://drive.google.com/file/d/1CinHXsfL2pjKDPWsAISkx2jS1PcUEsj4/view?usp=sharing

I was able to successfully run this project for a 10 year run. It took over 8 hours to finish but it did so and produced the following output.

https://drive.google.com/file/d/1BdIrrU6pMYKijuU6F0Wkolk4wf1WAf-l/view?usp=sharing

I will continue to investigate and run the full 15 years but as of now I have been unable to reproduce a crash.

ClassPrairieInfil.cpp

In ClassPrairieInfil.cpp
line 112 - 118

    if (hh < nhru) 
    {
        timer[hh] = 0;
        Xinfil[0][hh] = 0.0;
        Xinfil[1][hh] = 0.0;
        Xinfil[2][hh] = 0.0;
    }

In Borland 13018 - 13021

    timer[hh] = 0;
    Xinfil[0] [hh] = 0.0;
    Xinfil[1] [hh] = 0.0;
    Xinfil[2] [hh] = 0.0;

Also, in the Borland version, but not in the crhmcode version:

float textureproperties[] [6] = { // mm/hour
  {7.6, 12.7, 15.2, 17.8, 25.4, 76.2},  // coarse over coarse
  {2.5,  5.1,  7.6, 10.2, 12.7,  15.2}, // medium over medium
  {1.3,  1.8,  2.5,  3.8,  5.1,  6.4},  // medium/fine over fine
  {0.5,  0.5,  0.5,  0.5,  0.5,  0.5}   // soil over shallow bedrock
};

If this isn't defined elsewhere, it will definitely cause problems

Issue with solar radiation

I have changed the precipitation phase determination to be based on air temperatures, rather than the Harder method.
The net solar radiation for HRU 11 is now equal for the Borland and chrmcode versions:

However, the values are not equal for HRU 2

HRU 11 is water-covered (wetland), while HRU 2 is cropped.

I don't think that the differences can be due to snow, as the difference between the Borland and crhmcode versions persist all through the year, and are very consistent.

I'll keep digging to see if I can find the cause.

Output file of the Borland version

I have a concern to the output file of the Borland CRHM version:
This file misses the units of output variables and repeats the names of output variables in the file header. At least, the units of output variables are needed in the file for result analysis, I think. I am wondering is it possible to modify a bit and output the file in the format of previous CRHM version. Two output files from the versions are attached for comparison.

output_Borland_crhm.txt
output_previous_CRHM.txt

CRHMcode GUI menu item Project->Log sub-menu is not implemented - 18 hr

Current Behavior

• The Project->Log sub-menu does not exist.

Desired Behavior

• The menu item Project->Log has a sub-menu with the following elements:
  • Last
  • All
  • Debug_Screen
  • Summary
• The "Last" and "All" items form a radial dial selector with "All" selected by default.
• The "Debug_Screen" and "Summary" items have associated check boxes.
• When a project is loaded if the "Log_All" directive was included the Project->Log->All dial becomes selected.
• When a project is loaded if the "Log_Last" directive was included the Project->Log->Last dial becomes selected.
• When a project is loaded if the "Log_Screen" directive is included the Project->Log->Debug_Screen checkbox becomes checked.
• When a project is loaded if the"Summary_Screen" directive is included the Project->Log->Summary check box becomes checked.
• When a project is run with the Project->Log->Last dial selected the output file only contains the last time step of the output variables.
• When a project is run with the Project->Log->All dial selected the output file contains values for each time step for each output variable.
• When a project is run with the Project->Log->Debug_Screen check box checked the log screen information is saved in a file named "CRHM_output.log".
  • This feature may be able to be removed as this log output is already generated and saved by the new logging system.
• When a project is run with the Project->Log->Summary check box checked the requested summary values are saved to a file named "CRHM_ouptut.sum"
  • Summary values are specified in the "Display Observations" section of the project file.

Error compiling release 1.1

I attempted to make release 1.1 using gcc, but it did not complete, and returns this error message

/usr/bin/ld: obj/StandardConverterUtility.o: in function std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > __gnu_cxx::__to_xstring<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, char>(int (*)(char*, unsigned long, char const*, __va_list_tag*), unsigned long, char const*, ...)': /usr/include/c++/9/ext/string_conversions.h:105: undefined reference to ___chkstk_ms'
collect2: error: ld returned 1 exit status
make: *** [Makefile:95: crhm] Error 1

In addition it returns many examples of this warning:
cc1plus: warning: ‘-fstack-check=’ and ‘-fstack-clash_protection’ are mutually exclusive. Disabling ‘-fstack-check=’
I was compiling on Linux Mint 20.1, using boost 1.73, and gcc version 9.3.0

CRHMcode GUI menu item Project->Freq_Default

Current Behavior

• Menu item Project->Freq_Default is present but has no behavior.

Desired Behavior

• Clicking on the menu item Project->Freq_Default while no observation files are open opens a dialog window which allows the time step Frequency to be set. The allowed values are.
  • 1 for 24 hr each time step
  • 2 for 12 hr each time step
  • 3 for 8 hr each time step
  • 4 for 6 hr each time step
  • 6 for 4 hrs each time step
  • 8 for 3 hrs each time step
  • 12 for 2 hrs each time step
  • 24 for 1 hr each time step
  • 48 for 30 mins each time step
  • 72 for 20 mins each time step
  • 96 for 15 mins each time step
  • 144 for 10 mins each time step
  • 192 for 7.5 mins each time step
  • 288 for 5 mins each time step
• Clicking on the menu item Project->Freq_Default while observations are open displays the current time step frequency set by the observation file with the largest frequency. Also a message saying that Freq_Default can only be manually set with no observation files open.

Comments

Quoting Logan, "This is not useful. I have never used it before."

I would like to explore if this feature can be removed.

Crash while reading obs files

My model uses some new code (changes to soil_prairie), but the crash does not appear to be related to it.

It ran OK when I used one .obs file, but crashed when I used a different one.

The file causing crashes had been used by Peter Lawford's CRHM and worked OK in the past.

The file that worked OK is called Saskatoon2.obs and has this header

input_obs created by CRHMr function writeObsFile
u 1 (m/s)
t 1 (C)
rh 1 (%)
p 1 (mm)
ppt 1 (mm)
$ea ea(t, rh)
################ u.1 t.1 rh.1 p.1 ppt.1
1960 01 01 01 00 6.67 -13.3 84 0 1.3
1960 01 01 02 00 8.89 -12.8 85 0 0

...

This file the that caused the crash was StDenis_1901_2000_hourly.obs

obs created by CRHMr function writeObsFile
t 1 (C)
ea 1 (kPa)
u 1 (m/s)
p 1 (mm)
Qsi 1 (W/m2)
Qli 1 (W/m2)
$rh rh(t, ea)
################ t.1 ea.1 u.1 p.1 Qsi.1 Qli.1
1901 01 01 01 00 -25.479096476237 0.0581597479967261 0.56455938021342 0 0 172.545106846256

....

The crash message was interesting:

Observation: 'u', not in Data file. Requested by 'obs'

However, the u values are present in both files.
I haven't attached the files as they are very large, 14 and 86 MB, respectively.

Another albedo problem

I've been looking into the remaining differences between the Borland and crhmcode outputs, and have been focusing on the 1989 discharges as the differences are relatively large.

Looking at the reason for the differences led me (eventually) back to the albedo

In more detail:

You can see that the crhmcode albedos start to decay immediately, while the Borland albdeos increase on Feb 3 and 5.

I believe that this is caused by yet another thresholding issue. The snowfall over the time period ranges between 0.21 and 0.25 mm:

In the albdeo module there is a hard-coded check on the daily snowfall for values > 0.25 mm.
Looks like another double-precision issue.

        if(net_snowD[hh] > 0.25) { // SF = SWE*2 if density 0.005 (0.5cm)
          Albedo[hh] = Albedo[hh] + net_snowD[hh]*0.1*2.0; // daily value
          if(Albedo[hh] > Albedo_snow[hh])
            Albedo[hh] = Albedo_snow[hh];
          continue;

Could you please subtract epsilon from 0.25 to see that the effect would be?
Also, there are a bunch of other tests in this module which should also use epsilon.

Thanks

CRHMcode GUI Build->Macro window removes all modules on cancel or close. - 6 hr

The CRHMcode GUI correctly opens a editing window for macros when the Build->Macro menu item is clicked. The macros section is able to be edited and if "Save Changes" is clicked the macro section is updated correctly. However, if the window is closed by clicking "cancel" or closing the window all modules are removed from the project as if the Build->"Clear Modules" button was pressed.

CRHMcode GUI Observations Selector - 28 hr

Current Behavior

• Clicking on a observation name in the observation box places the first dimension of the observation into the selected observation box and plots the observation in the TeeChart graph area.
• Additional clicks of the same observation name add the subsequent dimensions of the observation variable to the selected box and the TeeChart graph area.

Desired Behavior

• Clicking on a observation name in the observation box highlights the observation and its help information, units, and source file are displayed in the observation help section at the bottom of the screen.
• Multiple observation names can be selected at once by using "shift+click" to add all between two name and "shift+ctrl" to add to the set of selected names.
• Right clicking on an observation name in the observation box brings up a context menu with the following items:
  • Add ins
    • Clicking on this adds the observation dimension of the selected observation names to the selected observations box and updates the TeeChart plot.
    • The added dimension is chosen by the observation dimension selector in the bottom left section of the screen.
  • AddArray
    • Clicking on this adds all of the observation dimensions of the selected observations to the selected observations box and updates the TeeChart plot
  • Function
    • Clicking on this opens up a modal window that allows the selection of a function to be applied to the observation. The functions available are:
      • Observation
      • VP_saturated
      • Watts to MJ/Int
      • MJ/Int to Watts
      • Average
      • Minimum
      • Maximum
      • Total
      • Positive
      • First
      • Last
      • Count
      • Count0
      • Delta
    • The modal window also has a close option.
    • After a function is selected all observations added will be the observation with the selected function applied.
    • To return to normal observation adding the "Observation" function must be selected.
• Clicking on a selected observation name highlights it.
• Right clicking on a selected observation name brings up a context menu with the following options:
  • Delete
    • Clicking on this removes the selected observations from the selected box and updates the TeeChart plot.
  • Negate
    • Clicking on this causes the values of the selected observations to be multiplied by -1
• There is a observation dimension selector in the bottom left that has arrows to select a number that determines what observation dimension is added to the selected box and the plot when the "Add ins" option is used.

Comments

The select function menu has options in Borland for selecting a display mode but Logan feels that this is not needed.

CRHMcode GUI Observations menu - 7 hr

Current Behavior

• Observations menu contains two items:
  • Open
  • Close All
• Clicking on "Open" opens a dialog that allows an observation file to be loaded.
• Clicking on "Close All" closes all open observation files.

Desired Behavior

• Observations menu contains two items unless an observation file is open:
  • Open
  • Close All
• Clicking on "Open" opens a dialog that allows an observation file to be loaded.
• Clicking on "Close All" closes all open observation files.
• Any open observation files are listed in the menu after "Close All"
  • These listings contain the path to the observation file.
  • Clicking on one of them will close that specific observation file.