oofem-wiki

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

====== 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 ====
  * The most serious thing is that the xfem implementation, as described in the article, requires changes on the level of basic FEM classes, i.e. modification (extensions) of basic element and node classes. This has two principal drawbacks:
    - if someone will want just the classic Element without xfem, he will be probably confused as what he should implement, when looking at base Element class. I want to keep basic element interface as simple as possible. This problem can be elegantly solved by interfaces (I got inspired in Java, because C++ does not have them, I use the inheritance). In case I need some specific functionality 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]]
    - the modification of basic fem classes will also introduce some variables declared at this level, that are only related to xfem. For analyses without xfem this will lead to wasting of space. ---[[bp]]
  * In the article method domain->solveFractureMechanicsProblemAt() is mentioned. For the representation of the problem we have a class EngngModel ---[[bp]]

----
==== Class Element and Node ====

== Changes at the parent class level ==
  * See also general comments  
  * We can think about whether not to 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]]
  * I am not very happy about this solution. Probably there could be an XFEMManager (Domain attribute), which keeps the list of enrichment on each node. In this way we could get around the problem of keeping this information on the Node. Nothing would have to be added to the Node class.---[[bp]]
  * As I understand, all the xfem functions apart from resolveLinearDependency (see below) should be added to the parent class Node. ---[[rhc]]

== 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]]

* 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]]

----
==== 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]]

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Share Alike 4.0 International