xfem
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
xfem [2008/06/27 12:30] – created rumacik | xfem [2008/06/28 21:13] – bp | ||
---|---|---|---|
Line 4: | Line 4: | ||
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// | 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// | ||
- | ==== Comments to the paper ==== | + | ---- |
+ | ==== General comments | ||
+ | * The most serious thing is that the xfem implementation, | ||
+ | - 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, | ||
+ | - 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-> | ||
- | === General comments | + | |
- | * I generally agree with classes EnrichmentItem, | + | ---- |
+ | ==== 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]] | ||
+ | | ||
+ | * I am not very happy about this solution. Probably there could be an XFEMManager | ||
+ | * As I understand, all the xfem functions apart from resolveLinearDependency (see below) should be added to the parent class Node. ---[[rhc]] | ||
- | === Class Element and Node === | + | == 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]] | ||
- | == Change at the parent class level == | + | * It is definitely true, that linear dependency is connected to EnrichmentFunction. In case of Heaviside function, this method decides whether |
- | | + | |
- | | + | * I do not think, the dependency is so exceptional. I would directly put it as a method of class EnrichmentFunction. |
- | | + | ---- |
+ | ==== Class CrackTip ==== | ||
+ | == std:: | ||
+ | I do not understand why material | ||
+ | == 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]] | ||
- | == resolveLinearDependency() == | + | I understand that it represents the quantity, which will be integrated for SIFs ---[[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 | + | == std:: |
+ | Interaction integral is not the only method for the SIF computation, | ||
+ | == 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]] | ||
- | :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 | + | ---- |
+ | ==== Class EnrichmentDetector ==== | ||
+ | | ||
- | === Class CrackTip === | + | * 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 |
- | == std:: | + | |
- | Why is this an attribute | + | ---- |
- | == CrackType tipID == | + | |
- | What is meant by cracktype? | + | ==== Class CrackGrowthDirectionLaw and CrackGrowthIncrementLaw ==== |
- | == std:: | + | * You mentioned |
- | Interaction integral is not the only method for the SIF computation, | + | |
- | == Mu::Circle* defineDomainForUpdatedEnrichment() == | + | * 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]] |
- | Domain (Circle) is too specific in this case. --[[rhc]] | + | |
- | == double giveRadiusOfDomainIntagration() == | + | |
- | Again too specific. I suggest that it is part of the SIFIntegralMethod. --[[rhc]] | + | |
- | === Class EnrichmentDetector === | ||
- | 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. | ||
xfem.txt · Last modified: 2008/09/29 12:42 by stephane.bordas