Andrew,
The point_value and point_gradient functions should do the job.
See below for an example of their use. See system.C for the function
implementation. These functions currently do not support vectors of points
but that should be added. Note that the arguments to the
point_value/gradient function are the variable number and Point object.
x = number;
y = number;
Point p(x, y);
Number u_p = point_value(0, p);
Gradient grad_u_p = point_gradient(0, p);
Thanks.
On Thu, Aug 19, 2010 at 4:30 AM, <
[email protected]> wrote:
> Send Libmesh-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Libmesh-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Periodic BC with adaptive mesh (Roy Stogner)
> 2. Interpolating at specific point(s) between nodes. (Andrew Wharmby)
> 3. Re: Interpolating at specific point(s) between nodes.
> (Derek Gaston)
> 4. Re: Interpolating at specific point(s) between nodes.
> (Andrew Wharmby)
> 5. Re: Interpolating at specific point(s) between nodes.
> (Derek Gaston)
> 6. Re: Periodic BC with adaptive mesh (Ming Q)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Aug 2010 19:41:32 -0500 (CDT)
> From: Roy Stogner <[email protected]>
> Subject: Re: [Libmesh-users] Periodic BC with adaptive mesh
> To: Minq Q <[email protected]>
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> On Thu, 19 Aug 2010, Minq Q wrote:
>
> > I am having a problem when using the periodic BC together with the mesh
> > refinement. When one BC is set to refine, the other paired BC is not
> > allocated the new nodes as it should.
>
> That's actually correct - the new node is a hanging node on one side
> of the boundary, and shouldn't exist on the other until the element on
> the other side is refined.
>
> > The strange thing is: The first time of the refinement is OK. But
> > from the second time the two paired BCs are become different.
>
> There are currently two issues with combining the periodic BC and the
> AMR feature:
>
> The "level 1 conformity" constraint is not supported across the
> boundary. I.e. if you set enforce_level_one to true it will only be
> enforced on the mesh interior, not from one side of a periodic
> boundary to another.
>
> The mix of AMR and periodic constraint equations may not be working
> correctly. The two features are supposed to be compatible, but when I
> wrote the latter I was mostly using one or the other, or at best
> running periodic problems where the non-uniform refinement occurred
> away from the periodic BC, so I haven't tested it thoroughly. If you
> can set up a test case (as simple as possible, please) where the
> constraints are coming out wrong, please post the code to the list,
> and we can at least see if it's a simple bug/fix.
> ---
> Roy
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 18 Aug 2010 19:59:12 -0500
> From: Andrew Wharmby <[email protected]>
> Subject: [Libmesh-users] Interpolating at specific point(s) between
> nodes.
> To: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've read some discussion these boards on how to go about doing this, but
> didn't find any real concrete answer. Is there an easy way of after running
> a model, to go back and use the interpolation functions used to approximate
> the nodal values to approximate points between the nodes?
>
> Thanks,
> _Andrew_
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Aug 2010 20:31:53 -0600
> From: Derek Gaston <[email protected]>
> Subject: Re: [Libmesh-users] Interpolating at specific point(s)
> between nodes.
> To: Andrew Wharmby <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Message-ID: <2161286881363897...@unknownmsgid>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Andrew,
>
> There are multiple ways to achieve this... But they are all variations
> on the same theme: you have to remember that your finite element
> "solution" is really nothing more than coefficients. These
> coefficients, when multiplied by their paired shape functions and
> added together are the actual solution.
>
> It just so happens (well not really as they are chosen like that on
> purpose) that lagrange shape functions are interpolary at the nodes...
> ie at the nodes the value of the function you solved for happens to
> correspond to the value of the coefficient associated with the shape
> function there... these are the "nodal values" most people refer to.
> Note that that is just a property of those particular functions (and
> actually are how they are defined / derived).
>
> So how to get values at non nodal points when using lagrange (or any
> other shape functions)? You actually need to evaluate your TRUE
> solution... that is: the coefficients multiplied by the shape
> functions. With normal finite element formulations that use shape
> functions with compact support this amounts to finding the element
> that contains the physical point you want to evaluate the solution
> at... then summing the local coefficients multiplied by their
> respective shape functions evaluated at the physical point.
>
> Specifically, in libmesh this can be accomplished by looping over the
> elements, calling contains_point() on each element then when you have
> found the element containing the point you need to reinitialize an FE
> object using that element and the physical point inverse mapped into
> the reference domain... that will give you your shape functions
> evaluated at the physical point... Now loop over the dofs on that
> element and multiply the coefficients from the solution vector by each
> associated shape function... and sum the results. That will be the
> value of the solution at that point.
>
> Firstly, this is NOT interpolation! This is EVALUATION. This is one
> of the large differences between finite elements and other
> discretization techniques (like finite difference and finite volume).
> In finite elements you are literally solving for a _function_ that
> covers the entire domain. In continuous galerkin (like you are
> probably using with lagrange shape functions) that function is even
> _continuous_ over the entire domain!
>
> Secondly... If this sounds like a lot of work.... It kind of is.
> That's why the MeshFunction object exists... Just initialize it with
> your solution and EquationSystems and it will do all of the above for
> you... Allowing you to evaluate your solution at any point in the
> domain (with some more efficiency than if you tried to do it
> yourself).
>
> Hope that helps!
>
> Derek
>
> Sent from my iPad
>
> On Aug 18, 2010, at 6:59 PM, Andrew Wharmby <[email protected]> wrote:
>
> > I've read some discussion these boards on how to go about doing this, but
> > didn't find any real concrete answer. Is there an easy way of after
> running
> > a model, to go back and use the interpolation functions used to
> approximate
> > the nodal values to approximate points between the nodes?
> >
> > Thanks,
> > _Andrew_
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Libmesh-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Aug 2010 23:11:00 -0500
> From: Andrew Wharmby <[email protected]>
> Subject: Re: [Libmesh-users] Interpolating at specific point(s)
> between nodes.
> To: Derek Gaston <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Derek,
>
> This does indeed clear some of the theory up for me as well as answers my
> question on there being an "easy" way to do it. I've located the
> documentation regarding the object here:
>
> http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1MeshFunction.php#a18dc4d4c722e1961fac15b2a337da62a
> and
> it looks like it does indeed perform all of the tasks you described. Is
> there any chance of there being an example where the MeshFunction object is
> used?
>
> Thanks,
> _Andrew_
>
> On Wed, Aug 18, 2010 at 9:31 PM, Derek Gaston <[email protected]> wrote:
>
> > Andrew,
> >
> > There are multiple ways to achieve this... But they are all variations
> > on the same theme: you have to remember that your finite element
> > "solution" is really nothing more than coefficients. These
> > coefficients, when multiplied by their paired shape functions and
> > added together are the actual solution.
> >
> > It just so happens (well not really as they are chosen like that on
> > purpose) that lagrange shape functions are interpolary at the nodes...
> > ie at the nodes the value of the function you solved for happens to
> > correspond to the value of the coefficient associated with the shape
> > function there... these are the "nodal values" most people refer to.
> > Note that that is just a property of those particular functions (and
> > actually are how they are defined / derived).
> >
> > So how to get values at non nodal points when using lagrange (or any
> > other shape functions)? You actually need to evaluate your TRUE
> > solution... that is: the coefficients multiplied by the shape
> > functions. With normal finite element formulations that use shape
> > functions with compact support this amounts to finding the element
> > that contains the physical point you want to evaluate the solution
> > at... then summing the local coefficients multiplied by their
> > respective shape functions evaluated at the physical point.
> >
> > Specifically, in libmesh this can be accomplished by looping over the
> > elements, calling contains_point() on each element then when you have
> > found the element containing the point you need to reinitialize an FE
> > object using that element and the physical point inverse mapped into
> > the reference domain... that will give you your shape functions
> > evaluated at the physical point... Now loop over the dofs on that
> > element and multiply the coefficients from the solution vector by each
> > associated shape function... and sum the results. That will be the
> > value of the solution at that point.
> >
> > Firstly, this is NOT interpolation! This is EVALUATION. This is one
> > of the large differences between finite elements and other
> > discretization techniques (like finite difference and finite volume).
> > In finite elements you are literally solving for a _function_ that
> > covers the entire domain. In continuous galerkin (like you are
> > probably using with lagrange shape functions) that function is even
> > _continuous_ over the entire domain!
> >
> > Secondly... If this sounds like a lot of work.... It kind of is.
> > That's why the MeshFunction object exists... Just initialize it with
> > your solution and EquationSystems and it will do all of the above for
> > you... Allowing you to evaluate your solution at any point in the
> > domain (with some more efficiency than if you tried to do it
> > yourself).
> >
> > Hope that helps!
> >
> > Derek
> >
> > Sent from my iPad
> >
> > On Aug 18, 2010, at 6:59 PM, Andrew Wharmby <[email protected]> wrote:
> >
> > > I've read some discussion these boards on how to go about doing this,
> but
> > > didn't find any real concrete answer. Is there an easy way of after
> > running
> > > a model, to go back and use the interpolation functions used to
> > approximate
> > > the nodal values to approximate points between the nodes?
> > >
> > > Thanks,
> > > _Andrew_
> > >
> >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by
> > >
> > > Make an app they can't live without
> > > Enter the BlackBerry Developer Challenge
> > > http://p.sf.net/sfu/RIM-dev2dev
> > > _______________________________________________
> > > Libmesh-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Aug 2010 22:55:18 -0600
> From: Derek Gaston <[email protected]>
> Subject: Re: [Libmesh-users] Interpolating at specific point(s)
> between nodes.
> To: Andrew Wharmby <[email protected]>
> Cc: "[email protected]"
> <[email protected]>
> Message-ID: <914001338438821...@unknownmsgid>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I don't believe there is. There probably should be since we get this
> question fairly often (which is one reason for my long winded answer...
> Because now I can just forward it as a future answer ;-)
>
> It really should just work... Give it a whirl and let us know if you run
> into trouble.
>
> Derek
>
> Sent from my iPad
>
> On Aug 18, 2010, at 10:11 PM, Andrew Wharmby <[email protected]> wrote:
>
> Derek,
>
> This does indeed clear some of the theory up for me as well as answers my
> question on there being an "easy" way to do it. I've located the
> documentation regarding the object here:
>
> http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1MeshFunction.php#a18dc4d4c722e1961fac15b2a337da62a
> and
> it looks like it does indeed perform all of the tasks you described. Is
> there any chance of there being an example where the MeshFunction object is
> used?
>
> Thanks,
> _Andrew_
>
> On Wed, Aug 18, 2010 at 9:31 PM, Derek Gaston <[email protected]> wrote:
>
> > Andrew,
> >
> > There are multiple ways to achieve this... But they are all variations
> > on the same theme: you have to remember that your finite element
> > "solution" is really nothing more than coefficients. These
> > coefficients, when multiplied by their paired shape functions and
> > added together are the actual solution.
> >
> > It just so happens (well not really as they are chosen like that on
> > purpose) that lagrange shape functions are interpolary at the nodes...
> > ie at the nodes the value of the function you solved for happens to
> > correspond to the value of the coefficient associated with the shape
> > function there... these are the "nodal values" most people refer to.
> > Note that that is just a property of those particular functions (and
> > actually are how they are defined / derived).
> >
> > So how to get values at non nodal points when using lagrange (or any
> > other shape functions)? You actually need to evaluate your TRUE
> > solution... that is: the coefficients multiplied by the shape
> > functions. With normal finite element formulations that use shape
> > functions with compact support this amounts to finding the element
> > that contains the physical point you want to evaluate the solution
> > at... then summing the local coefficients multiplied by their
> > respective shape functions evaluated at the physical point.
> >
> > Specifically, in libmesh this can be accomplished by looping over the
> > elements, calling contains_point() on each element then when you have
> > found the element containing the point you need to reinitialize an FE
> > object using that element and the physical point inverse mapped into
> > the reference domain... that will give you your shape functions
> > evaluated at the physical point... Now loop over the dofs on that
> > element and multiply the coefficients from the solution vector by each
> > associated shape function... and sum the results. That will be the
> > value of the solution at that point.
> >
> > Firstly, this is NOT interpolation! This is EVALUATION. This is one
> > of the large differences between finite elements and other
> > discretization techniques (like finite difference and finite volume).
> > In finite elements you are literally solving for a _function_ that
> > covers the entire domain. In continuous galerkin (like you are
> > probably using with lagrange shape functions) that function is even
> > _continuous_ over the entire domain!
> >
> > Secondly... If this sounds like a lot of work.... It kind of is.
> > That's why the MeshFunction object exists... Just initialize it with
> > your solution and EquationSystems and it will do all of the above for
> > you... Allowing you to evaluate your solution at any point in the
> > domain (with some more efficiency than if you tried to do it
> > yourself).
> >
> > Hope that helps!
> >
> > Derek
> >
> > Sent from my iPad
> >
> > On Aug 18, 2010, at 6:59 PM, Andrew Wharmby <[email protected]> wrote:
> >
> > > I've read some discussion these boards on how to go about doing this,
> but
> > > didn't find any real concrete answer. Is there an easy way of after
> > running
> > > a model, to go back and use the interpolation functions used to
> > approximate
> > > the nodal values to approximate points between the nodes?
> > >
> > > Thanks,
> > > _Andrew_
> > >
> >
> ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by
> > >
> > > Make an app they can't live without
> > > Enter the BlackBerry Developer Challenge
> > > http://p.sf.net/sfu/RIM-dev2dev
> > > _______________________________________________
> > > Libmesh-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 19 Aug 2010 11:29:57 +0200
> From: Ming Q <[email protected]>
> Subject: Re: [Libmesh-users] Periodic BC with adaptive mesh
> To: Roy Stogner <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
>
> Here is the test case that will show the BC constrain is broken after the
> refinement.
>
> Thanks,
> / Ming
> -------------- next part --------------
>
>
> On Aug 19, 2010, at 2:41 AM, Roy Stogner wrote:
>
> >
> > On Thu, 19 Aug 2010, Minq Q wrote:
> >
> >> I am having a problem when using the periodic BC together with the mesh
> >> refinement. When one BC is set to refine, the other paired BC is not
> >> allocated the new nodes as it should.
> >
> > That's actually correct - the new node is a hanging node on one side
> > of the boundary, and shouldn't exist on the other until the element on
> > the other side is refined.
> >
> >> The strange thing is: The first time of the refinement is OK. But
> >> from the second time the two paired BCs are become different.
> >
> > There are currently two issues with combining the periodic BC and the
> > AMR feature:
> >
> > The "level 1 conformity" constraint is not supported across the
> > boundary. I.e. if you set enforce_level_one to true it will only be
> > enforced on the mesh interior, not from one side of a periodic
> > boundary to another.
> >
> > The mix of AMR and periodic constraint equations may not be working
> > correctly. The two features are supposed to be compatible, but when I
> > wrote the latter I was mostly using one or the other, or at best
> > running periodic problems where the non-uniform refinement occurred
> > away from the periodic BC, so I haven't tested it thoroughly. If you
> > can set up a test case (as simple as possible, please) where the
> > constraints are coming out wrong, please post the code to the list,
> > and we can at least see if it's a simple bug/fix.
> > ---
> > Roy
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Libmesh-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>
> End of Libmesh-users Digest, Vol 51, Issue 8
> ********************************************
>
--
Vikram
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
