You can subscribe to this list here.
2003 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}
(4) 

2004 
_{Jan}
(1) 
_{Feb}
(21) 
_{Mar}
(31) 
_{Apr}
(10) 
_{May}
(12) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(6) 
_{Sep}
(5) 
_{Oct}
(11) 
_{Nov}
(43) 
_{Dec}
(13) 
2012 
_{Jan}
(56) 
_{Feb}
(120) 
_{Mar}
(72) 
_{Apr}
(57) 
_{May}
(82) 
_{Jun}
(66) 
_{Jul}
(51) 
_{Aug}
(75) 
_{Sep}
(166) 
_{Oct}
(232) 
_{Nov}
(284) 
_{Dec}
(105) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

2005 
_{Jan}
(25) 
_{Feb}
(12) 
_{Mar}
(49) 
_{Apr}
(19) 
_{May}
(104) 
_{Jun}
(60) 
_{Jul}
(10) 
_{Aug}
(42) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(6) 
_{Dec}
(4) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(15) 
_{Dec}

2011 
_{Jan}
(26) 
_{Feb}
(48) 
_{Mar}
(151) 
_{Apr}
(108) 
_{May}
(61) 
_{Jun}
(108) 
_{Jul}
(27) 
_{Aug}
(50) 
_{Sep}
(43) 
_{Oct}
(43) 
_{Nov}
(27) 
_{Dec}
(37) 
2009 
_{Jan}
(89) 
_{Feb}
(93) 
_{Mar}
(119) 
_{Apr}
(73) 
_{May}
(39) 
_{Jun}
(51) 
_{Jul}
(27) 
_{Aug}
(8) 
_{Sep}
(91) 
_{Oct}
(90) 
_{Nov}
(77) 
_{Dec}
(67) 
2013 
_{Jan}
(168) 
_{Feb}
(151) 
_{Mar}
(30) 
_{Apr}
(145) 
_{May}
(26) 
_{Jun}
(53) 
_{Jul}
(76) 
_{Aug}
(33) 
_{Sep}
(23) 
_{Oct}
(72) 
_{Nov}
(125) 
_{Dec}
(38) 
2010 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(98) 
_{Apr}
(45) 
_{May}
(25) 
_{Jun}
(60) 
_{Jul}
(17) 
_{Aug}
(36) 
_{Sep}
(48) 
_{Oct}
(45) 
_{Nov}
(65) 
_{Dec}
(39) 
2007 
_{Jan}
(5) 
_{Feb}
(46) 
_{Mar}
(9) 
_{Apr}
(23) 
_{May}
(17) 
_{Jun}
(51) 
_{Jul}
(41) 
_{Aug}
(4) 
_{Sep}
(28) 
_{Oct}
(71) 
_{Nov}
(193) 
_{Dec}
(20) 
2008 
_{Jan}
(46) 
_{Feb}
(46) 
_{Mar}
(18) 
_{Apr}
(38) 
_{May}
(14) 
_{Jun}
(107) 
_{Jul}
(50) 
_{Aug}
(115) 
_{Sep}
(84) 
_{Oct}
(96) 
_{Nov}
(105) 
_{Dec}
(34) 
S  M  T  W  T  F  S 



1

2

3
(3) 
4
(6) 
5

6

7
(4) 
8
(12) 
9
(5) 
10

11
(1) 
12

13

14
(5) 
15

16
(2) 
17
(1) 
18

19

20

21

22
(1) 
23
(1) 
24

25
(1) 
26

27

28

29

30
(2) 
31



From: Roy Stogner <roystgnr@ic...>  20060807 20:18:39

