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

Added an element test as a LIE cohesive zone benchmark #2157

Merged
merged 3 commits into from
Aug 5, 2018

Conversation

renchao-lu
Copy link
Contributor

This pull request is motivated to enrich secondary variables in the LIE/SmallDeformation as in the LIE/HydroMechanics, and add an element test for LIE cohesive zone model. The extended secondary variables consist of a fracture opening vector (w_n and w_s) and a fracture stress vector (f_stress_normal and f_stress_shear). With these output variables, it becomes more straightforward to make a comparison against the analytical solution in the element test.

@renchao-lu renchao-lu force-pushed the LIECohesiveZone_Benchmark branch 5 times, most recently from e0c3025 to 65db158 Compare July 6, 2018 11:22
@renchao-lu
Copy link
Contributor Author

renchao-lu commented Jul 13, 2018

Based upon the request, postTimestepConcreteProcess is replaced with computeSecondaryVariableConcrete in LIE/SmallDeformation.

@endJunction
Copy link
Member

Few more small things:

  • remove the executable flag from test files, e.g. Tests/Data/LIE/Mechanics/cohesive_zone_load_path.gml (chmod a-x Tests/Data/LIE/Mechanics/cohesive_zone_load_path.gml)
  • remove the pvd file from tests

@@ -89,10 +89,14 @@ AddTest(
TESTER vtkdiff
REQUIREMENTS NOT OGS_USE_MPI
DIFF_DATA
GLOB cohesive_zone_load_path_pcs_0_ts_*.vtu displacement displacement 1e-16 0
Copy link
Member

@endJunction endJunction Jul 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Put back the comparison of displacement, displacement_jump1, and sigma_*.
  • Use GLOB pattern, instead of writing out each time step.
  • The tolerances for the stress_n are rather loose; how come?
  • f_stress_n_analytical

Copy link
Contributor Author

@renchao-lu renchao-lu Jul 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GLOB pattern sounds like making the file comparison with an identical file name in the different folders. I am not sure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does compare the files from the source folder (expected output) to the build folder (ctest output) and the files are named identically. Simply do as for displacement etc.

Copy link
Contributor Author

@renchao-lu renchao-lu Jul 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expected output contains the analytical solution 'f_stress_n_analytical' which is not included in the ctest output though... Can we make a comparison against the analytical solution at some selected rather than all the instants?

auto mesh_prop_w_n = MeshLib::getOrCreateMeshProperty<double>(
const_cast<MeshLib::Mesh&>(mesh), "w_n",
MeshLib::MeshItemType::Cell, 1);
mesh_prop_w_n->resize(mesh.getNumberOfElements());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resize is not necessary. It's already done in the MeshLib::getOrCreateMeshProperty...

MeshLib::PropertyVector<double>* _mesh_prop_w_n = nullptr;
MeshLib::PropertyVector<double>* _mesh_prop_w_s = nullptr;
MeshLib::PropertyVector<double>* _mesh_prop_fracture_stress_shear = nullptr;
MeshLib::PropertyVector<double>* _mesh_prop_fracture_stress_normal = nullptr;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd try to use either _n and _s or _normal and _shear, but not to mix the both.

@renchao-lu
Copy link
Contributor Author

renchao-lu commented Jul 14, 2018

Checklist

  • Remove the executable flag from test files, e.g. Tests/Data/LIE/Mechanics/cohesive_zone_load_path.gml (chmod a-x Tests/Data/LIE/Mechanics/cohesive_zone_load_path.gml) [Done, appreciate it]
  • Remove the pvd file from tests [Done]
  • Put back the comparison of displacement, displacement_jump1, and sigma_*. [Done]
  • Use GLOB pattern, instead of writing out each time step. [Done]
  • The tolerances for the stress_n are rather loose; how come? [Fixed]
    Truncation of the variable 'w_n' causes the loss of accuracy in the previous calculation of analytical solution. Now it is fixed. The relative tolerance is reverted back to 5e-6.
  • f_stress_n_analytical [Done]
  • Clang-format [Learned, Done]
    Removed the particular commit for clang-formatting. Instead, it is done before making a commit.
  • Add a python script for describing how the analytical solution is computed (in Tests/Data/LIE/M) [to do]

@renchao-lu renchao-lu force-pushed the LIECohesiveZone_Benchmark branch 4 times, most recently from 1f436db to 175a9af Compare July 18, 2018 18:32
Copy link
Member

@endJunction endJunction left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

I was wondering how you computed the analytical solution; if there is a python script or something please include it here too (in Tests/Data/LIE/M). A description in "Selected Benchmarks" would be nice too.

@fparisio @nagelt You might want to have a look on the results.

Copy link
Member

@wenqing wenqing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

{
if (!_dofIndex_to_localIndex.empty())
{
auto const local_dof_size = local_x_.size();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can directly use local_x_.size() in the following for loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced accordingly.

auto const local_dof_size = local_x_.size();

_local_u.setZero();
for (unsigned i = 0; i < local_dof_size; i++)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change unsigned to std::size_t.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed accordingly.

@@ -45,6 +44,9 @@ class SmallDeformationProcess final : public Process
bool isLinear() const override;
//! @}

void computeSecondaryVariableConcrete(double const t,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late comment. AFAIK computeSecondaryVariableConcrete() is called after every single iteration.
In contrast postTimestepConcreteProcess() is called only after each timestep, so probably much less often. You seem to use the secondary variables only for output. Wouldn't postTimestepConcreteProcess() therefore suffice?
The only corner case that I am aware of is the output of iteration results. Or am I missing something?
For later developments, of course a preOutput() method would be a good option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought it would be the other way around, but it looks like the compute secondary vars is called just after postTimestep UncoupledTimeLoop.cpp.

I agree with the need for preOutput(). --> another PR.

I'd suggest to keep this implementation for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, implementation can be kept. Then I was wrong. Maybe then in the future the two methods can be combined.

@endJunction
Copy link
Member

@renchao-lu I've seen you want to add a python-script to the tests/data, that's great! Just add it when you are ready as another PR.

@endJunction endJunction merged commit 622b10c into ufz:master Aug 5, 2018
@renchao-lu renchao-lu deleted the LIECohesiveZone_Benchmark branch December 20, 2018 10:34
@ogsbot
Copy link
Member

ogsbot commented Jun 19, 2020

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants