Hi Wolfgang, Thanks so much for the response, this is exactly what I was looking for! A few follow-up questions:
1. For the projection operation that you describe, are you specifically talking about this implementation <https://www.dealii.org/current/doxygen/deal.II/namespaceVectorTools.html#a51a13e948e1296dbfdfc297167e4fd5a> of the projection() function (the [5/7] implementation)? I ask because it seems like the others require a Function object for which we need the FEFieldFunction class, rather than just something that eats a quadrature & cell index and gives back the value at the given quadrature point. If so, am I reading it correctly that this is only for a scalar-valued finite element function? How would we do this with vector-valued functions? 2. With respect to accuracy (that is, neglecting speed of computation or ease of implementation) are either of these methods better? My guess would be that projection is more (the most?) accurate in an L2 sense, while interpolation is more accurate in some other sense. 3. Is this kind of operation described in any of the tutorial steps, do you know? 4. Is this how folks typically do post-processing? Really what I would like to do is extract eigenvectors corresponding to the largest eigenvalues from my 3x3 tensor solution data and plot those as a vector field. Would this be something that is typically done with scripts in a visualization software (e.g. Paraview, Visit), or is that done in the C++ source? Just trying to get a sense for best practices... Again, thanks so much for the help! - Lucas On Monday, July 12, 2021 at 11:03:02 PM UTC-5 Wolfgang Bangerth wrote: > On 7/12/21 5:56 PM, Lucas Myers wrote: > > > > I'd like to apply a method to a finite element function (that is, > something > > that looks like the solution vectors) in order to get another finite > element > > function. For example, suppose my finite element function is a symmetric > > rank-2 tensor in type, and I would like a finite element function which > is a > > vector of its eigenvalues. I haven't been able to find anything in the > > tutorials which do this (though maybe I'm skimming too much). > > > > My naive approach would be to (i) construct a dealii Function which > evaluates > > some finite element vector (function?) at a given point and then (ii) > use the > > Interpolation or Projection functions from the VectorTools namespace. > However, > > I am not sure whether Interpolation or Projection would be a better > idea. > > Further, I don't know how to evaluate a finite element function at an > > arbitrary point -- only at quadrature points via the FEValues class. > Also I > > would be unsure how to build that into a Function class. > > > > Let me know if there's a better way to do this -- it seems like > something > > that's probably already implemented. > > Lucas, > do I understand right that what you want is something like > v_h = f(u_h) > where f(u) is some function of the solution? If so, you're right that that > cannot hold pointwise if u_h is a finite element function and v_h should > also > be a finite element function unless f has a special structure and the > spaces > for u_h and v_h match. So you need > v_h = I_h f(u_h) -- interpolation > or > v_h = Pi_h f(u_h) -- projection > Which of these two you choose typically depends on the application you > have. > The projection only requires you to apply f at quadrature points, and so > that's going to be easy. For I_h, you need to evaluate f(u) at the *nodal* > points of the space for v_h. That too is not complicated but you probably > want > to write the interpolation function yourself, after looking at how this is > implemented in VectorTools::interpolate. > > The cheap way to do the latter (but also the slow way) is to use the > FEFieldFunction class to evaluate u_h at arbitrary points. You'd then > write > your own class derived from Function that gets a point as argument, calls > FEFieldFunction to evaluate u_h(x), computes f(u_h(x)), and returns that > value. This kind of function you can then provide to > VectorTools::interpolate. > The problem is that FEFieldFunction is expensive. If you don't care about > speed, this is the way to go. If you do for whatever reason care about > speed, > go with the approach in the previous paragraph :-) > > Best > W. > > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > 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 dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/4fb1e098-41b4-47eb-a9f3-817c3d845d5fn%40googlegroups.com.
