Moose XFEM capability

[Max]

Hi all,

I just noticed a XFEM folder in the modulus/, 

I am wondering what is the capability so far for XFEM in Moose?

Thank you,

Max

[Wen Jiang]

Hi Max,

Currently, the XFEM in MOOSE can do crack propagation for 2D and static crack for 3D. For static crack, you should be able to evaluate the J-integral and stress intensify factors at crack front. You can find some more tests in /moose/modules/combined/tests/solid_mechanics/xfem/

Please let me know if you have any more questions. 

Regards,

Wen

[Benjamin Spencer]

This is a capability that has been in the works for quite a while, and we recently made a major effort to clean this up in preparation to merge in the MOOSE code base.  This implementation is based on the phantom node method.  Wen is correct that this can currently do crack propagation in 2D and static cracks in 3D.  There is also some preliminary capability for crack branching in 2D. This was developed with fracture mechanics applications in mind initially, but the intent is to extend this to be applicable to a wide variety of problems, including material interfaces.

I have been meaning to send out an announcement of this to the list once we tied up a few more loose ends and got some better documentation in place, but I guess you beat me to that!  In the mean-time, you can certainly look at the tests that Wen pointed you to.

-Ben

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/4325ad55-f9e9-41aa-b4f6-a1590658de03%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antoine Jacquey]

Hi all,

I'm just reopening this post for a question related to the XFEM module.
I am looking for any textbook or references to dig in the XFEM capabilities since I may need to use this capability in one Moose-based application.
I had a look on the tests and the source code of the module and I would like to know if the developers used a particular book or publication on which this module is based.

Thanks a lot in advance!

Cheers,
Antoine

[Wen Jiang]

Hi Antoine,

The X-FEM in MOOSE is implemented based on the phantom node method[1]. In the phantom node method, elements intersected by a crack are deleted and replaced by two elements that occupy the same locations as the original elements. A portion of the domain of each of these new elements (partial elements) represents physical material, while the remainder represents non-physical.

The most important part of the code for this phantom node XFEM lies in the algorithm to create and connect the partial elements. The algorithm is based partly on the work of  C. L. Richardson [2].

The code was primarily developed for fracture problems. The crack propagation is based on maximum principle stress but users are free to implement other criterion to propagate the crack, such as maximum hoop stress. In stead of free traction on crack surfaces, pressure boundary conditions can be added on the crack surfaces. 

In addition to fracture problems, the X-FEM is extended to deal with material interface problems. The enforcement of  interfacial condition is based on the work of [3] and is implemented by ElemElem constraint system in MOOSE.

We are also drafting some papers on more details of the X-FEM capabilities/implementation in MOOSE and we will send them to you when we finish. 

Please let us know if you have any more questions.

Regards,

Wen    

1. A. Hansbo and P. Hansbo, “A finite element method for the simulation of strong and weak discontinuities in solid mechanics,” Compututer Methods in Applied Mechanics and Engineering, 193, 3523–3540 (2004)

2. C. L. Richardson, J. Hegemann, E. Sifakis, J. Hellrung, and J. M. Teran, “An XFEM method for modeling geometrically elaborate crack propagation in brittle materials,” International Journal for Numerical Methods in Engineering, 88,1042-1065 (2011).

3. J Dolbow and I Harari, An efficient finite element method for embedded interface problems. volume 78, issue 2, 2009, p 229-252.

[Antoine Jacquey]

Hi Wen,

Thanks for the information. I will have a look on these publications.

I am wondering what would be the best way to to this:
I want to solve for a variable u using a Kernel similar to CoefDiffusion (from the framework test folder). I also would like to assign different values of the coefficient (or a material property for example) to the elements on the fracture.
My idea was to couple the Kernel (or the Material) to the AuxVariable xfem_volfrac and then assign different values of the coefficient for diffusion if xfem_volfrac is smaller than 1.

Is there a better way to do that?

Thanks in advance.
Looking forward to read your drafts on the XFEM module with Moose!

[Wen Jiang]

Hi Antoine,

I think your idea is good. The xfem_volfrac can tell you which element is cut and its physical volume fraction. In the future, we plan to use level set to represent the interface and then you can use level set values to know which element is cut.

Regards,

