[CIG-SHORT] XFEM

[Brad Aagaard]

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.

  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.

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

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

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

Regards,
Brad