-
Notifications
You must be signed in to change notification settings - Fork 89
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
Preparatory work for fractures + wells #3021
Conversation
…re_2d_faultSlip_well.xml
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.
Thanks for enabling fault initialization
@@ -305,12 +305,12 @@ void SinglePhaseFVM< BASE >::applySystemSolution( DofManager const & dofManager, | |||
} ); | |||
} | |||
|
|||
template< > | |||
void SinglePhaseFVM< SinglePhaseBase >::assembleFluxTerms( real64 const dt, |
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.
I am trying to understand the logic here. what is proposed is always using BASE besides singlePhaseProppantBase specialization? And I guess this implementation is assumed not only being restricted to SinglePhaseBase.
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.
If I remember correctly, the change should be just related to the default template argument (SinglePhaseBase
), no changes in other logic. SinglePhaseFVM< SinglePhaseProppantBase >::assembleFluxTerms
is still down below.
this question is not quite relevant to this PR. I am curious how much work do you estimate to prototype when well is connected to fractures? need adding extra blocks in the Jacobin matrix? |
I would redirect this to @CusiniM for better estimate. |
I mean, I am ready to work on that, just need some guidance where to start. |
I don't think it's a lot of work. However, it would be nice to first refactor the way wells are handled by introducing a |
template class SinglePhasePoromechanics< SinglePhaseBase, SolidMechanicsLagrangeContact >; | ||
template class SinglePhasePoromechanics< SinglePhaseBase, SolidMechanicsEmbeddedFractures >; |
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.
is this necessary? Isn't it already being instantiated in SinglePhasePoromechanicsConformingFractures.cpp
?
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.
I remember that somehow it was important but I can double-check
Would it miss versions of SinglePhasePoromechanics functions when only present in SinglePhasePoromechanicsConformingFractures?
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.
ah yes, sounds possible
For now, assuming wells are not directly connected to the fractures.
In this version, only
SinglePhasePoromechanicsConformingFracturesReservoir
solver can run, although I am having hard time to build a well-behaving example. Other versions of solvers with wells are drafted but commented out for now.Added poromechanics initialization for contact solver - technically runs but needs refinements.
Side thing: add default template types to avoid too long nested definitions