<div dir="ltr"><div dir="ltr">On Wed, Sep 2, 2020 at 2:26 PM Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com">jacob.fai@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>It is a complicated topological problem and I do not have a general solution. </div></div></div></blockquote><br></div><div>Definitely. I’ve been writing my own impls in python this past month that follows the algorithm laid out here <a href="https://www.sciencedirect.com/science/article/pii/S2352711018300797" target="_blank">https://www.sciencedirect.com/science/article/pii/S2352711018300797</a> but without a robust topology framework (one that I’m not interested in reinventing the wheel for in python) I have stalled.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>Maybe if you explain a little more about the problem you want to use it for, I can suggest some things to make it easier.</div></div></div></blockquote><div><br></div>I am using a different code (warp3D if the name is familiar) to do some fairly large-scale fracture mechanics simulations which is to be integrated into a stack of other simulations. warp3D offers 2 methods of crack propagation, element-extinction and cohesive zone model. Warp requires the mesh to have the cohesive elements pre-baked into it (AFAIK it cannot generate them on the fly). I am fairly locked into using warp3D as well as the cohesive element approach (element extinction is currently used but doesn’t play nice). <div><br></div><div>My goal is therefore to insert cohesive elements into an existing tet mesh. The meshes are arbitrary, massive, and geometrically complex and the loading configuration is equally unpredictable so it is unfeasible to try and predict intelligently where to insert the cohesive elements.</div></div></blockquote><div><br></div><div>This is the part I do not understand. Isn't the whole point of cohesive elements that they are not everywhere? All the papers they are citing in the one you link use them only along</div><div>the crack path. If you are going to crack every face in your mesh, you should probably just try to reformulate as a hybridized DG method, since that is what you would have essentially.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> Accuracy of the crack-front paths are of vital importance, so the only viable options are to either insert the elements everywhere, or in closely packed grains that permeate the whole mesh.</div><div><br></div><div><div><div>
<div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>Best regards,<br><br>Jacob Faibussowitsch<br>(Jacob Fai - booss - oh - vitch)<br>Cell: (312) 694-3391</div></div>
</div>
<div><br><blockquote type="cite"><div>On Sep 2, 2020, at 14:08, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="ltr">On Wed, Sep 2, 2020 at 1:43 PM Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com" target="_blank">jacob.fai@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I’m getting an argument out of bounds error (attached) but I suspect it’s because I’m feeding in bad input to either calls (I am marking __all__ vertices in the mesh in my input label to DMPlexLabelCohesiveComplete). Are the cohesive grains allowed to intersect? Does a cohesive region have to be closed? Does it have to be entirely enclosed by the mesh, i.e. not touching any of the boundaries?</div></blockquote><div><br></div><div>I see. If you want every face in the mesh pulled apart, we will likely have to write another implementation. For the fault problem, it is essential to</div><div>figure out what side of the fault each cell is on. It is a complicated topological problem and I do not have a general solution. Thus you cannot have</div><div>crossing faults in my implementation. You can have one fault dead-end into another. It can touch a boundary. If it ends inside the mesh, you should</div><div>make a boundary label around the interior boundary so it can be clamped shut.</div><div><br></div><div>Maybe if you explain a little more about the problem you want to use it for, I can suggest some things to make it easier.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>Best regards,<br><br>Jacob Faibussowitsch<br>(Jacob Fai - booss - oh - vitch)<br>Cell: (312) 694-3391</div></div></div><div></div></div><div><div></div><div><br><blockquote type="cite"><div>On Sep 2, 2020, at 09:28, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">On Mon, Aug 31, 2020 at 5:39 PM Jacob Faibussowitsch <<a href="mailto:jacob.fai@gmail.com" target="_blank">jacob.fai@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hello All,<div><br></div><div>What is the simplest possible configuration required to insert cohesive cells into a plex? Plex/tests/ex5.c would be the example to ape here but there is a lot there that I don’t (think) I need like a DS or any kind of physics. For now, I am essentially looking to:</div><div><br></div><div>1. Read the mesh</div><div>2. Perform some mesh analysis</div><div>3. Slap some cohesive cells along one/multiple areas identified in the previous step <span>(maybe even everywhere?)</span></div><div>4. Save the new mesh</div><div><br></div><div>This doesn’t even have to parallel. </div></div></blockquote><div><br></div><div>You can try it out easily. If it does not give you what you want, we can fix that up.</div><div><br></div><div><a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexConstructCohesiveCells.html" target="_blank">https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexConstructCohesiveCells.html</a> will give you back a mesh<br></div><div>with the cohesive cells inserted. For input, you need a suitable label.</div><div><br></div><div><a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexLabelCohesiveComplete.html#DMPlexLabelCohesiveComplete" target="_blank">https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexLabelCohesiveComplete.html#DMPlexLabelCohesiveComplete</a> starts<br></div><div>with a label marking vertices on an internal surface and creates the label needed by the call above.</div><div><br></div><div>Let me know if that works.</div><div><br></div><div> <span> </span>Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>Best regards,<br><br>Jacob Faibussowitsch<br>(Jacob Fai - booss - oh - vitch)<br>Cell: (312) 694-3391</div></div></div><br></div></div></blockquote></div><br clear="all"><div><br></div>--<span> </span><br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></blockquote></div><br clear="all"><div><br></div>--<span> </span><br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>