How does Cohesive zone actually works? for modelling stress with faults

[Traiwit]

Hi guys,

The documentation and examples for CZM are quite insufficient to me, I'm not sure how to implement it to my problem.

https://mooseframework.inl.gov/syntax/Modules/TensorMechanics/CohesiveZoneMaster/

Let's say the example below.

the objective of the simulation is to look into stress/strain change over mining steps (similar to coal mining problem)

Block = blockID saperation
Red = faults OR cohesive zone (cohesive element in Abaqus), as I read from 'CohesiveZoneMaster', BreakMeshByBlockGenerator will duplicate the note at the blocks above and below the fault line (red). Can I basically just import a similar Abaqus mesh without having to use BreakMeshByBlockGenerator?

Then I am not sure how does it work, will CZMInterfaceKernel automatically pick up these fault lines?

as I see from the example, I only see this ...

[Modules/TensorMechanics/CohesiveZoneMaster]
  [./czm1]
    boundary = 'interface'
    displacements = 'disp_x disp_y disp_z'
  [../]
[]

Then the properties of CohesiveZone is later defined under [Materials] block

  [./czm_3dc]
    type = SalehaniIrani3DCTraction
    boundary = 'interface'
    normal_gap_at_maximum_normal_traction = 1
    tangential_gap_at_maximum_shear_traction = 0.5
    maximum_normal_traction = 100
    maximum_shear_traction = 70
    displacements = 'disp_x disp_y disp_z'
  [../]

and that's pretty much it, I am not sure if MOOSE's czm is applicable to my problem, would be nice if we have cohesive elements like Abaqus instead, so we basically can identify the faults from an input mesh.

It would be nice if someone could shed some light. Thank you

Kind regards,
Traiwit

[Traiwit]

Just wondering if anyone has ever implemented CZM with MOOSE at all?

[hugary1995]

I'm not sure what you mean by "like Abaqus". Moose can definitely import a mesh from Abaqus .inp file though. Then BreakMeshByBlockGenerator should work.

@arovinelli knows more about czm in moose.

[Traiwit]

@jiangwen84 @arovinelli sorry gents, I still can't get over this

I'm checking BreakMeshByBlockGenerator.C I see it does 3 things, 1) making new duplicated nodes 2) attach the nodes back to the elements and then 3) create the cohesive interface. I only need to extract the last part (3) from the script.

ie I want to create a script that can generate cohesive interface from any of the available data listed below:

What I have available from Abaqus mesh are:

1. duplicated nodes (list of node pairs)
2. list of surface pairs
3. list of element pairs

is it possible to use any of these in order to generate the cohesive interface? I'm not very good with C++ it would be very helpful if you could point out which section of BreakMeshByBlockGenerator.C I should take out?

Thank you very much, much appreciated.

Kind regards,
Traiwit

[jiangwen84]

@Traiwit The MOOSE's CZM uses interface kernel (DG like) to enforce the CZM constitutive law. To make interface kernel to work, the element needs to know the information of its neighbor. In BreakMeshByBlockGenerator.C, we duplicate nodes and create new boundary for interface. One trick we did there is to keep the original element-neighbor information.

For your case, if you mesh already has disconnected interface, MOOSE won't know the element-neighbor information by directly reading the mesh. All you need to do is to manually set the neighbor information for the elements along the interface by using list of element pairs. There might not much staff that you can reuse from BreakMeshByBlockGenerator.C because the majority of that code is the node duplication.

[arovinelli]

To give you some background, we split the mesh on the fly without breaking the connectivity because we don't have to worry with element is a side neighbor of another element. In practice in MOOSE each element has a list of side neighbors.
Unfortunately, when you start from a disconnected mesh, that list is incomplete.
What you would need to do is to identify pairs of element neighbors, include which side is neighboring which side, i.e. elem 5, side 3 is a neighbor of elem 7 on side 1. once you have that list than it should be trivial to reconstruct the connectivity, but the code doing that, i.e. assigning a side neighbor to an element, is not in BreakMeshByBlock.
If reminder correctly once you have the list of [elem_id, elem_side, neighbor_id, neighbor_side] the command you should use is

Elem * current_elem = mesh->elem_ptr(elem_id)
Elem * neighbor_elem = mesh->elem_ptr(neighbor_id)
elem-> set_neighbor(elem_side, neighbor_elem->id())
neighbor_elem-> set_neighbor(neighbor_side, elem->id())

that should do it
the only annoyance is how to get the list...
you can do it in moose directly (safest way as when you import a mesh there is always the possibility elemntids get changes):
this would imply something like

