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}
(56) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(2) 
2
(1) 
3

4

5
(1) 
6

7
(9) 
8
(1) 
9
(2) 
10
(1) 
11
(2) 
12
(8) 
13
(18) 
14
(8) 
15
(3) 
16

17

18
(2) 
19
(5) 
20
(7) 
21
(13) 
22
(3) 
23
(9) 
24

25
(2) 
26
(13) 
27
(6) 
28
(24) 
29
(6) 
30
(5) 
31

From: Roy Stogner <roystgnr@ic...>  20091014 22:15:37

On Wed, 14 Oct 2009, Derek Gaston wrote: > I thought I ran into similar problems when I did mesh redistribution / > smoothing + adaptivity. I was able to go in and "fix" the hanging > nodes somehow... But I don't remember where I did it ( I thought it > was down inside the library and I committed it back). Heh, and I thought your solution to that was to just do the adaptivity first and the redistribution second. ;) > I'm not near a computer right now where I can go look at what I did > (I'm traveling this week)... But I bet if you look back a few years > (2007?) you might see a checkin from me referencing it. Aha! MeshTools::find_hanging_nodes_and_parents() looks like it's exactly the trick we'd need. Call that function, get the hanging_nodes map. Do hanging_node_moved = false Loop over hanging_nodes If a node isn't already in between its parents move it hanging_node_moved = true While(hanging_node_moved == true) The loop probably isn't the most efficient way to handle recursive constraints (maybe a depthfirst descent into hanging_nodes at each entry?) but it would work.  Roy 
From: Derek Gaston <friedmud@gm...>  20091014 21:56:08

I thought I ran into similar problems when I did mesh redistribution / smoothing + adaptivity. I was able to go in and "fix" the hanging nodes somehow... But I don't remember where I did it ( I thought it was down inside the library and I committed it back). I'm not near a computer right now where I can go look at what I did (I'm traveling this week)... But I bet if you look back a few years (2007?) you might see a checkin from me referencing it. If I get a chance tonight I'll do some digging... Derek Sent from my iPhone On Oct 14, 2009, at 11:48 AM, Roy Stogner <roystgnr@...> wrote: > > On Wed, 14 Oct 2009, Joa Ljungvall wrote: > >> So returning to the "fix" using the constraint equations... I don't >> quite >> understand the idea behind this. If my hanging node no longer is at >> the right >> position, my mesh is broken, no? > > Not quite. If your hanging node is no longer at the right position, > then the mesh is geometrically broken, but that can be fixed by simply > moving the node to a consistent position immediately, before the mesh > is topologically changed. The refinement cycle is what turns a > geometrically broken mesh into a topologically broken mesh, and that's > what can't be fixed. > >> So fixing this with the constraint equations is a way of making the >> calculations go on, assuming that the error we introduced this way >> is small, and not a complete solution to the problem? > > I believe this is a complete solution to the problem for adaptive > refinement  it would "unbreak" the mesh before the breaks could have > any real effect. > > For adaptive coarsening, however, it now occurs to me that we wouldn't > be able to use the DofConstraints to restore hanging node locations, > because the constraint coefficients are built based on > geometrydependent evaluations and would give the wrong results for > newlyhanging nodes. > > I'm not sure what the best solution is in the coarsening case. I > suggested using the DofConstraints because that code already works out > the hairy problems (as in the example I mentioned) of recursively > expanding constraints with nested dependencies... > >> This is way I came up with the idea of moving the nodes in groups... > > This wouldn't work for adaptive coarsening either, I'm afraid. >  > Roy > >  >  >  >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20091014 15:48:05

On Wed, 14 Oct 2009, Joa Ljungvall wrote: > So returning to the "fix" using the constraint equations... I don't quite > understand the idea behind this. If my hanging node no longer is at the right > position, my mesh is broken, no? Not quite. If your hanging node is no longer at the right position, then the mesh is geometrically broken, but that can be fixed by simply moving the node to a consistent position immediately, before the mesh is topologically changed. The refinement cycle is what turns a geometrically broken mesh into a topologically broken mesh, and that's what can't be fixed. > So fixing this with the constraint equations is a way of making the > calculations go on, assuming that the error we introduced this way > is small, and not a complete solution to the problem? I believe this is a complete solution to the problem for adaptive refinement  it would "unbreak" the mesh before the breaks could have any real effect. For adaptive coarsening, however, it now occurs to me that we wouldn't be able to use the DofConstraints to restore hanging node locations, because the constraint coefficients are built based on geometrydependent evaluations and would give the wrong results for newlyhanging nodes. I'm not sure what the best solution is in the coarsening case. I suggested using the DofConstraints because that code already works out the hairy problems (as in the example I mentioned) of recursively expanding constraints with nested dependencies... > This is way I came up with the idea of moving the nodes in groups... This wouldn't work for adaptive coarsening either, I'm afraid.  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091014 15:12:31

So returning to the "fix" using the constraint equations... I don't quite understand the idea behind this. If my hanging node no longer is at the right position, my mesh is broken, no? So fixing this with the constraint equations is a way of making the calculations go on, assuming that the error we introduced this way is small, and not a complete solution to the problem? This is way I came up with the idea of moving the nodes in groups... Joa Joa On Wed, Oct 14, 2009 at 08:38:59AM 0500, Roy Stogner wrote: > > On Wed, 14 Oct 2009, Joa Ljungvall wrote: > > >When I loop over the nodes, find a face that is on the boundary, and > >then move the nodes the problem is, if I understood it correct, that > >I might move a hanging node out of the line between the nodes of the > >not so refined neighbour. > > This is not the only possible failure case: You also might move a > vertex node without moving a hanging node (even a nonboundary hanging > node) that depends on it. That's the only failure mode in 2D, in > fact. > > >But I can check if this is the case, and instead of moving only the > >hanging node I move all three nodes keeping them on a line to > >minimize the error visavis the geometry. > > Or move all 6 nodes, in case you moved node A which depends on node B > and C, node C depends on D and E, and node F depends on nodes B and G? > In 3D this is not an extremely unlikely possibility, even with tets. > > That's why I suggested just fixing things with the constraint > equations. It sounds great to optimize the geometry error, but one > step at a time. > > >If this is a region where the solution changes fast this not so > >refined element will be refined allowing an improved description of > >the geometry. > > Also, in 3D "this not so refined element" may be "these not so refined > elements", since any number of tets can share a boundary node or a > boundary edge. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20091014 13:59:37

On Wed, 14 Oct 2009, Joa Ljungvall wrote: > When I loop over the nodes, find a face that is on the boundary, and > then move the nodes the problem is, if I understood it correct, that > I might move a hanging node out of the line between the nodes of the > not so refined neighbour. This is not the only possible failure case: You also might move a vertex node without moving a hanging node (even a nonboundary hanging node) that depends on it. That's the only failure mode in 2D, in fact. > But I can check if this is the case, and instead of moving only the > hanging node I move all three nodes keeping them on a line to > minimize the error visavis the geometry. Or move all 6 nodes, in case you moved node A which depends on node B and C, node C depends on D and E, and node F depends on nodes B and G? In 3D this is not an extremely unlikely possibility, even with tets. That's why I suggested just fixing things with the constraint equations. It sounds great to optimize the geometry error, but one step at a time. > If this is a region where the solution changes fast this not so > refined element will be refined allowing an improved description of > the geometry. Also, in 3D "this not so refined element" may be "these not so refined elements", since any number of tets can share a boundary node or a boundary edge.  Roy 
From: Joa Ljungvall <libmesh@jo...>  20091014 13:01:53

Hi again, When I loop over the nodes, find a face that is on the boundary, and then move the nodes the problem is, if I understood it correct, that I might move a hanging node out of the line between the nodes of the not so refined neighbour. But I can check if this is the case, and instead of moving only the hanging node I move all three nodes keeping them on a line to minimize the error visavis the geometry. If this is a region where the solution changes fast this not so refined element will be refined allowing an improved description of the geometry. Or have I missed something important? Such as that it will not work in 3D... Joa On Tue, Oct 13, 2009 at 05:23:07PM 0500, Roy Stogner wrote: > > > On Tue, 13 Oct 2009, Roy Stogner wrote: > > >Anyway, the solution is probably to, after you've looped over all > >nodes, loop over all constraint equations in the dof map and apply > >them to nodes' xyz coordinates. > > Thinking about it again, this is an oversimplification. For it to > work, you'd need to have a variable (either in your system, or better > in an ExplicitSystem created for the purpose) which is of type > LAGRANGE and which is of the same FE order as your geometric Elem > order. You'd also need to have some lookup between that variable's > dof indices and your node ids; they won't be the same thing. This is > still the right solution, it's just easier said than done. >  > Roy 
From: David Knezevic <dknez@MIT.EDU>  20091014 11:41:17

That'll work out of the box, but you can't coarsen the "base" mesh that you load in to libmesh  you can only refine the base mesh and then subsequently coarsen the elements that have been refined by libmesh. But if you can represent the geometry with a coarser mesh than is required to resolve the PDE solution satisfactorily, then this approach should still buy you something...  Dave Joa Ljungvall wrote: > I've been running in devel mode. Things start to look complicated... What > about this as an approach, escentially what was proposed to me in the > beginning. > > 1) Use gmsh to generate a mesh that is fine enough to describe the geometry > to the precision it is known > 2) Solve the equations > 3) Refine and COARSE the mesh using libmesh, nothing fancy > 4) > 2 until I've gotten rid of enough cells... > > > This should work "out of the box", no? > > > > cheers > > > Joa > > On Tue, Oct 13, 2009 at 05:23:07PM 0500, Roy Stogner wrote: > >> On Tue, 13 Oct 2009, Roy Stogner wrote: >> >> >>> Anyway, the solution is probably to, after you've looped over all >>> nodes, loop over all constraint equations in the dof map and apply >>> them to nodes' xyz coordinates. >>> >> Thinking about it again, this is an oversimplification. For it to >> work, you'd need to have a variable (either in your system, or better >> in an ExplicitSystem created for the purpose) which is of type >> LAGRANGE and which is of the same FE order as your geometric Elem >> order. You'd also need to have some lookup between that variable's >> dof indices and your node ids; they won't be the same thing. This is >> still the right solution, it's just easier said than done. >>  >> Roy >> > >  > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9  12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Joa Ljungvall <libmesh@jo...>  20091014 08:19:43

I've been running in devel mode. Things start to look complicated... What about this as an approach, escentially what was proposed to me in the beginning. 1) Use gmsh to generate a mesh that is fine enough to describe the geometry to the precision it is known 2) Solve the equations 3) Refine and COARSE the mesh using libmesh, nothing fancy 4) > 2 until I've gotten rid of enough cells... This should work "out of the box", no? cheers Joa On Tue, Oct 13, 2009 at 05:23:07PM 0500, Roy Stogner wrote: > > > On Tue, 13 Oct 2009, Roy Stogner wrote: > > >Anyway, the solution is probably to, after you've looped over all > >nodes, loop over all constraint equations in the dof map and apply > >them to nodes' xyz coordinates. > > Thinking about it again, this is an oversimplification. For it to > work, you'd need to have a variable (either in your system, or better > in an ExplicitSystem created for the purpose) which is of type > LAGRANGE and which is of the same FE order as your geometric Elem > order. You'd also need to have some lookup between that variable's > dof indices and your node ids; they won't be the same thing. This is > still the right solution, it's just easier said than done. >  > Roy 