Erroneous result while applying cohesive zone at inclined interface

[AmanKumar0301]

Hi @arovinelli @jiangwen84 I was trying to regenerate a patch test for cohesive zone model (see the attached figure, patch test-b). My geometry is a square of 1mm x 1mm dimension. I used BreakMeshByBlockGenerator to break the geometry along its diagonal (diagonal connecting the points (0,1) and (1,0)). Two triangular blocks are created as a result. I inserted PureElasticTractionSeparation CZM at this interface. Then applied displacement boundary condition at the top edge and right edge in order to create a pure mode-II loading.

However the generated results are erroneous. Neither the expected traction nor expected displacement are generated.

Correct results are being generated for CZM interface aligned along the Cartesian axes for patch test-a. However, for test-b, I suspect that erroneous result being generated has something to do with inclined interface. I applied the same loading/BCs without insertion of cohesive zone and yet the results are exactly same and erroneous. I cannot understand why is it happening. Please help.

[arovinelli]

@AmanKumar0301
That would be a major mistake that neither me or wen caught when developing or validating the model.
So I would say it's unlikely, but possible.
There are two set of traction vector, local traction (defined in the interface coordinate system) and global traction (defined in the sample coordinate system). Are you sure you are looking at the right set?
Also without you showing us the results of the simulation it's impossible to say if something is wrong

[AmanKumar0301]

Here is the MOOSE script that I am running:



I have applied traction BC at the right edge and top edge in +ve x-axis and +ve y-axis direction. So effectively it should simulate mode-1 opening normal to the interface. Also, with the given values of traction and penalty stiffness a normal jump of 1mm is expected. However see the following results:




Non of the above results is correct.
It is noteworthy that for other cases where I simulated the interface along Cartesian axes direction, the results are correct. For example, for patch test-a (see the image in 1st question), I am getting the correct result.

[arovinelli]

Important on the bottom, consideration on the top

something is weird. The result of the simulation you are running are not converged. You can't have different stresses on the two elements (you are using a stress prescribed BC), equilibrium is not satisfied.
Check your residual, I would be really surprised if that is 0~ish. The solution seems to be garbage.
Also did you check results without CZM (you said you did but I'm just curios at this point).
Can you add the tangential traction, which according to your configuration should be identically 0.
Can you ran it using Neumann BC, i.e. traction if your element size is 1. Pressure is kind of a complicated one.
The CZM results are only reported on the element belonging to the master surface, so I'm not surprised to see zeros on the right side.
It would interesing to see the residuals on both surfaces (tensor mechanics, see master action add

extra_vector_tags = 'F_x F_y'

IMPORTANT CONSIDERATIONS

I'm wondering, and now maybe remembering, that the preset nodal fields might not include the proper nodes.

you might want to add something like in here czm_multiple_action_and_materials.i see [add_side_sets] in mesh generation block to make sure you are indeed applying the right BC to the proper nodes or to generate your mesh in cubit and appropriately define side-sets.

I really suspect this is the problem.
When you break the mesh using BreakMeshByBlockGenerator, new nodes are added, and old side-set (left,right,top and bottom) might become incomplete, and not include the nodes that you are thinking. you can visualize them in paraview.

[AmanKumar0301]

Thanks a lot for your reply and thanks for your interest.

In the previous case, the results were converged. But they were garbage (incorrect) as you mentioned, and that is why I posted. I did check the side_sets in paraview for visualization before applying Bcs. And the side_sets top, bottom, left and right were all correctly visible.

Now, I followed your advice and generated side_sets based on type SideSetsFromNormalsGenerator. And the script is indeed working now and correct results are generating. I am so so thankful to you for bringing this aspect into my notice. I was struggling for more than a week now. But you saved me.

I have been meshing in GMSH. I want to ask you whether this traigular type element (with controlled dimension) can be generated in MOOSE itself in order to avoid future difficulties.

Also, I went through MOOSE database of CZM. There are three cohesive laws which have been implemented:

1. PureElasticTractionSeparation
2. BiLinearMixedModeTraction
3. SalehaniIrani3DCTraction

Are you considering implementing other traction separation laws e.g. exponential law?

Suppose I want to implement my own traction separation laws, how can I do so? I am working on exploring cohesive zone simulation through MOOSE. Till now I have been relying on already developed modules and solely using the MOOSE scripting to generate results. I don’t have background in C++. So please suggest.

I also request you to develop Cohesive Zone module in MOOSE to bring it at par with other commercially available softwares. If there are any shortcomings or something additional needs to be done, please do consider.

[arovinelli]

I'm glad it worked. We should probably add a warning in the cohesive model description about regenerating side sets.

To answer your questions:

• Moose is pretty flexible in terms of mesh generation, most case are handled.
• If you need something you cannot achieve with a mesh generator use cubit from SNL.
• I can't develop other cohesive zone models simply because my job now does not entail that, and I don't have funding for doing it. The last time I worked on CZM was 3 years ago, since then I moved to LANL and now I'm working with other solvers.
• if you need to develop your own model i suggest you looking at the CZM documentation which should explain fairly well how it's done. Find your eqautions and try. you don't need to be an expert in C++ .
• The exponential model should be the SalehaniIrani3d except that is not stateful, i.e. it does not have a linear unload after an exponential load, so it does not keep track of damage directly

Hope this helps
Cheers