> 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… Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Sep 2, 2020, at 14:35, Matthew Knepley <[email protected]> wrote: > > On Wed, Sep 2, 2020 at 2:26 PM Jacob Faibussowitsch <[email protected] > <mailto:[email protected]>> 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 > <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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Sep 2, 2020 at 1:43 PM Jacob Faibussowitsch <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Mon, Aug 31, 2020 at 5:39 PM Jacob Faibussowitsch <[email protected] >>> <mailto:[email protected]>> 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 >>> >>> <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 >>> >>> <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/>
