Updating tests to handle nutrient Components

[mattjbr123]

Sub-task of #14

As part of #14 the unit tests for UNIFHY need to be updated to expect nutrient components before any development on UNIFHY to add these components takes place.

[mattjbr123]

There is some question on whether or not to make the nutrient components mandatory or not for the tests (and thus for the user).

As UNIFHY allows NullComponents, which essentially remove the component from the Model, I think for now we will require all 6 components be provided for a Model, as the user will have the option of making the nutrient components NullComponents if they do not wish to model nutrients. Therefore the tests will be set up similarly, to expect 6 components for a given Model, and failing otherwise.

[mattjbr123]

The following changes need to be made to the tests for them to require 6 components instead of 3:

test_model.py:

• [x] Simulator.from_scratch(): Add 3 extra arguments defining the 'category' of the nutrient Components in the function declaration and to all calls of the function, and edit the body of the function appropriately to process these
• [x] Simulator.setup_model(): Add 3 extra arguments defining the nutrient Component 'kinds' to the function declaration and all function calls, and add get_dummy_component() calls for nutrients Components as for the WaterEnergy Components to the body of the function
• [x] Modify all calls to unifhy.Model() to include arguments that are the nutrient Components, and modify the identifier (within the function body?) to include these as well. This will cause calls to unifhy.Model() to fail as it won't be expecting nutrient Components.
• [x] Extend clean_up_dump_files() and clean_up_record_files() to include the nutrient Components directories and files
• [x] Add 3 simulator_2.model**.nutrientcomponentname**.initialise_states_from_dump lines (triggering an expected fail) to the test_spinup_dump_init_spinup() test
• [x] Add nutrient Components (as model.nutrientcomponentname) in check_final_conditions()
• [x] Add transfers to loop over in check_exchanger_transfers(). The transfers to add are any added between components involving the new nutrient Components defined in tests/tests/components/componentname/dummy.py
• [x] In AdvancedTestModel.test_setup_spinup_simulate_resume_run(): add in 'c', 'd' and 'n' in the 'doe' (design of experiment) selector variable for the 3 nutrient Components and the following loop, add nutrient Components to subtest and deepcopy calls, and add assertTrue() compare states tests for nutrient Components.
• [x] In BasicTestModel.test_setup_spinup_simulate_resume_run(), add in 3 deepcopy lines and compare_states lines for the nutrient Components.
• [x] In BasicTestModel.check_records() add in the 3 nutrient Components to the loop over Components
• [x] In AdvancedTestModel.test_setup_simulate(): add 'c', 'd' and 'n' to the 'doe' selector variable for the 3 nutrient Components and add to subTest call
• [x] In AdvancedTestModel.test_setup_simulate_various_sources(): add 'Python', 'Fortran', 'c' for the 3 nutrient Components in the 'doe' selector variable, add them to subsequent for loop and add to subTest call

test_component.py

