You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer, I want the drainage functionality to be separated from the elements, such that the elements become more maintainable and extendible and easier to understand.
Acceptance criteria
All functionality related to drainage, which could have different implementations (i.e. transient, drained and undrained) is moved to a separate class using the strategy design pattern see e.g. wikipedia for a bit more info.
Three strategies/policies are created, all deriving from an abstract interface, to provide the drainage functionality.
As discussed as apart of #12067 the interface for this policy will provide the following two functions to add the coupling, permeability and compressibility contributions to the left and right hand side:
AddToLHS(Matrix& rLeftHandSideMatrix, …, const callBack) and
As a developer, I want the drainage functionality to be separated from the elements, such that the elements become more maintainable and extendible and easier to understand.
Acceptance criteria
As discussed as apart of #12067 the interface for this policy will provide the following two functions to add the coupling, permeability and compressibility contributions to the left and right hand side:
where the callBack will hold references on required functions and it will be populated by an element (this implementation detail might still change).
We estimated this to be 13 SP, but removing it for now, since it's not ready to be picked up, and still needs to be split up
The text was updated successfully, but these errors were encountered: