Skip to content
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

Post-215 work: support Fortran material properties/char curves functions with contexts #216

Open
jeff-cohere opened this issue Dec 1, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@jeff-cohere
Copy link
Collaborator

jeff-cohere commented Dec 1, 2021

In #215 I had to disable the transient-snes-mpfaof90-region test case in the transient_snes_mpfaof90 demo regression suite because it uses some functions that I had as part of the new material properties / characteristic curves abstractions:

  • TDySetCharacteristicCurveVanGenuchtenValuesLocal
  • TDySetCharacteristicCurveMualemValuesLocal

We need to support coupling with other models (like PFlotran and E3SM's land models), but this is not the way to do it. Rather, we need to extend our support for C functions that provide contexts (e.g. MaterialPropsSetPorosity) to be available in Fortran as well. This can be done using trickery similar to that used in PETSc for passing optional contextual data to solvers (to evaluate residuals and Jacobians, for example).

@jeff-cohere
Copy link
Collaborator Author

Depending on how we plan to use these functions, there's an opportunity here to incorporate more geometry. The code I commented out in the transient_snes_mpfaof90 demo isn't very sophisticated--it just assigns the whole domain to a uniform set of parameters for relative permeability. I'm sure we need more heterogeneity in general.

@bishtgautam , what kinds of "stratigraphy" are we interested in modeling with TDycore? Are we interested in sampling curve parameters from distributions? Maybe we need to support reading in these parameters from a file generated by an external tool. Or, if different regions of the problem (identified by labels, say) are sampled from different distributions, we could read from files on a per label/region basis.

Can you point me at anything that illustrates how ELM (or a demo that wants to validate itself against PFlotran, say) might need to specify the saturation and relative permeability coefficients? Or let me know if I'm overthinking this. :-)

@jeff-cohere jeff-cohere removed their assignment Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant