-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added a function registry for referring to functions by name. #192
Conversation
Codecov Report
@@ Coverage Diff @@
## master #192 +/- ##
=======================================
Coverage 67.73% 67.73%
=======================================
Files 7 7
Lines 1221 1221
=======================================
Hits 827 827
Misses 394 394 Continue to review full report at Codecov.
|
I've added support for selecting porosity and forcing functions using the same method. The For permeability (which we're not yet doing in this Fortran demo), we might have to have a "tensor function" Fortran type (as opposed to the "scalar function" type we're currently assuming), to accommodate the different rank of the function's range. If we wanted to shoehorn all functions into the same type, we'd have to stipulate that the function's values are stored in an array instead of a scalar. I expect we'll discuss this stuff when it becomes more interesting. |
@@ -305,7 +312,8 @@ program main | |||
CHKERRA(ierr); | |||
|
|||
if (pflotran_consistent) then | |||
call TDySetPorosityFunction(tdy,PorosityFunctionPFLOTRAN,0,ierr); | |||
! call TDySetPorosityFunction(tdy,PorosityFunctionPFLOTRAN,0,ierr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be eventually make TDySetPorosityFunction
an internal TDy lib function and not expose it to the world?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. If people like the registry idea and want to use it exclusively, I see no reason we couldn't make this and the other similar functions internal/private.
This PR adds a registry for named functions. This lets a demo/driver program register functions (in C or Fortran) that can be selected for boundary conditions. We can also use these functions for forcing functions and other volumetric quantities. All functions live in the same namespace.
The basic functionality is demonstrated in the
transient_snes_mpfaof90
demo. Instead of callingTDySetBoundaryPressureFn
, we registerPressureFunction
under the name "p0" with a call toTDyRegisterFunction
, and then we select the boundary pressure function usingTDySelectBoundaryPressureFn
and referring to "p0". The original mechanism (TDySetBoundaryPressure
) is still supported, and is in fact used by the new registry selection thingy.This allows us to do all sorts of things that were previously difficult, including using names of functions in command line arguments, and embedding function names in mesh files. We can now register these functions in our demos/drivers and e.g. create mesh files specifically for those drivers that can associate different domain boundary surfaces with different named functions. For now, we only allow a single boundary function, but we can expand that when we're interested in doing so.
(I'm excited by this PR, because I've figured out a way to make the Fortran 2003 interoperability standard cooperate with PETSc's bespoke Fortran bindings!)
Also included: I added a
TDyOnFinalize
function to allow us to register shutdown functions that are called whenTDyFinalize
is called. This allows us to write subsystems without the basic foundation having to know about them.(In service of #188)