-
Notifications
You must be signed in to change notification settings - Fork 239
Add the shape function order to ProcessVariable class #1503
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
Conversation
…ry variables use the same order
…aceFlux and TestExtrapolation
0f5551b
to
c1d1d43
Compare
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.
Looks good and cleaner than my previous approach.
I'd though prefer explicit order=1 in the project files.
(I'll rebase HM on top of this before making PR.)
I'll add the order=1 in the project files. |
@@ -34,6 +34,9 @@ ProcessVariable::ProcessVariable( | |||
_bc_builder(new BoundaryConditionBuilder()) | |||
{ | |||
DBUG("Constructing process variable %s", _name.c_str()); | |||
//! \ogs_file_param{prj__process_variables__process_variable__order} | |||
auto opt_shapefunction_order = config.getConfigParameterOptional<int>("order"); | |||
_shapefunction_order = (opt_shapefunction_order ? opt_shapefunction_order.get() : 1); |
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.
When the order is given in the prj files, then this default choice can be removed and the tag becomes non-optional. ✅
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.
The change is nice. I have only one comment.
@@ -34,6 +34,9 @@ ProcessVariable::ProcessVariable( | |||
_bc_builder(new BoundaryConditionBuilder()) | |||
{ | |||
DBUG("Constructing process variable %s", _name.c_str()); | |||
//! \ogs_file_param{prj__process_variables__process_variable__order} | |||
auto opt_shapefunction_order = config.getConfigParameterOptional<int>("order"); | |||
_shapefunction_order = (opt_shapefunction_order ? opt_shapefunction_order.get() : 1); |
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.
Need an assert somewhere such that this input order is not larger than the order of element of the mesh.
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.
it's not possible because Mesh/Element class doesn't know which order it is. In current implementation, LocalDataInitializer is checking if a proper element is found for the given shape function order.
e6bf53a
to
a6312df
Compare
OpenGeoSys development has been moved to GitLab. |
Until now, the shape function order is decided by the order of the given mesh. This PR enables users to specify the shape function order in a config file, which can be different from the order of the given mesh, though appropriate mesh (e.g. 2nd order mesh for use of linear or quadratic order shape functions) should be provided.
This PR is extracted & modified after Dima's HM branch and is needed for implementing HM and "HM with LIE" processes, which use linear order for pressure and quadratic order for displacements. Major changes are
Remarks
<order>1</order>