Phase-field model for fracture using MPI and AMR #203
Conversation
Updated Marc's email id
Some edits to your code gallery program.
|
@WasimNiyazMunshi is a visiting student in my lab, and I've contributed to this program. I would appreciate if someone else would handle this PR! |
There was a problem hiding this comment.
Nice work. The code looks fine! I did not check the formulas in the code, as they overstep my expertise. According to your manuscript, you validated your code against literature data, which suffices for me.
The following two points are more suggestions than requirements for being merged. Please apply according to your own assessment :)
- If you'd like, you can run a code indentation tool like
clang-formatover your source file, which further improves readability. - If you are feeling fancy: Consider collecting all parameters in a parameter class or multiple classes, and use the
ParameterHandler.
| /* for (const auto &face : cell->face_iterators()) | ||
| { | ||
| if (face->at_boundary() && | ||
| face->boundary_id() == 10) | ||
|
|
||
| { | ||
| fe_face_values_elastic.reinit(cell, face); | ||
| for (const auto i : fe_face_values_elastic.dof_indices()) | ||
|
|
||
| {const unsigned int component_i = | ||
| fe_elastic.system_to_component_index(i).first; | ||
| for (const auto face_q_point : | ||
| fe_face_values_elastic.quadrature_point_indices()) | ||
| { | ||
|
|
||
| cell_rhs_elastic(i) += | ||
| fe_face_values_elastic.shape_value( i, face_q_point) | ||
| *(traction_values_elastic[face_q_point][component_i]) | ||
| *fe_face_values_elastic.JxW(face_q_point); | ||
|
|
||
|
|
||
|
|
||
| } | ||
| } | ||
| } | ||
| }*/ |
There was a problem hiding this comment.
This part of the code is used to apply traction boundary conditions. We do not any have traction boundary conditions in the example considered here but I think it would be a good idea to keep this part there incase one wants to solve problems with traction boundary conditions.
| /*for (const auto &cell : dof_handler_damage.active_cell_iterators()) | ||
| if (cell->is_locally_owned()) | ||
|
|
||
| { | ||
| //for (const auto &face : cell->face_iterators()) | ||
|
|
||
| for (const auto vertex_number : cell->vertex_indices()) | ||
| { | ||
| const auto vert = cell->vertex(vertex_number); | ||
| const Point<3>& node = vert; | ||
| if (((std::fabs((z_max*(node(0)-0.5*x_max + A)) - 2*A*( node(2))) <10*l) | ||
| && node(1)>=0.9*y_max) | ||
| || ((std::fabs((node(0)-0.5*x_max + A)*z_max+2*A*(node(2)-z_max))<10*l) | ||
| && node(1)<=0.1*y_max)) | ||
| if ((vert(0) - 0.5*(x_min+x_max) < 1e-12) && | ||
| (std::fabs(vert(1) - 0.5*(y_min + y_max)) <= bandwidth)) // nodes on initial damage plane | ||
|
|
||
|
|
||
| { | ||
| const unsigned int dof = cell->vertex_dof_index(vertex_number, 0); | ||
| constraints_damage.add_line(dof); | ||
| constraints_damage.set_inhomogeneity(dof,1); | ||
| } | ||
|
|
||
| } | ||
|
|
||
| }*/ |
There was a problem hiding this comment.
The problem considered here does not have any initial crack (damage). But often times, the problems one solves involves a pre-existing crack. This part of the code sets up the necessary constraints on the damage field for the initial crack.
Removed the *else break* line in the run function. Also moved incrementing the iteration counter to the end of the while loop.
Make the use of template arguments look more uniform.
Use LA::MPI::Vector instead of TrilinosWrappers.
Use FEValues::get_function_values().
…the same dof_handler
…nary conditional operator wherever possible
…e accessed in the RandomMedium namespace
|
@blaisb, @Rombur and @marcfehling. |
|
As for the commented-out code blocks: @WasimNiyazMunshi suggests to leave them in there because many benchmarks are described with traction boundary conditions rather than displacements, and the commented out code is what you will need if you want to use the code for a traction-based modification. That seems reasonable to me. |
|
Yes. Also, the other block of commented out code is used to describe any
pre-existing cracks. This is very common in most of the benchmark problems
in fracture, so I suggest to keep that as well.
…On Sun, 15 Dec, 2024, 16:44 Wolfgang Bangerth, ***@***.***> wrote:
As for the commented-out code blocks: @WasimNiyazMunshi
<https://github.com/WasimNiyazMunshi> suggests to leave them in there
because many benchmarks are described with traction boundary conditions
rather than displacements, and the commented out code is what you will need
if you want to use the code for a traction-based modification. That seems
reasonable to me.
—
Reply to this email directly, view it on GitHub
<#203 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BLC5F7EQ5LVU43GAL5AR3GT2FYH55AVCNFSM6AAAAABQCLWRZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBUGE4TCNBVGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
This pull request adds a phase-field solver for fracture to the code gallery. The fracture model uses the MPI and Adaptive Mesh Refinement (AMR) capabilities of deal.II to solve large scale problems in 3D.