Re: [Libmesh-users] on post processing

[Derek G. <fri...@gm...>]

In case that's not clear... just hold on to that Node& you get in the  
beginning and keep using it to look up the dof each time.  That Node  
reference will stay valid throughout the run (with the stipulations  
that Ben mentioned such as redistribution with ParallelMesh).

Derek

On Feb 11, 2009, at 6:40 AM, Kirk, Benjamin (JSC-EG) wrote:

> One such invariant should be the node address, barring  
> redistribution.  Of course in that case you are using ParallelMesh  
> and will need to handle the fact that the node of interest may not  
> exist on each processor anyway.
>
> The key is that the underlying containers in *Mesh store pointers to  
> nodes and elements, and these pointers do not change even though the  
> underlying containers do.
>
> So if you save a reference to the node or its address before the  
> refinement call you should be good.
>
> -Ben
>
>
>
>
> ----- Original Message -----
> From: Roy Stogner <roy...@ic...>
> To: yunfei zhu <yzh...@go...>
> Cc: lib...@li... <lib...@li... 
> >
> Sent: Wed Feb 11 07:20:43 2009
> Subject: Re: [Libmesh-users] on post processing
>
>
> On Wed, 11 Feb 2009, yunfei zhu wrote:
>
>> I use the following code to access the displacement of a special  
>> node at
>> each time step.
>> First, specified by the node_number:
>> const Node& node = mesh.node(node_number);
>
> This is probably what's going wrong: the node number changes after
> refinement.
>
>> Then get the dof number of a variable on this node:
>> const unsigned int node_dof_u = node.dof_number(0, u_var, 0);
>
> And so does the dof number.
>
>> Then I could access the solution by:
>> (*nonlinear_system.solution)(node_dof_u).
>>
>> But I don't think it's a good way to access the solution,
>
> That's true - it will break on non-vertex nodes on non-Lagrange
> elements.
>
>> because when I read in a mesh by
>>
>> mesh.read("mesh.xda"), then refine the mesh by
>> mesh_refinement.uniformly_refine(1), the solution it writes
>>
>> out is not the one I want. I thought maybe it is because the
>> solution would not be ordered by the dof number of node after
>> refinement.
>
> After refinement, the node with number node_number is still given by
> node = mesh.node(node_number), the first dof index there is still  
> given by
> node_dof_u = node.dof_number, the solution there is still given by
> solution(node_dof_u)... but because the indexing is changed by
> refinement, your old node_number and node_dof_u have nothing to do
> with the new mesh.  You'll need to save some invariant property of the
> node before refinement (it's position shouldn't change, for example)
> and look up it's new node number by searching for that.
> ---
> Roy
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users