TDycore polymorphism, part 3: separating concerns

[jeff-cohere]

Continuing in our journey (see #211 and #214):

This pull request defines interfaces for all important operations needed by our different numerical discretizations. Specifically:

• TDy is now just a container with all the relevant information that describes a problem
• The TDy struct contains a context pointer that is used to manage the specific implementations using the function pointers defined in the ops table.
• The context pointer stores the WY, BDM, or MPFA-O implementation selected by TDySetDiscretization.
• The calculation of boundary conditions (for pressure, temperature, velocity) and sources/sinks (forcings) have been separated into a Conditions type. They have been "vectorized" in the sense that they now can compute their values on multiple points.
• All model data has been removed from the MaterialProps and CharacteristicCurves types, which now have reworked, vectorized interfaces. This allows different implementations to store material properties differently, instead of forcing them to have similar layouts. The MaterialProps and CharacteristicCurves interfaces now only compute model data.
• Moving model data out of the above types required some changes in the IO system, in addition to those made in the specific numerical implementations.
• There's a new EOS type that calculates properties of water.
• Some source files have been moved into new directories:
  • fe: the finite element discretizations and related utilities live here
  • materials: EOS, CharacteristicCurves, and MaterialProp live here
  • mpfao: the MPFA-O code lives here (not a new folder, but it has taken on new code)
• Many functions have been removed from the public interface and made internal.
• The MPFA-O mesh has been consolidated into a smaller number of source files, and it has been separated from TDy itself (because it's part of the MPFA-O implementation).
• The Fortran interface has been reworked with vectorized functions for material properties, boundary conditions, and forcings, like its C counterpart. All Fortran-related source files now live in src/f90-mod.
• Several memory leaks in the MPFA-O code have been plugged.
• Bonus: source files in the library are now built in a deterministic order, which helps when you're trying to fix a lot of things in various places. :-)

In particular, there's a much stronger sense of an "interface" for TDycore. Instead of any piece doing whatever it wants at any point, we're moving toward a set of interfaces that perform specific tasks in specific contexts in a way that suggests a flow of information that is easier to understand.

So where are we?

Everything works.

• I had to disable a test and some diagnostic output in transient_snes_mpfaof90 because it uses some low-level functions that arguably don't belong in a demo, like directly setting coefficients and extracting data, which implies knowledge of how things are indexed. Maybe we should discuss this when we have a chance.
• I've disabled the mesh geometry reading/writing capability, since it makes assumptions about the mesh construction process that no longer hold.
• The TH demos exhibited a very tricky problem that led to the addition of a set_dm_fields operation, required by all models, that set up the field layout on a DM before it's distributed. The way it was done before was not correct, but for some reason, we hadn't experienced any problems with it till now.

What's next?

The bad news is: not everything will be perfect after this PR goes in. A lot of cleanup remains, but much of it is within the separate numerical implementations, which lets different parts of our team adjust things without affecting others.

The good news: the changes in this PR make it easier for us to move in the direction of the DM-oriented problem definition that we started discussing in #211. Briefly: we attach functions to a DM for computing residuals, Jacobians, etc, and then we hand the DM over to the solvers. This allows us to make TDycore's interface smaller and tighter--the dycore produces a DM that gets used by the solvers directly.

Fixes #133 Fixes #196 Fixes #197 Fixes #22

[jeff-cohere]

UPDATE: I've fixed the transient_mpfaof90 demos and the transient_snes_mpfaof90 demos, aside from the one that reads in the mesh geometry data from a file (which I'm not convinced is working correctly, and which we might want to disable for the purposes of this PR).

The remaining tests are related to the TH model and the Richards driver. That sounds like a post-holiday adventure.

[jeff-cohere]

Okay, I've fixed some issues I found in the higher-level driver interface, which drives the richards and th demos. Now these drivers run, but they get bad answers. I could go ahead and find out exactly what's going on, but it would be faster if someone who knew more about the driver interface could help me understand the assumptions that it makes.

These demos and the transfer of saved geometry info in the transient_snes_mpfaof90 demo are the only issues remaining, as far as I can tell. @bishtgautam , maybe we should discuss how to proceed.

[jeff-cohere]

The Richards driver tests now pass. The TH ones still fail.

Also, I found the source of the issue with reading in mesh geometry from a binary file: the new mesh construction process has already converted indices to compressed row format by the time the data is read, whereas the old construction process read in the geometry before doing that conversion.

[jeff-cohere]

@bishtgautam and I agreed that we can comment out the mesh geometry reading/writing stuff for now, as we may not actually need it.

The TH tests are the only remaining failures.

[codecov-commenter]

Codecov Report

Merging #215 (fe06c7a) into master (b97463a) will increase coverage by 2.14%. The diff coverage is 67.55%.

@@            Coverage Diff             @@
##           master     #215      +/-   ##
==========================================
+ Coverage   49.48%   51.63%   +2.14%     
==========================================
  Files           4        4              
  Lines         685      765      +80     
==========================================
+ Hits          339      395      +56     
- Misses        346      370      +24     

Impacted Files	Coverage Δ
demo/transient/transient.c	0.00% <0.00%> (ø)
demo/steady/steady.c	54.13% <72.20%> (+2.72%)	:arrow_up:
demo/th/th_driver.c	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update b97463a...fe06c7a. Read the comment docs.