Hi Wolfgang, Thank you very much. Your answer was very helpful.
> You're correct -- the mapping classes don't do that. I also think that they > shouldn't: They have a different purpose and at least at the moment I don't > quite see how that could be put into what the mappings are supposed to do. The > place to do it might be where the FEValues class combines quadrature weights > with the determinant of the Jacobian -- though I might still think that it's > not so cumbersome to just keep everything in user code -- it'll be at most a > dozen lines of code for most applications. It is not cumbersome at all to implement it in the assembly function. I implemented it, and it is just one extra line of code in the assembly function. The big advantage I find in somehow including that 2πr factor in the JxW(), applies when having a big code that solves several PDEs on the same domain, using 3D, 2D or axisymmetric geometries in general. In that case, it would be advantageous not to need to change every single assembly function depending on what kind of geometry you have, just use a different FEValues and implicitly include that factor on the JxW(). This would be in line with the generic programming approach of Deal.II for dimension-independent implementations, using the <dim> templates. > Can you point out where the places you mention about the documentation are? > Maybe we can clarify the text there. I think it was my big misunderstanding. I misinterpreted some points in this <https://dealii.org/developer/doxygen/deal.II/classMappingManifold_1_1InternalData.html> documentation page, but it was completely my mistake and I think the page is well-written. I could not understand how to connect the manifold to the Mapping, but now it is clear to me. Thank you very much for clarifying. > If you wanted to, that would > make for a nice pull request to get used to contributing to the library! ;-) ) Thank you for the invitation. I will try to see whether and what I can contribute. On Thursday, November 14, 2019 at 6:02:33 AM UTC+2, Wolfgang Bangerth wrote: > > > Andreas, > > > You are right that one could just leave the mapping as a simple 2D and > change > > the weak formulation. However I think that it is possible to solve an > > axisymmetric problem without touching the weak formulation. > > You can, in principle, but it requires some tricks. If you want to use an > axisymmetric formulation, then in essence you formulate your shape > functions as > phi_i(r,phi,z) > so that they are only defined on a r/z mesh, with no dependence on phi -- > but > nevertheless defined in 3d. The point is that you have to have a 2d mesh > for > the cross section in 3d. It's not a convenient set up. It's easier to > recall > that if you have > > \int_\Omega F(r(x,y,z),z) dx dy dz > > (i.e., with an integrand that formally depends on x,y,z, but in reality > only > on r,z) can be expressed as > > \int_a^b \int_0^{2pi} \int_0^R F(r,z) r dr dphi dz > = 2pi \int_a^b \int_0^R F(r,z) r dr dz > > In other words, the only change to the bilinear form is the addition of a > factor of 2*pi*r to all integrals that might appear in the formulation -- > not > a bothersome task. > > > > I have been > > working for quite some time with GetDP, and there that is the standard > way. > > I'm curious how that works there. > > > > For axisymmetric problems one just needs to change the "Jacobian" which > in > > GetDP stands for the mapping between real cells and the reference/unit > cell. > > So maybe the only difference there is the factor of 2*pi*r to |det J| > (which > is part of the JxW factor that appears in every deal.II integral). > > > > I > > think the two approaches in the end boil down in the same equations and > system > > assembly. In one case the coordinate transform scaling factors are > considered > > as a part of the PDE and need to be explicitly inserted in the weak > form, > > while in the other they are considered as part of the cell mapping and > would > > appear implicitly in the jacobian of the transfrom (the JxW factors in > the > > Deal.II framework). > > Yes, that seems reasonable. > > > > From a programming point of view, I think that the latter approach > would > > produce more generic and reusable code, that is why I first tried to > pursue > > it. I thought that this could be done in Deal.II, similarly to GetDP, by > using > > an appropriate Mapping object. I guess such a Mapping class is not > implemented > > though. In case I am wrong and it is (maybe a MappingManifold associated > with > > a CylindricalManifold), would it be possible to help on how to implement > it? > > You're correct -- the mapping classes don't do that. I also think that > they > shouldn't: They have a different purpose and at least at the moment I > don't > quite see how that could be put into what the mappings are supposed to do. > The > place to do it might be where the FEValues class combines quadrature > weights > with the determinant of the Jacobian -- though I might still think that > it's > not so cumbersome to just keep everything in user code -- it'll be at most > a > dozen lines of code for most applications. > > > > In general, how can I associate a MappingManifold object with a certain > > Manifold object? In the documentation, such an association is mentioned > > several times, but it is not specified how it can be implemented. > > Every piece of a triangulation (cell, face, edge) has a manifold > associated > with it. MappingManifold will simply use whatever it finds on a given > object > -- you don't need to explicitly associate anything. > > Can you point out where the places you mention about the documentation > are? > Maybe we can clarify the text there. (In fact: If you wanted to, that > would > make for a nice pull request to get used to contributing to the library! > ;-) ) > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5165a8a1-669d-434a-8936-a62e213db6a4%40googlegroups.com.
