Discussion on the design of the implementation of Xfem into Oofem. The discussion is based on the description of the implementation in the paper Bordas S et al., An extended finite element library, Int. J. Numer. Meth. Engng, 2007

• I generally agree with classes EnrichmentItem, EnrichmentFunction, GeometryEntity and IntegrationRule (already existing in oofem). I think that it will be possible to implement EnrichmentDetector, CrackGrowthDirLaw, CrackGrowthIncrementLaw into the rest of the classes. E.g. EnrichmentItem can have a method Grow. In case the EnrichmentItem is a crack, it will implement the functionality CrackGrowthDirLaw and CrackGrowthIncrementLaw.–bp

• In the article method domain→solveFractureMechanicsProblemAt() is mentioned. For the representation of the problem we have a class EngngModel –bp

• The most serious thing is that the xfem implementation in the article requires changes on the level of parent classes. If you want to implement a derived class, you inherit it from a parent class and from the parent class it should be obvious which functions should be implemented. In case an xfem support is added into class Element and someone will want just the classic Element without xfem, he will probably be confused as what he should implement. This problem I solve by interfaces (I got inspired in Java, because C++ does not have them, I use the inheritance). In case I need something specific on an element, I declare it in a class, say xyElementInterface, and if the element implements this functionality, it inherits also from xyElementInterface. Then I have a method, which finds out whether the element implements the interface and a method, which returns the Interface.–bp

• We can also think about whether not have two versions of an element e.g. PlaneStress2D and PlaneStress2dXfem. PlaneStress2dXfem would inherit from PlaneStress2d and solely added the Xfem interface.Everything is also motivated by saving memory. –bp

• In fact, the same problem is in Node class, but that we will probably have to accept. It would not probably be a good idea to have Node and XfemNode –bp

Both Element and Node class have a function resolveLinerDependency().I think that is a potential problem, because this method at least partly contains code which is connecte to a particular type of Enrichment. This I slightly mind. I would more like to see it in the implementation of EnrichmentFunction. Otherwise everytime you add an EnrichmentFunction you will have to change classes Node and Element.

:I do not think, it is so exceptional. I would directly put it as a method of class EnrichmentFunction. We also have to think whether the linear dependency cannot be caused also by an interaction of two different enrichment functions. I think that is generally possible, so we should think how to solve it.

Why is this an attribute of the CrackTip class –rhc

What is meant by cracktype? –rhc

Interaction integral is not the only method for the SIF computation, although it is true that it is the most often used. I think, it is too specific. There should be a reference for the base class SIFIntegralMethod or something of a similar name –rhc

Domain (Circle) is too specific in this case. –rhc

Again too specific. I suggest that it is part of the SIFIntegralMethod. –rhc

I would leave existence or non-existence of this class open. I have a feeling that lots of people are looking at how the changes in the enriched domain influence the solution. For this reason I find the existence of the class useful.