Wen   

[Antoine Jacquey]

Hi Wen,

Could you explain the level set in more details please?

I just realised that the vol_frac auxiliary variable is defined for each element. Is there an alternative defined at the quadrature points which gives the information if the quadrature point is on one side of the cut frac?

I tried to add two fractures in 2D which are intersecting. I get the following error:

In element 123054 there are more than 2 cut fragment edges

Does that mean that intersecting fracs are not supported yet?

I have another question which may sound strange. 

Would it be possible instead of cutting the mesh to define the fractures to include directly the nodes inside the mesh. Then we could give in the input file a list of node ids which are on the frac and duplicate them and correct the connectivity. That would allow to have more complex geometries for the fractures.

In case it could be done, could you direct me to the functions in the code which are modifying the connectivity and creating the ghost points so I can give it a try.

Thanks in advance.

Cheers,

Antoine

[Wen Jiang]

Hi Antoine,

Could you explain the level set in more details please?

The level set function is used to represent the geometry of the interface implicitly. Usually it uses signed distance function. For example, you can describe a circle by a signed distance function \phi = sqrt(x^2 + y^2) - r. Inside the circle \phi < 0, outside the circle \phi > 0 and the circle is \phi = 0. It is very natural to use XFEM in conjunction with level set function. It is very useful for moving interface problems.

 

I just realised that the vol_frac auxiliary variable is defined for each element. Is there an alternative defined at the quadrature points which gives the information if the quadrature point is on one side of the cut frac?

Could you explain to me what you want to do with the cut elements? If you look at the quadrature points, I guess it is somehow related to the integration aspects of the partial elements. In XFEM, the typical method is the sub-triangulation of the partial element and then integrate over the physical part. In MOOSE, we use volume fraction method. For the cut element, we do the integration over the whole element and then times the volume fraction. It is a fairly good approximation of the actual integration. So you should not worry about which quadrature points is in physical or non-physical. 

I tried to add two fractures in 2D which are intersecting. I get the following error:

In element 123054 there are more than 2 cut fragment edges

Does that mean that intersecting fracs are not supported yet?

Currently we only support the "Y" shape branching but not "X" shape intersection. It is not hard to implement the "X" case though.   

 

I have another question which may sound strange. 

Would it be possible instead of cutting the mesh to define the fractures to include directly the nodes inside the mesh. Then we could give in the input file a list of node ids which are on the frac and duplicate them and correct the connectivity. That would allow to have more complex geometries for the fractures.

In case it could be done, could you direct me to the functions in the code which are modifying the connectivity and creating the ghost points so I can give it a try.

It is more like a traditional way of FEM to deal with fracture problem in the sense that you should have a conforming mesh which fits the fracture geometry. You should be able to use Cubit to generate this kind of mesh and the mesh file automatically takes care of the connectivity. However, X-FEM does not need to have a conforming mesh such that the crack can be embedded in the background mesh. In my opinion, X-FEM is more easier to generate complex geometry, particularly in 3D. 

Please let me know if you have more questions. 

Regards,

Wen

[Antoine Jacquey]

Hi Wen,

