-
Notifications
You must be signed in to change notification settings - Fork 239
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
Local coordinate system #2370
Local coordinate system #2370
Conversation
ad47ae8
to
2eba549
Compare
Codecov Report
@@ Coverage Diff @@
## master #2370 +/- ##
==========================================
- Coverage 32.9% 32.73% -0.18%
==========================================
Files 530 530
Lines 19816 19850 +34
Branches 9258 9325 +67
==========================================
- Hits 6521 6498 -23
- Misses 9975 9999 +24
- Partials 3320 3353 +33
Continue to review full report at Codecov.
|
2eba549
to
9bb8ef3
Compare
I just took a brief look on the project file - for me it's ok. One question: How to define multiple local coordinate systems? |
@JobstM Do you mean for different material groups? Or, indeed, multiple, space-dependent coordinate systems? |
I mean the possibility to define several coordinate systems, which could be used eg in different areas (material groups) or different material models (eg permeability, elasticity, heat conductivity). Example: A model with 3 material groups, in material group 1, the permeability tensor is inclined by 20 deg, in material group 2 and 3 by 30 deg. |
c742830
to
afdd43f
Compare
_base[1]->getNumberOfComponents() != 2) | ||
{ | ||
OGS_FATAL("The parameters for the 2D basis must have two components."); | ||
} |
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.
In case there are wrong input by mistakes, it is also good to check the values of the bases, such as e_i \dot e_j := (i==j) ? 1, 0.
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.
Checking the determinant of the transformation matrix to be close to 1. In debug build only, though.
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 see.
OGS_FATAL( | ||
"The parameters for the 3D basis must have three components."); | ||
} | ||
} |
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.
Here the same, to check the values of the base vectors.
</variables> | ||
</output> | ||
</time_loop> | ||
<local_coordinate_system> |
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.
There may be not only one local system in some cases. It might be good to use a nested elements as
<local_coordinate_system>
<local_coordinate_system>
<name> x1 </name>
<basis_vector_0>e0</basis_vector_0>
<basis_vector_1>e1</basis_vector_1>
</local_coordinate_system>
</local_coordinate_system>
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.
@JobstM Material group dependent coordinate systems are not a problem with a single <local_coordinate_system> tag.This is because the parameters for the base vectors can be group based. An (untested) example:
<local_coordinate_system>
<basis_vector_0>e0</basis_vector_0>
<basis_vector_1>e1</basis_vector_1>
</local_coordinate_system>
<parameters>
<parameter>
<name>e0</name>
<type>Group</type>
<group_id_property>MaterialIDs</group_id_property>
<index_values>
<index>0</index>
<values>1 0 0</value> <!-- e0 for first material -->
</index_values>
<index_values>
<index>1</index>
<value>0.707 0.707 0</value> <!-- e0 for second material -->
</index_values>
</parameter>
<parameter>
<name>e1</name>
<type>Group</type>
<group_id_property>MaterialIDs</group_id_property>
<index_values>
<index>0</index>
<values>0 1 0</value> <!-- e1 for first material -->
</index_values>
<index_values>
<index>1</index>
<value>-0.707 0.707 0</value> <!-- e1 for second material -->
</index_values>
</parameter>
</parameters>
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.
More local_coordinate_system-tags are then only necesary if different parameters for the same material group have distinct principle directions? Or is there a way to represent this in the structure, too?
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 see. The current implementation can handle multi-local systems
@ThieJan Like this (figure from the Internet)
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.
What Jan says is correct, the multiple <local_coordinate_system> tags would only be necessary if, for example, temperature diffusion lives in a different coordinate system than the hydraulic permeability.
Suggest to wait until such a project comes up; the implementation is simple, just a name and instead of boolean <use_local_coordinate_system> a specific coordinate system would be referenced.
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.
Another possible input could be:
<local_coordinate_system>
<basis_matrix>basis</basis_matrix>
</local_coordinate_system>
<parameters>
<parameter>
<name>basis</name>
<type>Group</type>
<group_id_property>MaterialIDs</group_id_property>
<index_values>
<index>0</index>
<values>1 0 0 0 1 0 0 0 1</value> <!-- basis for first material -->
</index_values>
<index_values>
<index>1</index>
<values>0.707 0.707 0 -0.707 0.707 0 0 0 1</values> <!-- basis for second material -->
</index_values>
</parameter>
</parameters>
5d56d4f
to
682872c
Compare
e0103a1
to
ffe4466
Compare
@TomFischer or @wenqing I've added a 3D test for anisotropy but had to extend the GWF. Could you please review the last two commits? |
ffe4466
to
1661688
Compare
ProcessLib/Utils/ProcessUtils.cpp
Outdated
|
||
if (it == parameters.end()) | ||
{ | ||
return nullptr; |
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 a usual case? Maybe add also some debug output to detect if there is an error?
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 nullptr is checked later by the caller, which issues a warning or whatever.
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. ⏩
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 3D test looks good.
⏩
@@ -28,6 +28,34 @@ namespace GroundwaterFlow | |||
{ | |||
const unsigned NUM_NODAL_DOF = 1; | |||
|
|||
template <int GlobalDim> | |||
Eigen::Matrix<double, GlobalDim, GlobalDim> hydraulicConductivity( |
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.
Nice. It can be a common function for similar tensor parameters.
@@ -757,3 +757,5 @@ AddTest( | |||
DIFF_DATA | |||
square_1x1_quad_1e5.vtu square_1e5_volumetricsourceterm_pcs_0_ts_1_t_1.000000.vtu analytical_solution pressure 0.75e-4 1e-16 | |||
) | |||
|
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 (NOT OGS_USE_MPI)
OgsTest(PROJECTFILE "Elliptic/cube_1x1x1_GroundWaterFlow/cube_1e4_anisotropic.prj")
endif()
1661688
to
12443b4
Compare
The truncated version is not exactly comparable with the coordinate transformation version and results deviate by 10^-7. Better to use accurate representation of the tensor for the comparisons.
Only for debug mode, because the transformation can not be efficiently precomputed in the general case.
Calls corresponding to the dimension rotation function from the coordinate system.
And set the coordinate systems in those parameters having this tag set true.
12443b4
to
baf3fe9
Compare
I've removed the split of findParameterOptional and findParameterByName, because there is a circular dependecy (on header files level) btw. the ProcessLib and MaterialLib. This is handled in a different PR. |
OpenGeoSys development has been moved to GitLab. |
See the project file for the new possibilities.
<local_coordinate_system>
and a tag in permeability parameter "k" for usage.The designated parameters will be transformed according to the given local coordinate system.
An additional if-condition is introduced in all parameters, but it has less than 1% impact on the runtime.
Review commit-wise is possible.
TODO: