Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Libmesh-users] mapping back to reference coordinates

 Re: [Libmesh-users] mapping back to reference coordinates From: Roy Stogner - 2011-04-15 20:07:02 ```On Fri, 15 Apr 2011, Boyce Griffith wrote: > Is there a function that gives the reference coordinates for each node > of a (Lagrange) element? The first thing that comes to mind: initialize a first-order monomial FE on the element with trapezoidal quadrature, then at point p evaluate xi/eta/zeta from get_phi()[1/2/3][p]. There's probably a better way to do it, though. > The reason I ask is that I have a variable, say x(X), restricted to a > particular side of a particular element for which I would like to > identify any positions at which x(X0) = x0. If any such positions > exist, I then need to evaluate some other field variables at those > locations, which I can easily accomplish if I know the reference > coordinates corresponding to position X0, but not if I only know the > value(s) of X0. Just use inverse_map()? That way you can also handle off-node positions. --- Roy ```

 [Libmesh-users] mapping back to reference coordinates From: Boyce Griffith - 2011-04-15 20:00:24 ```Hi, Folks -- Is there a function that gives the reference coordinates for each node of a (Lagrange) element? The reason I ask is that I have a variable, say x(X), restricted to a particular side of a particular element for which I would like to identify any positions at which x(X0) = x0. If any such positions exist, I then need to evaluate some other field variables at those locations, which I can easily accomplish if I know the reference coordinates corresponding to position X0, but not if I only know the value(s) of X0. Doing this in general seems like it could be a real mess, but for lower order Lagrange elements it does not seem too bad. However, I think that I need to know the reference coordinates of the nodes, and I have been unable to find an API that seems to give access to these values. (It is my impression that functions such as Elem::point() give the current coordinates of the node, not the reference coordinates.) Also, I realize this probably seems like kind of a bizarre thing to be computing, but does there happen to be any existing code in libMesh that could be adapted to do this kind of thing? :-) Thanks! -- Boyce ```
 Re: [Libmesh-users] mapping back to reference coordinates From: John Peterson - 2011-04-15 20:04:10 ```On Fri, Apr 15, 2011 at 2:02 PM, Boyce Griffith wrote: > Hi, Folks -- > > Is there a function that gives the reference coordinates for each node > of a (Lagrange) element? > > The reason I ask is that I have a variable, say x(X), restricted to a > particular side of a particular element for which I would like to > identify any positions at which x(X0) = x0.  If any such positions > exist, I then need to evaluate some other field variables at those > locations, which I can easily accomplish if I know the reference > coordinates corresponding to position X0, but not if I only know the > value(s) of X0. > > Doing this in general seems like it could be a real mess, but for lower > order Lagrange elements it does not seem too bad.  However, I think that > I need to know the reference coordinates of the nodes, and I have been > unable to find an API that seems to give access to these values.  (It is > my impression that functions such as Elem::point() give the current > coordinates of the node, not the reference coordinates.) > > Also, I realize this probably seems like kind of a bizarre thing to be > computing, but does there happen to be any existing code in libMesh that > could be adapted to do this kind of thing?  :-) > > Thanks! FE::inverse_map() -- John ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Roy Stogner - 2011-04-15 20:07:02 ```On Fri, 15 Apr 2011, Boyce Griffith wrote: > Is there a function that gives the reference coordinates for each node > of a (Lagrange) element? The first thing that comes to mind: initialize a first-order monomial FE on the element with trapezoidal quadrature, then at point p evaluate xi/eta/zeta from get_phi()[1/2/3][p]. There's probably a better way to do it, though. > The reason I ask is that I have a variable, say x(X), restricted to a > particular side of a particular element for which I would like to > identify any positions at which x(X0) = x0. If any such positions > exist, I then need to evaluate some other field variables at those > locations, which I can easily accomplish if I know the reference > coordinates corresponding to position X0, but not if I only know the > value(s) of X0. Just use inverse_map()? That way you can also handle off-node positions. --- Roy ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Kirk, Benjamin (JSC-EG311) - 2011-04-15 20:15:40 ```On 4/15/11 3:02 PM, "Boyce Griffith" wrote: > Also, I realize this probably seems like kind of a bizarre thing to be > computing, but does there happen to be any existing code in libMesh that > could be adapted to do this kind of thing? :-) The implementation for the System::point_value() might be instructive: http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1System.php#af077a1b91c8b03020f2c6da41fcb72fb ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Boyce Griffith - 2011-04-15 20:28:11 ``` On 4/15/11 4:06 PM, Roy Stogner wrote: > > On Fri, 15 Apr 2011, Boyce Griffith wrote: > >> The reason I ask is that I have a variable, say x(X), restricted to a >> particular side of a particular element for which I would like to >> identify any positions at which x(X0) = x0. If any such positions >> exist, I then need to evaluate some other field variables at those >> locations, which I can easily accomplish if I know the reference >> coordinates corresponding to position X0, but not if I only know the >> value(s) of X0. > > Just use inverse_map()? That way you can also handle off-node > positions. Thanks, I had managed to totally overlook inverse_map()... It seems like it would at least provide an easy way to get the element coordinates. In fact, it seems like inverse_map() comes close to doing everything that I want to do. I'm trying to do is to find any intersection(s) between a line and a side (in 3D) or edge (in 2D). Conveniently, the lines in question are always in the coordinate directions, so I think that maybe I can simply project the sides in the direction of the line and then call inverse_map(). The only complication is that the coordinate system being used for the mesh is a Lagrangian (material) coordinate system, and the line is in the current (physical) coordinate system, but I suppose that I can call Elem::build_side() and then reset the nodal positions of the generated side element to correspond to the current positions. Thanks, -- Boyce ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Roy Stogner - 2011-04-15 20:38:06 ```On Fri, 15 Apr 2011, Boyce Griffith wrote: > The only complication is that the coordinate system being used for the mesh > is a Lagrangian (material) coordinate system, and the line is in the current > (physical) coordinate system, but I suppose that I can call > Elem::build_side() and then reset the nodal positions of the generated side > element to correspond to the current positions. Hmm... one catch with that is that you'll ideally want to make sure you're moving around *copied* nodes; otherwise you'll have the same multithreading race conditions that the library ALE code has. --- Roy ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Boyce Griffith - 2011-04-15 20:42:57 ``` On 4/15/11 4:37 PM, Roy Stogner wrote: > > On Fri, 15 Apr 2011, Boyce Griffith wrote: > >> The only complication is that the coordinate system being used for the >> mesh is a Lagrangian (material) coordinate system, and the line is in >> the current (physical) coordinate system, but I suppose that I can >> call Elem::build_side() and then reset the nodal positions of the >> generated side element to correspond to the current positions. > > Hmm... one catch with that is that you'll ideally want to make sure > you're moving around *copied* nodes; otherwise you'll have the same > multithreading race conditions that the library ALE code has. OK; and I guess these will need to be manually allocated and deleted? Thanks! -- Boyce ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Roy Stogner - 2011-04-15 20:49:40 ```On Fri, 15 Apr 2011, Boyce Griffith wrote: > On 4/15/11 4:37 PM, Roy Stogner wrote: >> >> On Fri, 15 Apr 2011, Boyce Griffith wrote: >> >>> The only complication is that the coordinate system being used for the >>> mesh is a Lagrangian (material) coordinate system, and the line is in >>> the current (physical) coordinate system, but I suppose that I can >>> call Elem::build_side() and then reset the nodal positions of the >>> generated side element to correspond to the current positions. >> >> Hmm... one catch with that is that you'll ideally want to make sure >> you're moving around *copied* nodes; otherwise you'll have the same >> multithreading race conditions that the library ALE code has. > > OK; and I guess these will need to be manually allocated and deleted? Make them local stack variables so you can avoid new and delete, but you're essentially right, I don't think we've got any facility in libMesh right now for doing a "deep copy" of an Elem. --- Roy ```
 Re: [Libmesh-users] mapping back to reference coordinates From: Boyce Griffith - 2011-04-15 22:23:25 ``` On 4/15/11 4:49 PM, Roy Stogner wrote: > > On Fri, 15 Apr 2011, Boyce Griffith wrote: > >> On 4/15/11 4:37 PM, Roy Stogner wrote: >>> >>> On Fri, 15 Apr 2011, Boyce Griffith wrote: >>> >>>> The only complication is that the coordinate system being used for the >>>> mesh is a Lagrangian (material) coordinate system, and the line is in >>>> the current (physical) coordinate system, but I suppose that I can >>>> call Elem::build_side() and then reset the nodal positions of the >>>> generated side element to correspond to the current positions. >>> >>> Hmm... one catch with that is that you'll ideally want to make sure >>> you're moving around *copied* nodes; otherwise you'll have the same >>> multithreading race conditions that the library ALE code has. >> >> OK; and I guess these will need to be manually allocated and deleted? > > Make them local stack variables so you can avoid new and delete, but > you're essentially right, I don't think we've got any facility in > libMesh right now for doing a "deep copy" of an Elem. I tried something like: AutoPtr side_elem = elem->build_side(side); for (int k = 0; k < n_node; ++k) { side_elem->set_node(k) = ...; } // do stuff for (int k = 0; k < n_node; ++k) { side_elem->set_node(k) = NULL; } where the last part was to make sure that I didn't accidentally try to use the "cloned" nodes. However, it seems like this also sets the node pointers to NULL in elem. Does side_elem->set_node(k) also have the effect of calling elem->set_node(k) ? Thanks, -- Boyce ```