[petsc-dev] DMPlex + Cohesive Cells Setup

Wed Sep 2 14:57:21 CDT 2020

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

> 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.
>
>
>  don’t have any reliable way of determining the origin of the crack path
> and hence can’t selectively put them in places. The mesh will be subjected
> not only to physical external loads but internal stresses due to heat-flux
> and other fluid flow. Not that it can be entirely avoid, but selectively
> putting in the cohesive elements makes the crack mesh-dependent which would
> be minimized if the elements are everywhere.
>
> you should probably just try to reformulate as a hybridized DG method,
> since that is what you would have essentially.
>
>
> If I was writing my own solver, sure, but there is a lot of infrastructure
> available through warp that rewriting it all in my own impls is unpalatable…
>

More precisely, the complication in the existing methods comes _precisely_
from the fact that not all faces are split. If they all are, then you just
have
hybridized DG plain and simple.

  Thanks,

     Matt

> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
>
> On Sep 2, 2020, at 14:35, Matthew Knepley <knepley at gmail.com> wrote:
>
> 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/>
>
>
>

-- 
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/894fb50c/attachment-0001.html>