xfem
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| xfem [2008/06/28 21:13] – bp | xfem [2008/09/29 12:42] (current) – stephane.bordas | ||
|---|---|---|---|
| Line 18: | Line 18: | ||
| * See also general comments | * 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]] | * 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 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 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]] | * 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 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]] | * 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]] | * As I understand, all the xfem functions apart from resolveLinearDependency (see below) should be added to the parent class Node. ---[[rhc]] | ||
| Line 25: | Line 28: | ||
| == resolveLinearDependency() == | == 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]] | * 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, | * 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, | ||
| * 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]] | * 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 ==== | ==== Class CrackTip ==== | ||
xfem.txt · Last modified: 2008/09/29 12:42 by stephane.bordas