On Mon, 7 Aug 2006, Tim Kr=F6ger wrote: > On Fri, 4 Aug 2006, Roy Stogner wrote: > >> The inverse map iteration definitely won't converge for some elements >> if the physical point is outside the element, but that shouldn't cause >> a problem for Elem::constains_point() anymore; if its call to >> inverse_map() doesn't converge, the result is a distant point that >> will make sure on_reference_element() is false. > > No: If the nonlinear solver doesn't converge, it will call error() and = thus=20 > crash. At least, this call to error() should be removed  perhaps by=20 > giving the solver class an optional argument. That's exactly why the inverse_map function has the "bool secure" argument. If secure is false (as it is when contains_point() calls inverse_map() ), then Newton isn't expected to converge and inverse_map just exits after 10 iterations. Of course, inverse_map() is *supposed* to exit by returning an outofbounds point, not just whatever its last iterate was. Derek, didn't we fix this? Or did you send me a patch I forgot to commit to CVS? > The other problem that I see when leaving the linear search in is that = when=20 > I will later implement the possibiliy to evaluate the MeshFunction outs= ide=20 > the domain covered by the grid, the linear search will slow this down=20 > considerabely. That is undesirable. > What about adding some heuristic safety margin around the bounding box = in=20 > the case of quadratic mappings? Well, not really satisfying ... As long as the margin is a proveable upper bound, I'll be happy with it. Trying to figure out what would be an upper bound on a quadratic Hex makes my head spin, though. > Perhaps better: Enable the linear search only if quadratic mappings are= =20 > involved. That sounds good too, but deciding whether or not quadratic mappings are involved is easier said than done. I'd go so far as to say that secondorder geometric elements with linear mappings is one of the most common usage patterns in libMesh, since we need the extra nodes in the secondorder elements to store degree of freedom numbers for any p>1 finite element. > Any suggestions? No good ones. All I can think to do is warn about the problem. When you add an interface for outofmesh MeshFunction extensions, let that interface turn off (well, replace) the linear search, and add an assert() or #ifdef DEBUG block in that code path which verifies that it doesn't see any quadratic mappings.  Roy 
From: Roy Stogner <roystgnr@ic...>  20060807 20:05:20

