[CIG-SHORT] XFEM

Ehsan Haghighat ehsanh at mit.edu
Wed Aug 23 13:52:58 PDT 2017


> 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 <http://onlinelibrary.wiley.com/doi/10.1002/nag.2368/full>

> 
> 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20170823/39848453/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1846 bytes
Desc: not available
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20170823/39848453/attachment-0001.bin>


More information about the CIG-SHORT mailing list