1-loop over all the nodes find all duplicated nodes
2-construct a node-to-element-map adding adding to it only duplicated nodes
3-using the node to element map and duplicated nodes find what element shoudl be neighbors
4-use the code above to stitch them.

unfortunately is not going to be as easy as writing it.

[Traiwit]

Hi @arovinelli,

I believe we can extract the list of [elem_id, elem_side, neighbor_id, neighbor_side] from Abaqus mesh.

But I'm still unsure how to convert this information into cohesive interfaces.

Kind regards,
Traiwit

[jiangwen84]

@Traiwit I feel the effort to convert your Abaqus mesh would be more than to create a new mesh and assign blocks. You can use gmsh or cubit to build a mesh.

[arovinelli]

@jiangwen84 you need to reconstruct the connectivity somehow... as far as I know, there is not a generator available that start from a split mesh and reconstruct the connectivity or do we?

[jiangwen84]

@jiangwen84 you need to reconstruct the connectivity somehow... as far as I know, there is not a generator available that start from a split mesh and reconstruct the connectivity or do we?

@arovinelli Yes, we need to implement new generators. The current CZM interface generator uses blocks to define the interface location. A second option I suggest is to use lower dimension mesh to define the interface. But we need to make sure that lower dimension mesh sits on the element edges of the computation mesh. Either way we need reconstruct the connectivity.

[arovinelli]

@jiangwen84 you need to reconstruct the connectivity somehow... as far as I know, there is not a generator available that start from a split mesh and reconstruct the connectivity or do we?

@arovinelli Yes, we need to implement new generators. The current CZM interface generator uses blocks to define the interface location. A second option I suggest is to use lower dimension mesh to define the interface. But we need to make sure that lower dimension mesh sits on the element edges of the computation mesh. Either way we need reconstruct the connectivity.

If nodes are coincident wouldn't be easier simply to look for element with coincident faces but not sharing all the nodes? once we find the faces we simply add them to a boundary, still it would be difficult to discern between different surfaces...

[chunhuizhao478]

I think this question is relevant to our problem, so I would like to post my questions here: Is there a way for CZM to create/identify embedded cracks? I don't think the "BreakMeshByBlockGenerator" is able to handle this since there is no actual "block" between the crack interfaces. Or we need to get our hand dirty to pre-split, provide the list and write them in the code as suggested by arovinelli?

[hugary1995]

BTW, generating a CZM interface based on starting and ending points of a line segment is also useful for us, so I may be able to write a mesh generator to do that later this year. You are welcome to create an issue to help me track that

[chunhuizhao478]

"there should be an easy way to identify the blocks based on the starting and ending points of the pre-existing cracks." Just want to make sure if there is another way, all I can think of right now is write scripts and play around in MSH file to get the information, but it is not easy to do.

[hugary1995]

It might be easier to use the gmsh python api.

[chunhuizhao478]

Oh yes, that's also something I'm looking into. Thanks!

[chunhuizhao478]

Just to update the question I asked, Gmsh + MESHIO can do the trick.

[chunhuizhao478]

I would like to ask for the reference article if possible for cohesive zone model implementation in moose (It is mentioned that the cohesive zone model is implemented using a discrete Galerkin approach).

[hugary1995]

The jump is computed at qps on element edges. I don't quite get your 2nd question. Could you help me understand what you mean by "pass the motion forward to other surfaces"?

[chunhuizhao478]

Thanks, I’m just wondering if there is some continuity relations among the three nodes in the center so that if one surface has tangential jump, the other two surfaces can be affected (like a rupture propagates towards to other surfaces) or put it in the other way, how is cohesive zone model handle crack propagation in this case.

[chunhuizhao478]

Sorry if this may sound confusing, I try to understand how element cohesive zone surface interact with its neighbors

[Traiwit]

Hi guys, I still don't see the current MOOSE CZM and BreakMeshByBlockGenerator could handle more complex systems such as the one below:

These are C3D6 elements embedded within C3D4 mesh and connecting the node pair via NodalConstraint (works well with hydro/porousflow problems, but too expensive for mech problems)

I still believe introducing cohesive elements (zero thickness elements) still the way to go in the case that we already have pre-defined faults/cracks in the system.

Kind regards,
Traiwit

[jiangwen84]

IMO, the zero thickness and interface approaches are equivalent to handle cohesive conatraint. The issue for your problem is the preprocessing, which is not trival for either approach. BreakMeshByBlock is definitely not appropriate, but some of its algorithm can be used to create interface boundaries, e.g. BreakMeshByLowerDMesh.