[CIG-SHORT] XFEM

[Matthew Knepley]

On Wed, Aug 23, 2017 at 4:52 PM, Ehsan Haghighat <ehsanh at mit.edu> wrote:

>
> On Aug 23, 2017, at 3:53 PM, Brad Aagaard <baagaard at usgs.gov> wrote:
>
> On 08/23/2017 11:26 AM, Ehsan Haghighat wrote:
>
> Hi Brad,
> Getting more familiar with the geo-physical problems, I see a great
> advantage in using the Extended FEM to represent the fault geometry.
>
>
> Have you talked with Ethan Koon at Los Alamos National Laboratory? My
> understanding from talking with Matt Knepley our computational scientist on
> the PyLith development team is that after lots of work Ethan is convinced
> that XFEM inevitably leads to ill-conditioning due to the crack cutting
> through the edges of cells.
>
>
> No, I have not; I have seen his name on a document I found related to
> XFEM-PyLith that I think was very old (2010).
>
> I however cannot follow why XFEM enrichments lead to ill-conditioned
> system of equations and not the standard contact method. Both XFEM
> description of fault and contact model should result in very similar
> systems. That’s based my my own experience in modeling localization using
> XFEM (a problem similar to fault). http://onlinelibrary.
> wiley.com/doi/10.1002/nag.2368/full
>

This is not hard to see (and can be found in Ethan Coon's Columbia thesis
which is online). If you have a discontinuity which almost lines
up with a cell edge, then you generate an ill-conditioned system. This
behavior is ubiquitous.

  Thanks,

    Matt

>
> As a result, I am going through the code to understand where this can be
> implemented in a way that does not break the code and can be merged to the
> pylith in future (initial brainstorming, nothing implemented yet). Having
> said that, I have few questions regarding the details of implementations:
>
> - Do you have any thought how the crack surface can be defined?
>
>
> On the fly? No, I haven't thought about it. For existing faults, either a
> mesh-based approach or spline-surface approach could work.
>
>
> I think the natural way is to define fault by creating surfaces in the 3D
> model and mesh them. However, I am not sure if meshio utilities read these
> surfaces in their current state (or require additional development?)
>
>
> - Can parameter _numBasis be different for different elements? Or it has
> to be uniform all over the domain?
>
>
> Starting in PyLith v3.0 (the next major release), the number of basis
> functions will be defined per solution field, not for each material.
> However, a material (or fault) could have additional information, such as
> additional basis functions.
>
>
> How about each cell? Because in XFEM, only the cells cut by the fault
> require additional basis functions, not the whole domain.
>
>
> - Does pylith support combined Triangular/Quadrilateral meshes?
>
>
> PyLith uses the PETSc DMPlex data structure for finite-element mesh
> topology information. Matt Knepley can clarify whether DMPlex supports
> mixed cell meshes.
>
>
> Matt, can you please clarify here?
>
>
> It would be great if there is a chance to have a skype conversation; I
> would really like to discuss some challenges and hear your suggestions
> directly before jumping into this problem.
>
>
>
> My suggestion is to first talk with Ethan Koon (http://www.lanl.gov/
> expertise/profiles/view/ethan-coon) about his experiences trying to get
> XFEM working for faults. He can describe the computational challenges in
> much greater detail than I can.
>
>
> This is a good suggestion; I will contact him.
>
>
>
> Thanks Brad for your support.
>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20170823/4bca39ac/attachment.html>