On Mon, 7 Aug 2006, Karl Tomlinson wrote: > On Fri, 4 Aug 2006 16:09:16 0500 (CDT), Roy Stogner wrote: > >> On Sat, 5 Aug 2006, Karl Tomlinson wrote: >> >>> I'm used to thinking of x,y,z as variables in themselves, like >>> dependent (system) variables in libMesh, each with their own >>> FEType. But I think it is reasonable that x,y,z should all have >>> the same FEType (but not necessarily the same as that of each of >>> the dependent variables). >> >> This makes sense when the domain is transformed from a cartesian grid, >> but what do you do on more general unstructured meshes? > > I now see that libMesh is storing xyzbased derivatives for the > dofs in Hermite meshes, whereas I'm used to thinking of xibased > derivatives. That's right. Basically I wanted to make it easier to handle selectively refined (whether by libMesh's hierarchical AMR or by a priori mesh grading) meshes. Once you do that, d/dxi is no longer consistent between neighboring elements, but d/dx still is. > When thinking in terms of xyzderivatives, there needs to be some > way of calculating the scale factors (dx/dxi) for the geometry. > This can be done with edgelengths or something similar but it may be > iterative and may not be simple. > > When the dofs are xiderivatives this step is not an issue. Well, if your mesh is topologically equivalent to a subset of a cartesian grid, there's no problem: your "master elements" can all be the same, and then making a distinction between d/dx and d/dxi (for mapping functions) doesn't make sense. Once you do a little hierarchic refinement, then there's a scaling factor that comes into play, but it's still simple. What I still can't wrap my head around is what you do for really unstructured meshes: >> Imagine you've got three Hermite quads meeting at one point, for >> example  what are the mapping variables at that node? If xi and eta >> are different between elements, derivatives with respect to xi and eta >> won't be uniquely defined on element interfaces. > > This situation does make things more complicated for the > xiderivative implementation. Some linear constraints would be needed > to require C1 continuity. (The scale factor matrix provides this > in the xyzderivative implementation.) I'm not convinced it's possible to get C1 continuous mapping functions with Hermite elements in this situation, regardless of how you code them. The Hermite elements get away with fewer degrees of freedom than you would expect a C1 quad or hex to need, because they take advantage of the fact that you're using meshes where the mixed derivatives (e.g. d^2/dxideta in 2D) are in the same "direction" on all neighboring elements. I don't see how that can happen unless you have four quads (or 8 hexes) meeting at every node. > A similar issue exists where an element is adjacent on one side to > 2 elements of higher hrefinement level (with a hanging node). This is much easier to handle by comparison; sure there's some scaling involved, but as long as the mapping is consistent (all the mapping values on the hanging node correspond to the correct linear combinations of the values on the neighboring vertices), the result should still be C1 and should still be straightforward to compute. >> Also, it's easy to conceive of situations where the mapping variables >> take up a different amount of data than any solution variable. It >> might be nice to handle NURBS geometries via a two step map: a first >> order Lagrange mapping from master elements to a few unit boxes, then >> a few NURBS points to define a map from those into physical space. >> Perelement NURBS information could work but would waste RAM. > > I'm not familiar enough with NURBS to comment here. Imagine a quadratic mapping, then. Say you want to discretize the domain from 1<x<1 and x^21<y<x^2+1. You can describe a mapping into that domain by using triangles which each have 6 nodes and a quadratic map, but you could also do it by mapping a bunch of 3 node master triangles onto a unit square, then using a single 9 node quadratic map to transform the unit square onto the physical domain. In the former case you end up using approximately 1 mapping node per 2 triangles, in the latter you use approximately 3. This isn't a huge memory savings until you get up to high p mappings or complicated NURBS, I know, but I don't want to preclude it unless we have to. > I was thinking that geometric variables should be as similar as > possible to solution (or any other  e.g. material parameter) > variables, but are you saying that geometric variables may be more > complicated than solution variables? It's not so much that they're more or less complicated, it's that they're "differently" complicated. I think that for geometric variables you may often find that the most memoryefficient way to store the mapping is as a composition of many simple (perhaps linear Lagrange) mappings from master elements into "geometric patches" and a few complicated (perhaps NURBS) mappings from those patches into the physical domain. There's no analog to such a process among solution variables. >>> Should the shape functions for the map be tied more closely to an >>> FE for the Mesh (or an Elem) rather than to the FEs for each of >>> the dependent variables in each System on the Mesh? >> >> I'd rather not have a mapping FE associated with each Elem unless we >> can think of a cunning data structure; I felt bad about just adding a >> byte for p_level until I realized most compilers would have turned >> that byte into alignment padding anyway. Adding a perElem pointer to >> a mapping FEType object would be a bit much. I'm willing to reconsider this. Looking over elem.h, it's clear that we're going to have something like a dozen pointers per Elem on even 2D meshes; adding another one won't kill us. I'm still not sure what good it would be, though. Generally when we have finite elements that are compatible with each other, we put them in the same FEFamily, even though one is a quad and the other a triangle. I can't imagine situations where I'd want to mix and match mapping FEFamilies; it wouldn't be safe. > (As I understand it, prefinement essentially changes the FEType > through the order and so it is just having different FEFamilys > that is the issue. Correct me if I'm wrong.) You're correct. Also we currently only support adaptive p refinement of hierarchictype basis functions, which makes mixing different p levels in the same mesh a little easier. >> I guess more flexibility is better than less, but to simplify code >> elsewhere (the FE caching I just added to CVS, for instance) it would >> be nice if we could assume there was just one perMesh mapping FEType. > > For the most part I'm happy with one perMesh mapping FEFamily. > The possible exception is CloughTocher and Hermite FEFamilies. > > I'm not familiar with CloughTocher but they look pretty clever. > Hermites don't provide TRI or TET ElemTypes so having some > CloughToucher to provide this may be useful. Is this a feasible > combination (with hanging node constraints perhaps)? I had hoped it would be when I started coding them, but no, that doesn't work. To make the interface C1, you'd need to constrain the flux on the Hermite side to be quadratic instead of cubic  but there's no way to do that without the constraint "spilling over" into neighboring elements, and that can ruin the locality or even the approximation accuracy of your basis functions. There is a quad macroelement which is compatible with the CloughTochers and which is likely a little more efficient in a hybrid mesh than dissecting the quads and using CT alone, but I don't think the slight gain is worth the coding time. Also, keep in mind that there's no Clough Tet elements in libMesh, either. C1 tets are ugly; you need something like p=11 to build them without macroelements, and the best macroelements suitable for any Tet mesh require p=5 polynomials and can't be restricted below p=3. My main motivation for writing the Hermite class in the first place was that I wanted to get some C1 3D results without spending a year or two bug hunting through a hundred macroelement terms. > Maybe using only CloughTocher elements might be solution here. That would work, but I'd be worried about what CloughTocher mappings might do to your quadrature rules. Granted, any kind of nonaffine map can mess up your nice exact Gaussian quadrature, but the CloughTocher basis functions have internal subelement boundaries which might be even worse. > Are CloughTocher and Hermite FEFamilys similar enough to be > different ElemTypes of the same FEFamily? No; even if the code worked, the resulting function space would only be C0 conforming. I guess having a space which was C1 almost everywhere might be good for some applications, but my fourth order problems would start producing bad results.  Roy 
From: <tim@ce...>  20060807 09:43:38

Dear Roy, On Fri, 4 Aug 2006, Roy Stogner wrote: > On Fri, 4 Aug 2006, Tim Kr=F6ger wrote: > >> I did these changes now; see the attached patch. Please commit it to th= e=20 >> repository (provided that you are satisfied with it). > > One problem I see: in the case of quadratic mappings (or any more > complicated mappings, if the University of Auckland folks decide to > code them!) it's possible for an element's nodes to all be inside a > bounding box even though part of the element interior extends outside > the box. You are right, I did not think about this. > I don't know of any fast way to get the real bounding box for even a > quadratic element. This will be a very uncommon problem, though  > perhaps an adequate solution for now is just to leave in the fallback > linear search. > The inverse map iteration definitely won't converge for some elements > if the physical point is outside the element, but that shouldn't cause > a problem for Elem::constains_point() anymore; if its call to > inverse_map() doesn't converge, the result is a distant point that > will make sure on_reference_element() is false. No: If the nonlinear solver doesn't converge, it will call error() and=20 thus crash. At least, this call to error() should be removed =20 perhaps by giving the solver class an optional argument. The other problem that I see when leaving the linear search in is that=20 when I will later implement the possibiliy to evaluate the=20 MeshFunction outside the domain covered by the grid, the linear search=20 will slow this down considerabely. What about adding some heuristic safety margin around the bounding box=20 in the case of quadratic mappings? Well, not really satisfying ... Perhaps better: Enable the linear search only if quadratic mappings=20 are involved. Any suggestions? Best Regards, Tim 
From: Karl Tomlinson <k.tomlinson@au...>  20060807 06:36:54

Thanks, Roy, for your positive comments and thoughts. On Fri, 4 Aug 2006 16:09:16 0500 (CDT), Roy Stogner wrote: > On Sat, 5 Aug 2006, Karl Tomlinson wrote: > >> However, we have many existing meshes that use Hermite >> interpolation for the geometric variables (xyz). [snip] >> Any thoughts on how this might be done? >> >> I'm used to thinking of x,y,z as variables in themselves, like >> dependent (system) variables in libMesh, each with their own >> FEType. But I think it is reasonable that x,y,z should all have >> the same FEType (but not necessarily the same as that of each of >> the dependent variables). > > This makes sense when the domain is transformed from a cartesian grid, > but what do you do on more general unstructured meshes? I now see that libMesh is storing xyzbased derivatives for the dofs in Hermite meshes, whereas I'm used to thinking of xibased derivatives. When thinking in terms of xyzderivatives, there needs to be some way of calculating the scale factors (dx/dxi) for the geometry. This can be done with edgelengths or something similar but it may be iterative and may not be simple. When the dofs are xiderivatives this step is not an issue. > Imagine you've got three Hermite quads meeting at one point, for > example  what are the mapping variables at that node? If xi and eta > are different between elements, derivatives with respect to xi and eta > won't be uniquely defined on element interfaces. This situation does make things more complicated for the xiderivative implementation. Some linear constraints would be needed to require C1 continuity. (The scale factor matrix provides this in the xyzderivative implementation.) A similar issue exists where an element is adjacent on one side to 2 elements of higher hrefinement level (with a hanging node). I'll have to look more at the libMesh (xyz) implementation. > Also, it's easy to conceive of situations where the mapping variables > take up a different amount of data than any solution variable. It > might be nice to handle NURBS geometries via a two step map: a first > order Lagrange mapping from master elements to a few unit boxes, then > a few NURBS points to define a map from those into physical space. > Perelement NURBS information could work but would waste RAM. I'm not familiar enough with NURBS to comment here. I was thinking that geometric variables should be as similar as possible to solution (or any other  e.g. material parameter) variables, but are you saying that geometric variables may be more complicated than solution variables? >> Should the shape functions for the map be tied more closely to an >> FE for the Mesh (or an Elem) rather than to the FEs for each of >> the dependent variables in each System on the Mesh? > > I'd rather not have a mapping FE associated with each Elem unless we > can think of a cunning data structure; I felt bad about just adding a > byte for p_level until I realized most compilers would have turned > that byte into alignment padding anyway. Adding a perElem pointer to > a mapping FEType object would be a bit much. > > Even if we do something more memory efficient (separate perFEType > std::vector<Elem *>s in Mesh? A tree storing the first and last > element ID number in each contiguous range with the same FEType?), > mixing different mapping FETypes in the same mesh is a little weird. (As I understand it, prefinement essentially changes the FEType through the order and so it is just having different FEFamilys that is the issue. Correct me if I'm wrong.) > I guess more flexibility is better than less, but to simplify code > elsewhere (the FE caching I just added to CVS, for instance) it would > be nice if we could assume there was just one perMesh mapping FEType. For the most part I'm happy with one perMesh mapping FEFamily. The possible exception is CloughTocher and Hermite FEFamilies. I'm not familiar with CloughTocher but they look pretty clever. Hermites don't provide TRI or TET ElemTypes so having some CloughToucher to provide this may be useful. Is this a feasible combination (with hanging node constraints perhaps)? Maybe using only CloughTocher elements might be solution here. Are CloughTocher and Hermite FEFamilys similar enough to be different ElemTypes of the same FEFamily? Karl. 