From: Roy Stogner <roystgnr@ic...>  20071004 17:40:14

On Thu, 4 Oct 2007, Yujie wrote: > Because I have several variables in my system. The code I previously suggested will work just fine no matter how many variables are in your system. > I think the following codes should be better. It is from > equation_systems::build_discontious_solution_vector(): That code doesn't do what you asked, though; you said you wanted to get the solution all on one processor. If what you really want is a nodal interpolant of the solution all on one processor, then the code we use for generating visualization output will work fine too. > I always want to confirm whether the reference element in FE:inverse_map() > is isoparameter element? No. The shape functions are determined by your FEType; the mapping functions are determined by your Elem type. Elements may be iso, super, or subparametric. > We will integrate on the isoparameter element. The > integrate results on the physical element can be obtained by the values > times Jacobian. Inverse_map() want to get point (physical element)'s > position (reference element). inverse_map() may be used to simplify the code when integrating on element sides; but not on element interiors. On element interiors the reference points are generated directly by the quadrature rule and only forward maps are ever needed (if you get_xyz()). > if the FEtype is firstorder lagrange. I think it is simple to get > such corresponding relationship. If the FEtype is complicated, it > will be difficulat to perform inverse_map(). Is it right? An inverse_map() requires a Newton iteration, which will take more than a step or two if you're not using linear geometric elements, but it's hardly difficult, and as far as your code is concerned it's all inverse_map().  Roy 