I plan to use the XFEM capability of MOOSE to model fluid flow (with Darcy's approximation), heat transfer (conduction and advection with fluid velocity) and tensor mechanics (elasticity first) in fractures.
It seems that the mechanics are well supported since you developed the module in this scope. However, I encountered several issues for modeling fluid flow.
Basically I need the pore pressure variable to be the same on both sides of the fracture (as in the test single_var_constraint_2d/stationary_equal) and I want the permeability (material property) to be higher on the fracture planes (Kernel used to solve for pressure is basically a diffusion kernel with the permeability as a coefficient) than in the unfractured elements.
I noticed that if I use the constraint XFEMSingleVariableConstraint with no jump, it works fine if I solve with the Diffusion Kernel. But if I solve with the CoeffDiffusion Kernel, convergence is not insured depending on the value of the coefficient (in my case it will be the permeability). I saw that this constraint takes a stabilization parameter as input. Do you know if changing the value of this stabilization parameter could help in the convergence in the case of the CoeffDiffusion Kernel?

Currently we only support the "Y" shape branching but not "X" shape intersection. It is not hard to implement the "X" case though.   

Good. Do you have any tips where to start to implement the "X" shape intersection case?

Thank you in advance.
Antoine

[Wen Jiang]

Hi Antoine,

I plan to use the XFEM capability of MOOSE to model fluid flow (with Darcy's approximation), heat transfer (conduction and advection with fluid velocity) and tensor mechanics (elasticity first) in fractures. It seems that the mechanics are well supported since you developed the module in this scope. However, I encountered several issues for modeling fluid flow.

I have not tried XFEM with Darcy's flow and it might have some issues. I am happy to help you figure it out :-)

 

Basically I need the pore pressure variable to be the same on both sides of the fracture (as in the test single_var_constraint_2d/stationary_equal) and I want the permeability (material property) to be higher on the fracture planes (Kernel used to solve for pressure is basically a diffusion kernel with the permeability as a coefficient) than in the unfractured elements.
I noticed that if I use the constraint XFEMSingleVariableConstraint with no jump, it works fine if I solve with the Diffusion Kernel. But if I solve with the CoeffDiffusion Kernel, convergence is not insured depending on the value of the coefficient (in my case it will be the permeability).

XFEMSingleVariableConstraint is based on Nitsche's method and it involves a gradient term on the interface. The implementation assumes the diffusion coefficient to be "1" on both side of the interface. For the case with different coefficient, you need add coefficient parameters and change the residual and jacobian by multiplying the _grad_* term with the correct coefficient. For  example, in the computeQpResidual, the r -= (0.5 * _grad_u[_qp] * _interface_normal + 0.5 * _grad_u_neighbor[_qp] * _interface_normal) * _test[_i][_qp]  should change to r -= (0.5 * _grad_u[_qp] * _coef_u * _interface_normal + 0.5 * _grad_u_neighbor[_qp] * _coef_u_neighbor * _interface_normal) * _test[_i][_qp]

If you have any difficulty and still have the convergence issue, you can send me your codes and input files. I can help you look at it. 

One more thing to mention is the constraint system currently does not work with branching and intersection case since we have not implemented the code to find the pairs of cut elements at those trijunction points. We would like to implement it in the near future. 

 

I saw that this constraint takes a stabilization parameter as input. Do you know if changing the value of this stabilization parameter could help in the convergence in the case of the CoeffDiffusion Kernel?

The stabilization parameter might affect your convergence behavior. It is related to the numerical stability issue. I think any value between 10~1000 should be reasonable.

 

Currently we only support the "Y" shape branching but not "X" shape intersection. It is not hard to implement the "X" case though.   

Good. Do you have any tips where to start to implement the "X" shape intersection case?

You can take a look at the XFEM.C file. It manages the mesh cutting algorithm. In particular, you can look at the function, markCutEdgesByGeometry. In this function, it first cut the element. If the element has already been cut, it tries to cut the fragment (partial element). Currently, we only cut one of the two fragments (partial elements) for the "Y" shape intersection and you need to cut both fragments for the "X" shape intersection, see the picture below. Basically we can recursively cut a element any times we want. It might not be easy for you to implement this and I will be happy to help you and implement some codes for you. 

Regards,

Wen

[Antoine Jacquey]

Thanks for your response Wen, it helped a lot.

I have not tried XFEM with Darcy's flow and it might have some issues. I am happy to help you figure it out :-)

I will continue trying. I may come back to you if I encounter any problem.

 

XFEMSingleVariableConstraint is based on Nitsche's method and it involves a gradient term on the interface. The implementation assumes the diffusion coefficient to be "1" on both side of the interface. For the case with different coefficient, you need add coefficient parameters and change the residual and jacobian by multiplying the _grad_* term with the correct coefficient. For  example, in the computeQpResidual, the r -= (0.5 * _grad_u[_qp] * _interface_normal + 0.5 * _grad_u_neighbor[_qp] * _interface_normal) * _test[_i][_qp]  should change to r -= (0.5 * _grad_u[_qp] * _coef_u * _interface_normal + 0.5 * _grad_u_neighbor[_qp] * _coef_u_neighbor * _interface_normal) * _test[_i][_qp]

If you have any difficulty and still have the convergence issue, you can send me your codes and input files. I can help you look at it. 

I manage to run a 2D case with a line fracture with my Darcy Kernel. However, I notice that it is not possible now to get Material properties from the Constrain class. Do you know if having an interface to material properties could be possible?

One more thing to mention is the constraint system currently does not work with branching and intersection case since we have not implemented the code to find the pairs of cut elements at those trijunction points. We would like to implement it in the near future. 

This would be really useful for me. Please tell me if I can be of any help.

You can take a look at the XFEM.C file. It manages the mesh cutting algorithm. In particular, you can look at the function, markCutEdgesByGeometry. In this function, it first cut the element. If the element has already been cut, it tries to cut the fragment (partial element). Currently, we only cut one of the two fragments (partial elements) for the "Y" shape intersection and you need to cut both fragments for the "X" shape intersection, see the picture below. Basically we can recursively cut a element any times we want. It might not be easy for you to implement this and I will be happy to help you and implement some codes for you.

I will have a look at this function and try to add the X shape.

Thanks a lot again.
Cheers,

Antoine 

[Wen Jiang]

Hi Antoine,

I manage to run a 2D case with a line fracture with my Darcy Kernel. However, I notice that it is not possible now to get Material properties from the Constrain class. Do you know if having an interface to material properties could be possible?

Yes, it is definitely possible. I just pushed a branch that tests the non-stateful material property in the constraint system. 

https://github.com/jiangwen84/moose/tree/test_mat_prop_elem_elem_constraint  

You can take a look at it and let me know if you have any questions. I also developed the capability to use stateful material property and I think it will be merged soon. :-)

Regards,

Wen 

[Philipp Schädle]

Hi all,

I came across this discussion and read it with great interest. 

I would like to ask if you did any further development regarding flow in fractured porous media, particularly two-phase flow. 

As I am only interested in flow, and no mechanics, it is sufficient to consider static fractures. What kind of fracture intersections does the Moose xfem module currently support? 

Best,

Philipp

[Benjamin Spencer]

Phillipp,

  We have not yet attempted to apply XFEM to porous flow problems, but the way it is implemented, it should work generally with any physics models in MOOSE.

  The ability to model intersecting fractures is still in development.  It works in 2D, and it can't handle two simultaneous fracture planes in an element -- you have to first insert one of the fractures, followed by the other one.  The test:

moose/modules/xfem/tests/solid_mechanics_basic/square_branch_quad_2d.i

is a simple demonstration of this.

-Ben

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/3ba54fd7-3ade-4c79-8171-690c445d7b03%40googlegroups.com.

[Philipp Schädle]

Thanks Ben. I will have a look at the test to see how it works.

Regarding the flow problem it seems that if I combine the porous flow module with the XFEM module, that I would still need to implement flow along a fracture as well as a kernel function for the transfer from fracture to the matrix, right?

-Philipp

Am Dienstag, 7. Februar 2017 00:24:53 UTC+1 schrieb benjamin.spencer:

Phillipp,

  We have not yet attempted to apply XFEM to porous flow problems, but the way it is implemented, it should work generally with any physics models in MOOSE.

  The ability to model intersecting fractures is still in development.  It works in 2D, and it can't handle two simultaneous fracture planes in an element -- you have to first insert one of the fractures, followed by the other one.  The test:

moose/modules/xfem/tests/solid_mechanics_basic/square_branch_quad_2d.i

is a simple demonstration of this.

-Ben

On Mon, Feb 6, 2017 at 11:04 AM, Philipp Schädle <philipp....@gmail.com> wrote:

Hi all,

I came across this discussion and read it with great interest. 

I would like to ask if you did any further development regarding flow in fractured porous media, particularly two-phase flow. 

As I am only interested in flow, and no mechanics, it is sufficient to consider static fractures. What kind of fracture intersections does the Moose xfem module currently support? 

Best,

Philipp

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

[Wen Jiang]

Philipp, 

Regarding the flow problem it seems that if I combine the porous flow module with the XFEM module, that I would still need to implement flow along a fracture as well as a kernel function for the transfer from fracture to the matrix, right?

Yes, you need to solve the flow along the fracture. To apply the pressure on the fracture surface, I would suggest you use constraint system. We have simple interfacial constraint examples in xfem/tests/single_var_constraint_2d.