[petsc-dev] DMPlex + Cohesive Cells Setup

[Matthew Knepley]

On Wed, Sep 2, 2020 at 2:26 PM Jacob Faibussowitsch <jacob.fai at gmail.com>
wrote:

> It is a complicated topological problem and I do not have a general
> solution.
>
>
> Definitely. I’ve been writing my own impls in python this past month that
> follows the algorithm laid out here
> https://www.sciencedirect.com/science/article/pii/S2352711018300797 but
> without a robust topology framework (one that I’m not interested in
> reinventing the wheel for in python) I have stalled.
>
> 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.
>
>
> 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).
>
> 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.
>

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
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.

  Thanks,

      Matt


> 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.
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
>
> On Sep 2, 2020, at 14:08, Matthew Knepley <knepley at gmail.com> wrote:
>
> On Wed, Sep 2, 2020 at 1:43 PM Jacob Faibussowitsch <jacob.fai at gmail.com>
> wrote:
>
>> 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?
>>
>
> 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
> 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
> 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
> make a boundary label around the interior boundary so it can be clamped
> shut.
>
> 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.
>
>   Thanks,
>
>      Matt
>
>
>> Best regards,
>>
>> Jacob Faibussowitsch
>> (Jacob Fai - booss - oh - vitch)
>> Cell: (312) 694-3391
>>
>> On Sep 2, 2020, at 09:28, Matthew Knepley <knepley at gmail.com> wrote:
>>
>> On Mon, Aug 31, 2020 at 5:39 PM Jacob Faibussowitsch <jacob.fai at gmail.com>
>> wrote:
>>
>>> Hello All,
>>>
>>> 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:
>>>
>>> 1. Read the mesh
>>> 2. Perform some mesh analysis
>>> 3. Slap some cohesive cells along one/multiple areas identified in the
>>> previous step (maybe even everywhere?)
>>> 4. Save the new mesh
>>>
>>> This doesn’t even have to parallel.
>>>
>>
>> You can try it out easily. If it does not give you what you want, we can
>> fix that up.
>>
>>
>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexConstructCohesiveCells.html will
>> give you back a mesh
>> with the cohesive cells inserted. For input, you need a suitable label.
>>
>>
>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DMPLEX/DMPlexLabelCohesiveComplete.html#DMPlexLabelCohesiveComplete
>>  starts
>> with a label marking vertices on an internal surface and creates the
>> label needed by the call above.
>>
>> Let me know if that works.
>>
>>   Thanks,
>>
>>      Matt
>>
>>
>>> Best regards,
>>>
>>> Jacob Faibussowitsch
>>> (Jacob Fai - booss - oh - vitch)
>>> Cell: (312) 694-3391
>>>
>>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>> https://www.cse.buffalo.edu/~knepley/
>> <http://www.cse.buffalo.edu/~knepley/>
>>
>>
>>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200902/f2cbf14e/attachment-0001.html>