Table of Contents

Xfem in oofem

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


General comments

—-

Class Element and Node

Changes at the parent class level

* I am personally not in favor of doing so, because the enrichment does not live at the element level, but at the patch level (node level). The rest of the structure should not have to know about it directly, only through the node, at least, this is how I see it right now. If we want to solve problems with different physics, we also need to know which field is enriched with what. A possible way to do this is probably to use the dof Manager. spab

* I agree, it would not be a good idea… spab

* EnrichmentManager is a possibility to avoid the info being held at the node level. I think we are trying here to go around a problem which is realted to the fact that we are not defining function spaces really. We could simply have something like a function space manager, and function spaces could live on different parts of the domain, this way, we avoid all that trouble. I think… spab

resolveLinearDependency()

* Both Element and Node clases have a function resolveLinerDependency(). I think that is a potential problem, because this method at least partly contains code which is connected to a particular type of Enrichment. This I slightly mind. I would like to see it in the implementation of EnrichmentFunction. Otherwise every time you add an EnrichmentFunction you will have to change classes Node and Element.—bp * This is a very good point, the enrichment should clearly be able to solve their own dependency problems, that was a mistake on our part. spab * It is definitely true, that linear dependency is connected to EnrichmentFunction. In case of Heaviside function, this method decides whether the enriched node changes to non-enriched, if one part of the cut nodal support is too big compared to the other one. So I think, in the paper they put it into Node class since they need to operate with the nodal support. I would probably solve it by an interface LinearDependency(), which will be inherited by EnrichmentFunction in case it suffers from it. The interface would have a reference to EnrichmentItem and a virtual function resolveLinearDependency().—rhc

* I do not think, the dependency 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.—bp * Yes, we should try and solve this dependency problem in a general way. The ingredients that come into it are the types of enrichment, and the mesh. We can also say it is the enrichment geometry and the mesh. In the general case, each enrichment function should know how to resolve this problem with the mesh. But the enrichment function is strongly dependent on the geometry of the enrichment feature, which means that this could be resolved at the mesh geometry interaction level. spab


Class CrackTip

std::vector<Material*>* matArray

I do not understand why material is an attribute of the CrackTip class —rhc

CrackType tipID
void CrackTypeInitialization()
void CrackTypeUpdate()

What is meant by cracktype? —rhc

FieldType field

Does this differentiation concern the current and auxiliary field? In this case it would be dependent on which method is used for the SIF computation —rhc

I understand that it represents the quantity, which will be integrated for SIFs —bp

std::valarray<double> computeInteractionIntegral(TimeStep *stepN)

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

Mu::Circle* defineDomainForUpdatedEnrichment()

I find Circle too specific in this case. —rhc

double giveRadiusOfDomainIntegration()

Radius of domain integration is very specific. I suggest that it is part of the SIFIntegralMethod (mentioned in computeInteractionIntegral(TimeStep *stepN)). —rhc


Class EnrichmentDetector

* 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

* 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. —rhc


Class CrackGrowthDirectionLaw and CrackGrowthIncrementLaw

* You mentioned that you would like to have it implemented as a part of the rest of the classes. In fact I liked the idea of having them as a base abstract class.—rhc

* Ok, we can dicuss it. I do not generally like to waste lots of classes for a particular problem. These two classes are basically just for the representation of discrete cracks, which is a small part of xfem. They will have lots of derived classes. Instead, there could be one class with an optional parameter, which decides on the direction law etc. But I do agree, that the idea is nicely with the object-oriented design.—bp