xfem
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
xfem [2008/06/27 12:30] – created rumacik | xfem [2008/09/29 12:42] (current) – stephane.bordas | ||
---|---|---|---|
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 == |
+ | | ||
+ | * 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. | ||
+ | * 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]] | ||
+ | * In fact, the same problem | ||
+ | * I agree, it would not be a good idea... [[spab]] | ||
+ | * 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]] | ||
+ | * 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]] | ||
+ | * 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]] | ||
+ | * 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, | ||
- | == Change at the parent class level == | + | * I do not think, |
- | | + | * Yes, we should try and solve this dependency problem |
+ | ---- | ||
+ | ==== Class CrackTip ==== | ||
+ | == std:: | ||
+ | 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 | ||
- | | + | I understand that it represents the quantity, which will be integrated for SIFs ---[[bp]] |
+ | == 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 | ||
- | | + | ---- |
+ | ==== Class EnrichmentDetector ==== | ||
+ | * I generally agree with classes EnrichmentItem, EnrichmentFunction, GeometryEntity and IntegrationRule (already existing in oofem). I think that it will be possible | ||
- | == resolveLinearDependency() == | ||
- | 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 leave existence or non-existence |
+ | ---- | ||
- | === Class CrackTip | + | ==== Class CrackGrowthDirectionLaw and CrackGrowthIncrementLaw |
- | == std:: | + | * 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 |
- | Why is this an attribute | + | |
- | == CrackType tipID == | + | * Ok, we can dicuss |
- | What is meant by cracktype? --[[rhc]] | + | |
- | == std:: | + | |
- | Interaction integral is not the only method for the SIF computation, although | + | |
- | == Mu::Circle* defineDomainForUpdatedEnrichment() == | + | |
- | Domain (Circle) is too specific in this case. --[[rhc]] | + | |
- | == double giveRadiusOfDomainIntagration() == | + | |
- | Again too specific. I suggest | + | |
- | === 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