You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}

S  M  T  W  T  F  S 

1

2
(5) 
3

4

5

6
(5) 
7

8

9
(8) 
10
(9) 
11
(2) 
12
(3) 
13

14

15

16
(11) 
17
(2) 
18
(1) 
19
(11) 
20

21

22

23
(3) 
24

25
(1) 
26
(4) 
27
(5) 
28

29

30

31





From: Derek Gaston <friedmud@gm...>  20100819 18:05:56

Yes... we're seeing this too... but haven't had time to go further. There are other modifications to the periodic constraints that are on my todo list.... most notably the ability to apply them to individual variables instead of EVERY variable in the system. Yes, I know it sounds weird, but we really do have a system of equations where some variables are periodic and others aren't... Unfortunately.... I _still_ don't have time immediately to look at either of these issues.... Derek On Aug 19, 2010, at 12:02 PM, Roy Stogner wrote: > > On Thu, 19 Aug 2010, Ming Q wrote: > >> Here is the test case that will show the BC constrain is broken after the refinement. > > This replicates here perfectly; thanks. And cutting down the mesh > size to 2x2 (then expanding the refinement criteria to y>5 to > compensate) reduces the problem to something I can look at by hand. > I'm swamped lately but I'll try to check it out this weekend. > > Unless any other interested parties want to try to beat me to it? > E.g. I think Derek's coworkers already ran into this bug, but just > hadn't managed to boil it down to such a simple test case. >  > 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/RIMdev2dev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20100819 18:02:46

On Thu, 19 Aug 2010, Ming Q wrote: > Here is the test case that will show the BC constrain is broken after the refinement. This replicates here perfectly; thanks. And cutting down the mesh size to 2x2 (then expanding the refinement criteria to y>5 to compensate) reduces the problem to something I can look at by hand. I'm swamped lately but I'll try to check it out this weekend. Unless any other interested parties want to try to beat me to it? E.g. I think Derek's coworkers already ran into this bug, but just hadn't managed to boil it down to such a simple test case.  Roy 
From: John Peterson <peterson@cf...>  20100819 15:50:22

On Thu, Aug 19, 2010 at 10:45 AM, John Peterson <peterson@...> wrote: > On Thu, Aug 19, 2010 at 10:40 AM, Vikram Garg > <vikramvgarg@...> wrote: >> 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); > > To be clear, this is a feature of the FEMContext object, itself a part > of the FEMSystem family of classes. An example of FEMSystem use is > ex18, "plain vanilla" libmesh doesn't have these functions. Ah! nevermind, Vikram is right, these functions are in the System class. I just got confused because point_value is also in the FEMContext ;)  John 
From: John Peterson <peterson@cf...>  20100819 15:46:20

On Thu, Aug 19, 2010 at 10:40 AM, Vikram Garg <vikramvgarg@...> wrote: > 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); To be clear, this is a feature of the FEMContext object, itself a part of the FEMSystem family of classes. An example of FEMSystem use is ex18, "plain vanilla" libmesh doesn't have these functions.  John 
From: Vikram Garg <vikramvgarg@ma...>  20100819 15:40:35

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, < libmeshusersrequest@...> wrote: > Send Libmeshusers mailing list submissions to > libmeshusers@... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/libmeshusers > or, via email, send a message with subject or body 'help' to > libmeshusersrequest@... > > You can reach the person managing the list at > libmeshusersowner@... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Libmeshusers 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 <roystgnr@...> > Subject: Re: [Libmeshusers] Periodic BC with adaptive mesh > To: Minq Q <micavn@...> > Cc: libmeshusers@... > MessageID: > <alpine.DEB.2.00.1008181932500.24735@...> > ContentType: TEXT/PLAIN; charset=USASCII; 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 nonuniform 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 <awharmby@...> > Subject: [Libmeshusers] Interpolating at specific point(s) between > nodes. > To: libmeshusers@... > MessageID: > <AANLkTikcp_VnFi5=3MCgTSbP2vmgmeXMWEueXjYRaTU7@...> > ContentType: text/plain; charset=ISO88591 > > 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 <friedmud@...> > Subject: Re: [Libmeshusers] Interpolating at specific point(s) > between nodes. > To: Andrew Wharmby <awharmby@...> > Cc: "libmeshusers@..." > <libmeshusers@...> > MessageID: <2161286881363897123@...> > ContentType: text/plain; charset=ISO88591 > > 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 <awharmby@...> 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/RIMdev2dev > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > >  > > Message: 4 > Date: Wed, 18 Aug 2010 23:11:00 0500 > From: Andrew Wharmby <awharmby@...> > Subject: Re: [Libmeshusers] Interpolating at specific point(s) > between nodes. > To: Derek Gaston <friedmud@...> > Cc: "libmeshusers@..." > <libmeshusers@...> > MessageID: > <AANLkTikAX=1g0QA91j69Ubix6UPYGYK40_iDWuZJys=h@...> > ContentType: text/plain; charset=ISO88591 > > 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 <friedmud@...> 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 <awharmby@...> 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/RIMdev2dev > > > _______________________________________________ > > > Libmeshusers mailing list > > > Libmeshusers@... > > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > > >  > > Message: 5 > Date: Wed, 18 Aug 2010 22:55:18 0600 > From: Derek Gaston <friedmud@...> > Subject: Re: [Libmeshusers] Interpolating at specific point(s) > between nodes. > To: Andrew Wharmby <awharmby@...> > Cc: "libmeshusers@..." > <libmeshusers@...> > MessageID: <914001338438821886@...> > ContentType: text/plain; charset=ISO88591 > > 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 <awharmby@...> 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 <friedmud@...> 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 <awharmby@...> 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/RIMdev2dev > > > _______________________________________________ > > > Libmeshusers mailing list > > > Libmeshusers@... > > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > > >  > > Message: 6 > Date: Thu, 19 Aug 2010 11:29:57 +0200 > From: Ming Q <micavn@...> > Subject: Re: [Libmeshusers] Periodic BC with adaptive mesh > To: Roy Stogner <roystgnr@...> > Cc: libmeshusers@... > MessageID: <FB05193520CE4A7C8A658D3AED98E9F3@...> > ContentType: text/plain; charset="usascii" > > 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 nonuniform 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/RIMdev2dev > >  > > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > End of Libmeshusers Digest, Vol 51, Issue 8 > ******************************************** >  Vikram 
From: Ming Q <micavn@gm...>  20100819 09:30:05

Here is the test case that will show the BC constrain is broken after the refinement. Thanks, / Ming 
From: Derek Gaston <friedmud@gm...>  20100819 04:55:28

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 <awharmby@...> 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 <friedmud@...> 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 <awharmby@...> 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/RIMdev2dev > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Andrew Wharmby <awharmby@gm...>  20100819 04:11:10

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 <friedmud@...> 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 <awharmby@...> 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/RIMdev2dev > > _______________________________________________ > > Libmeshusers mailing list > > Libmeshusers@... > > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Derek Gaston <friedmud@gm...>  20100819 02:32:06

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 <awharmby@...> 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/RIMdev2dev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Andrew Wharmby <awharmby@gm...>  20100819 00:59:37

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_ 
From: Roy Stogner <roystgnr@ic...>  20100819 00:41:30

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 nonuniform 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 