xfem
Differences
This shows you the differences between two versions of the page.
Next revisionBoth sides next revision | |||
xfem [2008/06/27 12:30] – created rumacik | xfem [2008/06/27 13:52] – rumacik | ||
---|---|---|---|
Line 5: | Line 5: | ||
==== Comments to the paper ==== | ==== Comments to the paper ==== | ||
+ | ---- | ||
=== General comments === | === General comments === | ||
- | * I generally agree with classes EnrichmentItem, | + | |
- | + | | |
- | * In the article method domain-> | + | * In the article method domain-> |
+ | ---- | ||
=== Class Element and Node === | === Class Element and Node === | ||
== Change at the parent class level == | == Change at the parent class level == | ||
- | * 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, | + | * 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, |
+ | * 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]] | ||
- | * We can also think about whether not have two versions of an element e.g. PlaneStress2D and PlaneStress2dXfem. PlaneStress2dXfem would inherit | + | As I understand, all the xfem functions apart from resolveLinearDependency (see below) should be added to the parent class Node. ---[[rhc]] |
- | * In fact, the same problem | + | 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 |
== resolveLinearDependency() == | == 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 | + | 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 connected |
- | :I do not think, it is so exceptional. I would directly put it as a method of class EnrichmentFunction. | + | It is definitely true, that linear dependency |
+ | 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 === | === Class CrackTip === | ||
- | == std:: | + | == std:: |
- | Why is this an attribute of the CrackTip class --[[rhc]] | + | I do not understand why material |
== CrackType tipID == | == CrackType tipID == | ||
- | What is meant by cracktype? --[[rhc]] | + | == void CrackTypeInitialization() == |
- | == std:: | + | == void CrackTypeUpdate() == |
- | Interaction integral is not the only method for the SIF computation, | + | What is meant by cracktype? |
+ | == 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< | ||
+ | Interaction integral is not the only method for the SIF computation, | ||
== Mu::Circle* defineDomainForUpdatedEnrichment() == | == Mu::Circle* defineDomainForUpdatedEnrichment() == | ||
- | Domain (Circle) is too specific in this case. --[[rhc]] | + | I find Circle too specific in this case. ---[[rhc]] |
- | == double | + | == double |
- | Again too specific. I suggest that it is part of the SIFIntegralMethod. --[[rhc]] | + | Radius of domain integration is very specific. I suggest that it is part of the SIFIntegralMethod |
+ | |||
+ | ---- | ||
=== Class EnrichmentDetector === | === 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. | + | 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. |
+ | |||
+ | ---- | ||
+ | |||
+ | === 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]] | ||
xfem.txt · Last modified: 2008/09/29 12:42 by stephane.bordas