Dear Roy:
The following codes is about global_displacement from
ex8. I change "displacement" in .get_vector() using my variables'
name. I can get the corresponding values of my variables by using different
variables' name? However,
how to know the corresponding
relationship between the index of this vector and the global index of
point in the mesh, global
degree of freedom number in parallel?
dof_no may not be local in parallel runs, so we may need a global
displacement vector
NumericVector<Number> &displacement
= t_system.get_vector("displacement");
std::vector<Number> global_displacement(displacement.size());
displacement.localize(global_displacement);
Write nodal results to file. The results can then be viewed with e.g.
gnuplot (run gnuplot and type 'plot "pressure_node.res" with lines' in the
command line)
res_out << t_time << "\t"
<< global_displacement[dof_no]
<< std::endl;
In addition, regarding the codes from build_discontious_solution_vector();
I think that
update_globle_solution() for geting all solutions on one processor. ?
00602 for (unsigned int i=0; i<dof_indices.size(); i++)
00603 elem_soln[i] = sys_soln[dof_indices[i]];
for dispatching the values to the corresponding point of variable.?
00605 FEInterface::nodal_soln (dim,
00606 fe_type,
00607 elem,
00608 elem_soln,
00609 nodal_soln);
for interpolating?
Is it right?
thanks a lot.
Regards,
Yujie
On 10/4/07, Roy Stogner <roystgnr@...> wrote:
>
> 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
>
