Closed jeff-cohere closed 2 years ago
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.
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.
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.
@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.
Merging #215 (fe06c7a) into master (b97463a) will increase coverage by
2.14%
. The diff coverage is67.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.
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 problemTDy
struct contains a context pointer that is used to manage the specific implementations using the function pointers defined in theops
table.TDySetDiscretization
.Conditions
type. They have been "vectorized" in the sense that they now can compute their values on multiple points.MaterialProps
andCharacteristicCurves
types, which now have reworked, vectorized interfaces. This allows different implementations to store material properties differently, instead of forcing them to have similar layouts. TheMaterialProps
andCharacteristicCurves
interfaces now only compute model data.EOS
type that calculates properties of water.fe
: the finite element discretizations and related utilities live herematerials
:EOS
,CharacteristicCurves
, andMaterialProp
live herempfao
: the MPFA-O code lives here (not a new folder, but it has taken on new code)src/f90-mod
.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.
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.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