• [x] In the various dictionaries, add entries for the 3 nutrient Components. Matching the setup of the WaterEnergy Components should do the job for now, though might want to build an additional test for differences between matching Components of WaterEnergy and Nutrients (e.g. Openwater and NutrientOpenwater) in the future. Might need to create new dummy_subsurface_parameter.... or similar files for this.
• [x] In get_dummy_component, ensure the land_sea_mask and flow_direction are read in for "nutrientsurfacelayer" as well as "surfacelayer" components.
• [x] Add unifhy.component. **nutrientcompname** to the substituting class loop in test_instantiation_datacomponent() (causing an expected test failure as these won't exist yet)
• [x] Do the same for test_instantiation_nullcomponent()

test_clock.py

• [x] Add td_d,e,f, exp_d,e,f and exp_idx_d,e,f to the start of the TestClock class definition, corresponding to the time domains of the dummy nutrients components
• [x] Change the equivalent variables for the dumping to have the 'g' suffix (i.e. td_g etc.), making sure to also change all occurences of them
• [x] Add the 3 nutrient Components to the start of test_clock_init() and to the assertEqual statements below, using the variables created in the above 2 steps. The former will cause an expected test failure as Clock will not have been set up to expect nutrient Components.
• [x] Repeat for test_clock_iteration(), and add e, f, g to the loop over clock, and the corresponding if and append statements
• [x] Repeat for test_clock_incompatible_time_domains()
• [x] Repeat for test_clock_incompatible_dumping_frequency()
• Note: td_{a,b,c,d,e,f,g} are derived from the get_dummy_timedomain function in test_time.py . If the function is changed, then td_a,b,c,d,e,f,g, and thus exp_bool_a,b,c,d,e,f,g and exp_idx_a,b,c,d,e,f,g variables will need to be changed accordingly.

test_record.py

• [x] Add in the expected records for the 3 nutrient Components for the same_t and diff_t tests, like for the WaterEnergy Components. This will depend on the values in the input files and any processing in the dummy nutrient Components

Dummy component files

• [x] Add nutrient component folders in unifhy/tests/tests/components for nutrient components, like for the WaterEnergy components. Each folder needs to contain:
  • [x] an __init__.py file with just from .dummy import Dummy in it.
  • [x] a component_name.py file that replicates the equivalent WaterEnergy Component in all but name. The class that Dummy subclasses (one of the NutrientSurface, NutrientSubSurface or NutrientOpenwater classes) will not exist yet causing the test to fail as expected.
  • [x] a dummyfortran folder with blank __init__.py file and Makefile identical to those for the Fortran dummy WaterEnergy Components
  • [x] a dummyc folder with blank __init__.py file and Makefile & setup.py files identical to those for the C dummy WaterEnergy Components
• [x] Do the same for the Fortran versions, which involves:
  • [x] a dummy.f90 file in the dummyfortran folder which:
  • [x] has separate variables for each state timestep
  • [x] x, y and the outputs are also in the subroutine definitions and declared within the subroutines
  • [x] All other inputs used in them declared at the start of the subroutines
  • [x] The same calculations as done in the python version (without the unifhy routing function if it is used in the python version)
  • [x] Adding a Makefile in the dummyfortran folder, but this is identical across components
  • [x] Adding DummyFortran classes within the Nutrient Component dummy.py files. These pass the inputs and inwards to and receive the outputs and outwards from the Fortran subroutines, pass these to/from the exchanger, and perform any routing that needs doing, which can only be done from a python file.
• [x] And for the C versions which involves:
  • [x] A dummy.c file containing the C code for the initialise/run/finalise functions
  • [x] A dummy.h file that just contains the declaration statements for the functions
  • [x] A dummy.pyx file that wraps the C initialise/run/finalise functions in the dummy.c file in python/cython code
  • [x] Adding DummyC classes within the Nutrient Component dummy.py files which call the initialise/run/finalise functions defined in the dummy.pyx files.
• [x] Add the nutrient dummy Fortran and C components to the Makefile in unifhy/tests/tests/components
• [x] Specify some WaterEnergy <--> Nutrient transfers into/out of the Dummy Components as inwards/outwards in the nutrient dummy Components and corresponding WaterEnergy dummy Components.
• [x] Add nutrients components to yaml files in tests/configurations, copying the time and space setup from the WaterEnergy yaml files, and the transfers/datasets/params etc. from the dummy Components.

Dummy data files

There also needs to be:

• [x] dummy data to fit the tests. I e. the inputs/outputs specified in the dummy nutrients components. Copying the existing files for the WaterEnergy Components and adding/removing/changing the names of the data variables as needed should do the trick.
• [x] Substitute data for when components are tested as data components. These files need to have the outward transfers of the component in them. All the temporal and spatial resolution permutations also need to be covered, these are shown at thet op of the test_component.py file. Thibault's data-generators scripts can generate the data files once the values and permutations are input.

[mattjbr123]

Regarding the structure of the new dummy components. I have settled upon the setup shown in the diagram below. The key features are:

• Replication of the inputs to, outputs from and transfers between WaterEnergy Components in the Nutrient Components, with different names assigned to avoid ambiguity and errors
• The addition of two transfers between the WaterEnergy set of Components and the Nutrient set of Components, transfer_h and transfer_p.

The two transfers added are:

• From the Nutrient SurfaceLayer Component to the WaterEnergy SurfaceLayer Component (transfer_h)
• From the WaterEnergy OpenWater Component to the Nutrient OpenWater Component (transfer_p)

To accommodate these transfers the following edits were made to the WaterEnergy Components:

• OpenWater Component: transfer_p set to first division and current timestep of state_a
• SurfaceLayer Component: new output_y created which is transfer_h multiplied by the current timestep of state_a

The Nutrient Components are copies of the WaterEnergy components with only the transfer names changed as shown in the diagram below. The edits then made to accommodate the two new transfers added are:

• OpenWater Component: transfer_p added to output_y
• SurfaceLayer Component: transfer_h set to first timestep of state_a multiplied by ancillary_e

Further to this the new setup will require replication of the files that are used as input to the WaterEnergy Components, as noted in 'Dummy data files' in https://github.com/unifhy-org/unifhy/issues/93#issuecomment-1717762320. The expected records in test_record.py may also need to be changed to reflect the additional calculations as a result of the additional transfers.

[ThibHlln]

Hi Matt,

For the dummy files, you may find these scripts useful (I hope): https://github.com/hydro-jules/data-generators

As you will have noticed, I tried to keep the "equations" in the dummy components as simple as possible while using each input/transfer/parameter/state/constant at least once. This meant that the time series the components were producing were mostly made of integers or at least rational numbers (see https://github.com/unifhy-org/unifhy/blob/4105932ed7dfec34d428c1f2d2f85ec25ea522ed/tests/tests/test_utils/test_record.py#L10-L59 and https://github.com/hydro-jules/data-generators/blob/a4667021f7f0e4c9edf32eacd40f0d3394ce71c9/generate_dummy_cf_substitute_data.py#L35-L66). This was to avoid having to deal with floating point precision when comparing what was produced by the components vs. what I was expecting on paper. Since you are necessarily adding transfers between WaterEnergy and Nutrient, you will have to increase the "complexity" of these "equations", so you may not be able to avoid ending up with irrational numbers, but I guess it is not too bad.

[mattjbr123]

Thanks Thibault :) I was aware of this issue of possible irrational numbers, so I tried to keep the extra calculations as simple as possible but didn't actually check what the records would now come out as. That's my next job xD

It looks like I don't have access to the data-generators repo - I'm just getting a 404

[mattjbr123]

Adding in the expected records for the 3 nutrient Components for the same_t and diff_t tests to test_record.py took a long time due to the need to calculate 16 model timesteps by hand, with 6 components.

To ease this process for future development I created a script that users can trust to calculate these values for them once they input their dummy components. See issue #95

[mattjbr123]

Test updates (finally!) complete. Next step is to analyse which of these changes will result in the errors when the full framework is run and make changes to the framework to allow the tests to pass.