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}
(28) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(9) 
2
(42) 
3
(17) 
4
(10) 
5
(12) 
6
(11) 
7

8
(2) 
9
(14) 
10
(11) 
11
(4) 
12

13

14
(2) 
15
(1) 
16
(3) 
17
(3) 
18
(4) 
19
(3) 
20
(2) 
21
(1) 
22

23
(4) 
24
(1) 
25
(1) 
26
(5) 
27
(2) 
28
(3) 
29
(1) 
30
(1) 
31





From: Roy Stogner <roystgnr@ic...>  20070705 20:46:48

On Thu, 5 Jul 2007, Tahar Amari wrote: > I read your slides about divergence free finite element . > It is very interesting. > It sounds you did not need to use RaviartThomas finite element. That's correct. > Would you suggest me that I could be able to solve > MHD equation, now a vector field B is divergence free > without having to use H(div) or H(rot) finite element, > on Tetrahedra. I don't think I would recommend it. The trouble with using divergencefree spaces generated from the curl operator is that in three dimensions the curl operator's kernel is huge. In 2D the kernel is one dimensional and so it's easy to constrain away to produce a positive definite system; in 3D you either need a very clever way of constraining away the kernel or you need your solvers to be able to handle highly underdefined systems of equations. My graduate studies committee claimed the problem was "too hard or impossible" in 3D, which was an overstatement, but it was turning out to be difficult and inefficient enough that I didn't argue about changing my dissertation topic. > Suppose I have a tetrahedral mesh, what kind of element could I use > ? Degree of freedom on the vertices of the tetrahedra ? > > Do you rewrite the equaitons with a potential vector > B=rot(A) such that div B= 0 (your slide #3 writes u=rot(psi). Yes; but unlike in 2D where psi is a scalar (with an implicit vector direction of +z), in 3D A is a full vector. Your finite element space is then three scalar elements, $C^1$ elements if you don't want end up with interface integrals in your weak formulation. The only 3D C^1 elements in libMesh are the Hermite cubes, though, so if you needed to use a tetrahedral mesh you would have to implement something like the AlfeldAwanouLai 4split tetrahedral macroelement. That last sentence was probably the only part of this email relevant to libMesh as a whole, so if you've got more questions on the subject we won't subject libmeshusers to the discussion. If I haven't discouraged you yet, send me a private email and I can dig through my thesis bibliography for you; I think I've got a reference or two to papers using similar techniques for MHD.  Roy 
From: Tahar Amari <amari@cp...>  20070705 20:15:16

