Jon, > Is there a preferred way to obtain the actual coordinates of the point > at which the solution (and its derivatives and normals) are provided in > the DataPostprocessor class? For example, if one has a material with > varying elastic moduli, computing the stress may involve evaluating a > function to get the moduli at that specific point. If it isn't > implemented already, how difficult would it be to take this: > [...]
I think this is an oversight in the initial implementation of the class that I've also stumbled across on occasion. Since we like to not be incompatible with previous versions, we can't just change the signature of the function. That said, this is what can be done: - Add to the DataPostprocessor a *second* virtual function that has the signature you suggest - This function is not abstract (i.e. does not have =0) and its default implementation simply calls the other one, in the process forgetting about the support_points argument (by the way, rename it to evaluation_points, since they are not related to the support points of a finite element) - In the places in the library where we currently call the DataPostprocessor function, call the newly introduced one instead - If existing code then implements the old interface, everything is fine since the function still gets called - If new codes implement the new interface, they override the implementation in the base class and the right thing happens Want to give this a try? If you have some code that you'd like to share let me know and I'll see that it gets into the library! Best Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: [email protected] www: http://www.math.tamu.edu/~bangerth/ _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