Roy, I read your slides about divergence free finite element . It is very interesting. It sounds you did not need to use RaviartThomas finite element. Would you suggest me that I could be able to solve MHD equation, now a vector field B is divergence free without having to use H(div) or H(rot) finite element, on Tetrahedra. Could you please be more precise ? Suppose I have a tetrahedral mesh, what kind of element could I use ? Degree of freedom on the vertices of the tetrahedra ? Do you rewrite the equaitons with a potential vector B=3Drot(A) such that div B=3D 0 (your slide #3 writes u=3Drot(psi). Many thanks Tahar  T. Amari Centre de Physique Theorique Ecole Polytechnique 91128 Palaiseau Cedex France tel : 33 1 69 33 47 53 fax: 33 1 69 33 30 08 email: <mailto:amari@...> URL : http://www.cpht.polytechnique.fr/cpht/amari Le 5 juil. 07 =E0 16:14, Roy Stogner a =E9crit : > On Thu, 5 Jul 2007, Tahar Amari wrote: > >> Great Roy . Since I am new in libmesh , do you think that >> concerning documentation I should go in .h files , to learn about >> the various fonctionalities of the classes , what they do ..... > > I'm afraid we don't have anything like an official manual, so the > example applications and the header files are the best way to learn. > There are processed HTML versions here: > http://libmesh.sourceforge.net/examples.php > http://libmesh.sourceforge.net/doxygen/index.php > Which (depending on your development environment) you may find more > readable than the raw source code. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20070705 20:07:29

Vikram Garg is now reporting good solver results for (low Reynolds number) NavierStokes flow with the following set of PETSc options: pc_hypre_type boomeramg pc_hypre_boomeramg_max_iter 20 ksp_norm_type unpreconditioned ksp_type bcgs The key here is using unpreconditioned norms (and cranking down the linear solver relative tolerance if you're using penalty boundary conditions); this seems to keep the ksp solver from converging prematurely, so any failures in the muligrid preconditioner now get successfully corrected by the Krylov iteration, which no longer ends up with an inaccurate result. The performance on NavierStokes isn't nearly as good as on symmetric positive definite systems, but it's still faster than ILU4 on moderately small problems. We have yet to test it on large problems (or on very asymmetric problems, or on highly nonlinear problems, etc. etc.) but I thought these first results were interesting enough that other users might want to start experimenting themselves.  Roy 
From: Roy Stogner <roystgnr@ic...>  20070705 14:14:09

On Thu, 5 Jul 2007, Tahar Amari wrote: > Great Roy . Since I am new in libmesh , do you think that > concerning documentation I should go in .h files , to learn about > the various fonctionalities of the classes , what they do ..... I'm afraid we don't have anything like an official manual, so the example applications and the header files are the best way to learn. There are processed HTML versions here: http://libmesh.sourceforge.net/examples.php http://libmesh.sourceforge.net/doxygen/index.php Which (depending on your development environment) you may find more readable than the raw source code.  Roy 
From: Tahar Amari <amari@cp...>  20070705 13:54:55

> The PointLocator class currently defaults to PointLocatorTree, which > builds an octree structure for finding the element containing a point. > This probably costs a bit of overhead when you first create the > structure (especially if you do much adaptive mesh refinement, which > invalidates old PointLocators), but it should be roughly O(log N) for > each point you find with it. Great Roy . Since I am new in libmesh , do you think that concerning documentation I should go in .h files , to learn about the various fonctionalities of the classes , what they do ..... Tahar  T. Amari Centre de Physique Theorique Ecole Polytechnique 91128 Palaiseau Cedex France tel : 33 1 69 33 47 53 fax: 33 1 69 33 30 08 email: <mailto:amari@...> URL : http://www.cpht.polytechnique.fr/cpht/amari 
From: Roy Stogner <roystgnr@ic...>  20070705 13:34:04

On Thu, 5 Jul 2007, Tahar Amari wrote: > By the way is there somewhere in libmesh a way of determining to which > tetrahedra belongs a points with '(x,y,z) coordinates given a priori, or > do I have to make it myself ( I can figure out how to do it), but in case it > exists in libmesh I guess it will be optimized (there are several possible > algorithms but those are differently efficient !). The PointLocator class currently defaults to PointLocatorTree, which builds an octree structure for finding the element containing a point. This probably costs a bit of overhead when you first create the structure (especially if you do much adaptive mesh refinement, which invalidates old PointLocators), but it should be roughly O(log N) for each point you find with it.  Roy 
From: Tahar Amari <amari@cp...>  20070705 13:12:55

You are right Roy, I actually also need the edge nodes. Because for example a vector field H(div) with faces centrered degrees of freedom (its normals) , has its rotational H(rot), edge centered. And I also need several interpolation formulaes from cellcenter to =20 facescenter and edgemidle and the other ways too ... By the way is there somewhere in libmesh a way of determining to which tetrahedra belongs a points with '(x,y,z) coordinates given a priori, or do I have to make it myself ( I can figure out how to do it), but in =20 case it exists in libmesh I guess it will be optimized (there are several =20 possible algorithms but those are differently efficient !). Tahar  T. Amari Centre de Physique Theorique Ecole Polytechnique 91128 Palaiseau Cedex France tel : 33 1 69 33 47 53 fax: 33 1 69 33 30 08 email: <mailto:amari@...> URL : http://www.cpht.polytechnique.fr/cpht/amari Le 5 juil. 07 =E0 15:01, Roy Stogner a =E9crit : > On Thu, 5 Jul 2007, Tahar Amari wrote: > >> Excuse me I may not be familiar with the terminology. > > The mistakes may be mine; I know roughly how the finite volume method > works but I've never implemented it or studied it in much detail. > >>> For finite volume schemes where the volumes are the primal =20 >>> triangles, >>> tetrahedra, etc. that libMesh supports, you can use one of our >>> discontinuous finite element spaces like MONOMIAL or XYZ, and >>> initialize the FE objects on interiors to calculate volume integrals >>> and on element sides to handle flux integrals. >> >> Do you mean, Tetrahedral mesh with cell centered unknowns ? > > Yes, exactly. (or triangle mesh with cell centered unknowns, hex mesh > with cell centered unknowns, etc.) > >>> For finite volume schemes where the volumes are centered on primal >>> nodes and discontinuous on primal element interiors, I don't think >>> there's an easy way to perform such calculations in libMesh. >> >> Do you mean, Dual mesh of the Tetrahedral mesh ? >> In this case with node centered unknowns ? > > Again, that is correct. > >>> We'd appreciate your contribution, since a Tet14 class would be >>> useful for high polynomial degree Hierarchic elements as well, but >>> I warn you that it wouldn't be a simple task. >> >> I was thinking of Tet4, only four degree of freedom, on the faces. > > Yes, but because of the way libMesh uses the Node class for both > degree of freedom storage and mesh geometry, a tetrahedron with only > four face nodes can't be used to create a continuous mesh; at the very > least you would additionally need four vertex nodes to define the > geometry, even though with your FE class these nodes would hold zero > degrees of freedom each. And although your application only needs 8 > nodes, if you're going to all that effort then you might as well add > the extra 6 edge nodes and give us a topologically complete element. > ;) >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20070705 13:01:19

On Thu, 5 Jul 2007, Tahar Amari wrote: > Excuse me I may not be familiar with the terminology. The mistakes may be mine; I know roughly how the finite volume method works but I've never implemented it or studied it in much detail. >> For finite volume schemes where the volumes are the primal triangles, >> tetrahedra, etc. that libMesh supports, you can use one of our >> discontinuous finite element spaces like MONOMIAL or XYZ, and >> initialize the FE objects on interiors to calculate volume integrals >> and on element sides to handle flux integrals. > > Do you mean, Tetrahedral mesh with cell centered unknowns ? Yes, exactly. (or triangle mesh with cell centered unknowns, hex mesh with cell centered unknowns, etc.) >> For finite volume schemes where the volumes are centered on primal >> nodes and discontinuous on primal element interiors, I don't think >> there's an easy way to perform such calculations in libMesh. > > Do you mean, Dual mesh of the Tetrahedral mesh ? > In this case with node centered unknowns ? Again, that is correct. >> We'd appreciate your contribution, since a Tet14 class would be >> useful for high polynomial degree Hierarchic elements as well, but >> I warn you that it wouldn't be a simple task. > > I was thinking of Tet4, only four degree of freedom, on the faces. Yes, but because of the way libMesh uses the Node class for both degree of freedom storage and mesh geometry, a tetrahedron with only four face nodes can't be used to create a continuous mesh; at the very least you would additionally need four vertex nodes to define the geometry, even though with your FE class these nodes would hold zero degrees of freedom each. And although your application only needs 8 nodes, if you're going to all that effort then you might as well add the extra 6 edge nodes and give us a topologically complete element. ;)  Roy 
From: Roy Stogner <roystgnr@ic...>  20070705 12:54:27

On Thu, 5 Jul 2007, Tim Kröger wrote: > Does the MeshFunction class work correctly in parallel? I.e., do all > processors get the correct result for the value/gradient at a given > point or only the processor on which the element lives that contains > the point? Currently that's entirely up to you. If you give MeshFunction a standard distributed vector then you'd better only call it with points that live on the local processor. If you need to evaluate points that live on any processor, you need to give MeshFunction a serial vector to use, doing any necessary NumericVector::localize() work manually.  Roy 
From: FreeWebCards.Com <oryug@2f...>  20070705 12:25:15

Hi. Partner has sent you a postcard. See your card as often as you wish during the next 15 days. SEEING YOUR CARD If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet: http://64.112.192.201/?71c16a2e59b1283bd17061a8cb Or copy and paste it into your browser's "Location" box (where Internet addresses go). PRIVACY FreeWebCards.Com honors your privacy. Our home page and Card Pick Up have links to our Privacy Policy. TERMS OF USE By accessing your card you agree we have no liability. If you don't know the person sending the card or don't wish to see the card, please disregard this Announcement. We hope you enjoy your awesome card. Wishing you the best, Administrator, FreeWebCards.Com 
From: Tahar Amari <amari@cp...>  20070705 10:34:35

Hello Roy, Excuse me I may not be familiar with the terminology. > > For finite volume schemes where the volumes are the primal triangles, > tetrahedra, etc. that libMesh supports, you can use one of our > discontinuous finite element spaces like MONOMIAL or XYZ, and > initialize the FE objects on interiors to calculate volume integrals > and on element sides to handle flux integrals. Do you mean, Tetrahedral mesh with cell centered unknowns ? > > For finite volume schemes where the volumes are centered on primal > nodes and discontinuous on primal element interiors, I don't think > there's an easy way to perform such calculations in libMesh. Do you mean, Dual mesh of the Tetrahedral mesh ? In this case with node centered unknowns ? > > There's two difficulties here. > > First, libMesh doesn't support vectorvalued elements; we solve vector > problems by treating each vector component as a scalar variable. This > works when your vectorvalued function spaces are just tensor products > of scalarvalued spaces, but for spaces like the RaviartThomas > produce that isn't true. Second, libMesh has a Tet10 class, but would > need a Tet14 class to handle finite element spaces with face degrees > of freedom on tets. > > The minimal set of changes you'd need to make to the library is to > first add a 14node tetrahedron, then add a scalarvalued FE subclass > that is continuous only at face centroids. Then, in your system > assembly code you would translate quadrature point locations and > scalar values into the isomorphic RaviartThomas values on each > element. We'd appreciate your contribution, since a Tet14 class would > be useful for high polynomial degree Hierarchic elements as well, but > I warn you that it wouldn't be a simple task. I was thinking of Tet4, only four degree of freedom, on the faces. Tahar >  > Roy 
From: <tim@ce...>  20070705 07:36:04

Dear all, Does the MeshFunction class work correctly in parallel? I.e., do all processors get the correct result for the value/gradient at a given point or only the processor on which the element lives that contains the point? Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim@..., tim@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, D28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 