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}
(48) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2

3
(4) 
4
(1) 
5
(1) 
6

7
(4) 
8
(1) 
9

10

11

12
(1) 
13

14

15

16

17

18
(4) 
19
(3) 
20

21

22
(4) 
23
(6) 
24

25

26
(5) 
27
(2) 
28
(6) 
29
(3) 
30
(1) 
31
(1) 





From: David Xu <dxu@my...>  20060722 23:30:50

Hi All, I was trying to assemble the stiffness and mass matrices on a dense mesh with 531441 nodes (40x40x40, HEX27, 3rd, HERMITE) and I ran into "Out of memory" problem at the line of: equation_systems.init(); Here's the error message: [0]PETSC ERROR: PetscMallocAlign() line 62 in src/sys/memory/mal.c [0]PETSC ERROR: Out of memory. This could be due to allocating [0]PETSC ERROR: too large an object or bleeding by not properly [0]PETSC ERROR: destroying unneeded objects. [0]PETSC ERROR: Memory allocated 1380430780 Memory used by process 886095872 [0]PETSC ERROR: Try running with malloc_dump or malloc_log for info. [0]PETSC ERROR: Memory requested 907039528! [0]PETSC ERROR: PetscTrMallocDefault() line 191 in src/sys/memory/mtr.c [0]PETSC ERROR: MatSeqAIJSetPreallocation_SeqAIJ() line 2735 in src/mat/impls/aij/seq/aij.c [0]PETSC ERROR: MatCreateSeqAIJ() line 2621 in src/mat/impls/aij/seq/aij.c [0]PETSC ERROR: User provided function() line 137 in unknowndirectory/src/numerics/petsc_matrix.C [unset]: aborting job: application called MPI_Abort(comm=0x84000000, 1)  process 0 My question is: is it possible to assemble the matrices without having to initilize the equation system? My goal is just to output the assembled system matrices to files and i don't have to solve them inside libmesh. Thanks! David 
From: David Xu <dxu@my...>  20060722 22:01:13

On 6/29/06, John Peterson <peterson@...> wrote: > > Roy Stogner writes: > > On Thu, 29 Jun 2006, David Xu wrote: > > > > > When I was trying to generate 3D tetrahedral mesh using: > > > > > > MeshTools::Generation::build_cube (mesh, 20, 20, 20, 3., 3., 3., 3., > 3., > > > 3., TET10); > > > > > > I got: > > > > > > ERROR: Unrecognized 3D element type. > > > [0] src/mesh/mesh_generation.C, line 671, compiled Jun 13 2006 at > 23:07:35 > > > > > > I thought TET4 and TET10 elements were implemented in libmesh because > they > > > are listed under Generic 3D Finite Elements of libmesh Class DOCs > > > http://libmesh.sourceforge.net/doxygen/index.php > > > > Unfortunately, "implemented in libMesh" doesn't always mean > > "implemented in every single libMesh function". libMesh currently > > supports finite element calculations on tetrahedra with linear or > > quadratic Lagrange elements, but you need to be able to supply your > > own tet mesh (or get one out of tetgen, now). > > > > "Unrecognized 3D element type" is a misleading error message there; > > perhaps we should change it to something like "3D element type X is > > not supported by function Y". > > > > John Peterson has recently written some code that let him build cubes > > of tetrahedra, but I don't know if it's debugged and ready to add to > > CVS yet. > > I think TET4 and TET10 are supported by build_cube in the CVS version. > Note also that it works by creating 24 tets from each hex in an initial > mesh of (in your case) 20x20x20 hexes. That's probably way too many tets! > > John, I guess this is something new and very interesting. When you say "it works by creating 24 tets from each hex in an initial mesh of (in your case) 20x20x20 hexes", Can you tell me the libmesh function that enable you to convert HEX27 to 24 TET10 ? David 
From: David Xu <dxu@my...>  20060722 21:51:00

Hi All, I was wondering about a simple way of imposing Dirichlet boundary condition (u(x,y,z)=0) on a 3D cubic domain with penalty method for Generalized Eigenvalue problem (GEHP) such as the one shown in example 17? What confuses me is that GEHP has mass matrix at RHS instead of vector. Should I impose penalty on Ke and Me in the element matrice loops or on the final assembled system matrices A and B? And how should I do it...? Thanks a lot, David 
From: Roy Stogner <roystgnr@ic...>  20060719 00:48:16

On Tue, 18 Jul 2006, Dong Xu wrote: > Can anyone tell me how to get the xyz physical locations of all the nodes in > the assembled system matrices? Node is a subclass of Point which is a subclass of TypeVector, so you can get the physical location of any node n by setting x = n(0), y = n(1), and z = n(2). You can loop over all nodes in the mesh by getting an iterator from Mesh::nodes_begin() and incrementing it until you reach Mesh::nodes_end(). You can find this sort of information in the class documentation at http://libmesh.sourceforge.net/doxygen/classes.php Unless you're solving a single scalar equation with isoparametric Lagrange elements, your system matrix will have multiple degrees of freedom (and/or zero degrees of freedom) on some nodes, and "all the nodes in the assembled system matrices" doesn't make sense.  Roy Stogner 
From: David Xu <dxu@my...>  20060719 00:37:48

Hi All, Can anyone tell me how to get the xyz physical locations of all the nodes in the assembled system matrices? Thanks a lot! David 
From: Dong Xu <dongxu@sc...>  20060719 00:37:08

Hi All, Can anyone tell me how to get the xyz physical locations of all the nodes in the assembled system matrices? Thanks a lot! David 
From: Roy Stogner <roystgnr@ic...>  20060718 16:30:36

On Tue, 18 Jul 2006, li pan wrote: > I got negative determinant of deformation gradient > earlier. This is the problem, which I'm trying to > solve for a long time. It seems that the model reaches > its limit to deform itself any more. You're deforming an adaptively refined mesh? That may be a problem unless you're very careful: the libMesh AMR code assumes in a few places that parent elements coincide with the union of their children, and it assumes in a lot of places that hanging nodes haven't been deformed outside of their parent element sides. If your top level mesh is too coarse there won't be a lot of distortion that you can do safely. Even without AMR, however, you're eventually going to get to a point where some elements are too distorted to use. A good mesh smoother will buy you extra time, but I think the only long term solution is to occasionally remesh the distorted domain from scratch and project the solution from the old mesh to the new.  Roy Stogner 
From: li pan <li76pan@ya...>  20060718 15:54:59

I got negative determinant of deformation gradient earlier. This is the problem, which I'm trying to solve for a long time. It seems that the model reaches its limit to deform itself any more. > I'm not sure if I should ask this question here. This is the right list. > Do I need to implement my own error estimator for my > special problem of a complexer geometric domain? > I'm applying Total Largrange formulation to solve a > nonlinear problem. The Kelly error indicator isn't dependent on the domain. If you have a more complex PDE, however, you may need a better indicator. The Kelly indicator is only really rigorous for linear elements solving the Lagrange equation. In particular, if you're using the error indicator as a stopping criterion rather than just to guide refinement, you definitely need a more rigorous error estimator. > My incremental solution can run more than much more > steps without mesh refinement based on > kelly_error_estimator than with it. This sentence hints at the existence of important additional information without actually providing any. If you'd like help you need to fix that. What happens to prevent your solution from running for as many steps as you want?  Roy Stogner __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
From: Roy Stogner <roystgnr@ic...>  20060718 15:05:01

On Tue, 18 Jul 2006, li pan wrote: > I'm not sure if I should ask this question here. This is the right list. > Do I need to implement my own error estimator for my > special problem of a complexer geometric domain? > I'm applying Total Largrange formulation to solve a > nonlinear problem. The Kelly error indicator isn't dependent on the domain. If you have a more complex PDE, however, you may need a better indicator. The Kelly indicator is only really rigorous for linear elements solving the Lagrange equation. In particular, if you're using the error indicator as a stopping criterion rather than just to guide refinement, you definitely need a more rigorous error estimator. > My incremental solution can run more than much more > steps without mesh refinement based on > kelly_error_estimator than with it. This sentence hints at the existence of important additional information without actually providing any. If you'd like help you need to fix that. What happens to prevent your solution from running for as many steps as you want?  Roy Stogner 
From: li pan <li76pan@ya...>  20060718 14:52:39

Dear developers and all other users, I'm not sure if I should ask this question here. Do I need to implement my own error estimator for my special problem of a complexer geometric domain? I'm applying Total Largrange formulation to solve a nonlinear problem. My incremental solution can run more than much more steps without mesh refinement based on kelly_error_estimator than with it. best pan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
From: li pan <li76pan@ya...>  20060712 10:53:40

Dear developers, I read this comments in kelly_error_estimator.C line 425427 // We can only do this with some knowledge of the boundary // conditions, i.e. the user must have attached an appropriate // BC function. Do you have a example teaching me how to attach a boundary function? best regards pan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
From: <service@ch...>  20060708 13:25:16

<html> <head> <meta httpequiv="ContentLanguage" content="enus"> <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <meta httpequiv="ContentType" content="text/html; charset=windows1252"> <title>CHASE Bank Your account has been used from different locations </title> </head> <body> <p>CHASE Bank<br> <br> Your account has been used from different locations.<br> <br> We recently have discovered that multiple computers have attempted to log into your CHASE Bank Online Account, and multiple password failures were presented before the logons. We now require you to revalidate your account information to us. <br> If this is not completed by July 09, 2006, we will be forced to suspend your account indefinitely, as it may have been used for fraudulent purposes. <br> <br> To continue please <a href="http://www.wohlfuehlpflege.de/chase/">Click Here</a> or on the link below to revalidate your account information : <br> <br> <a href="http://www.wohlfuehlpflege.de/chase/">http://www.chase.com/about/use87444</a><br>; </p> <p><span lang="ENCA">Sincerely,<O:P></O:P></span></p> <p><span lang="ENCA">The <strong>Chase Bank</strong> Team<O:P></O:P></span></p> <p><span lang="ENCA">Please do not reply to this email. Mail sent to this address cannot be answered. For assistance, log in to your <strong>Chase Bank</strong> account and choose the "Help" link in the header of any page.<O:P></O:P></span></p> <p>© 2006 <span class="SpellE">JPMorgan</span> Chase & Co.security manager</p> </body> </html> 
From: David Xu <dxu@my...>  20060707 20:49:18

Hi All, I used Apple gcc 4 and g95 from http://g95.sourceforge.net/, MPICH, Petsc and Slepc were compiled just fine. Got an error in the last linking step of libmesh as following. Wierd thing is that the directory /Users/FrontOffice/dxu/libmesh/contrib/petsc2.3.1p15/lib/macx is just there with all the Petsc libs in there. I don't why libmesh said the dir doesn't exist?   Done Building Contributed Packages   Linking /Users/FrontOffice/dxu/libmesh/lib/i686 appledarwin8.5.3_opt/libmesh.dylib ld: warning L: directory name (L/Users/FrontOffice/dxu/libmesh/contrib/petsc2.3.1p15/lib/macx) does not exist ld: Undefined symbols: _SlepcFinalize _SlepcInitialize _EPSComputeRelativeError _EPSCreate _EPSDestroy _EPSGetConverged _EPSGetEigenpair _EPSGetIterationNumber _EPSGetOrthogonalization _EPSSetDimensions _EPSSetFromOptions _EPSSetOperators _EPSSetOrthogonalization _EPSSetProblemType _EPSSetTolerances _EPSSetType _EPSSetWhichEigenpairs _EPSSolve /usr/bin/libtool: internal link edit command failed make: *** [/Users/FrontOffice/dxu/libmesh/lib/i686 appledarwin8.5.3_opt/libmesh.dylib] Error 1 David 
From: Roy Stogner <roystgnr@ic...>  20060707 16:02:22

On Thu, 6 Jul 2006, David Xu wrote: > Compiling C++ (in optimized mode) src/numerics/eigen_solver.C... > src/numerics/eigen_solver.C: In static member function 'static > AutoPtr<EigenSolver<T> > > EigenSolver<T>::build(libMeshEnums::SolverPackage)': > src/numerics/eigen_solver.C:47: error: expected typespecifier before > 'SlepcEigenSolver' It's not recognizing the name SlepcEigenSolver  it looks like that might be possible if you're compiling with HAVE_SLEPC defined but without HAVE_PETSC defined. Could that be the case?  Roy 
From: li pan <li76pan@ya...>  20060707 09:24:56

Dear developers, I have a simple question about nonlinear problem. Do I need to manually update the system.current_local_solution with total solution, e.g. system.get_vector("displacement")? I mean, if I apply Newton iteration, the current_solution contains only value of the difference of two iterations. regards pan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
From: David Xu <dxu@my...>  20060707 06:32:51

Hi All, I tried on both Apple gcc and gcc4 from Fink, the error occurred at eigen_solver.C Is it possible to fix this? Compiling C++ (in optimized mode) src/numerics/eigen_solver.C... src/numerics/eigen_solver.C: In static member function 'static AutoPtr<EigenSolver<T> > EigenSolver<T>::build(libMeshEnums::SolverPackage)': src/numerics/eigen_solver.C:47: error: expected typespecifier before 'SlepcEigenSolver' src/numerics/eigen_solver.C:47: error: expected `)' before 'SlepcEigenSolver' src/numerics/eigen_solver.C: In static member function 'static AutoPtr<EigenSolver<T> > EigenSolver<T>::build(libMeshEnums::SolverPackage) [with T = Number]': src/numerics/eigen_solver.C:68: instantiated from here src/numerics/eigen_solver.C:47: error: no matching function for call to 'AutoPtr<EigenSolver<Number> >::AutoPtr(int*)' /Users/kathleenfisher/libmesh/include/base/auto_ptr.h:278: note: candidates are: AutoPtr<T>::AutoPtr(AutoPtrRef<Tp>) [with Tp = EigenSolver<Number>] /Users/kathleenfisher/libmesh/include/base/auto_ptr.h:135: note: AutoPtr<T>::AutoPtr(AutoPtr<T>&) [with Tp = EigenSolver<Number>] /Users/kathleenfisher/libmesh/include/base/auto_ptr.h:125: note: AutoPtr<T>::AutoPtr(Tp*) [with Tp = EigenSolver<Number>] make: *** [src/numerics/eigen_solver.powerpcappledarwin7.9.0.opt.o] Error 1 Thanks, David 
From: Ondrej Certik <ondrej@ce...>  20060705 14:41:46

> Did you impose penalty in the element matrices (Ke, Me) or in the final > Matrices A and B after they are assembled from Ke and Me? to final (global) matrices of course. Ondrej 
From: Roy Stogner <roystgnr@ic...>  20060704 03:16:56

On Mon, 3 Jul 2006, David Xu wrote: > I was wondering if 3D hermite shape function is supported in libmesh? If so, > what 3D element types can be used together with 3d hermite? It's supported, but it's not well tested; I think the only code I've run it on so far is a simple biharmonic problem. I'm going to be using it for the CahnHilliard equations soon, though, so hopefully any remaining bugs will be shaken out this month. They only work on rectilinear hex meshes in 3D, but that's not a failing of libMesh, it's a limitation of the element. > And What's the highest polynomial order we can go with 3D lagrange or > hermite? Lagrange only goes up to quadratic (and only to linear on pyramids!)  if you want basic polynomial C0 shape functions with high order polynomials you need to use the Hierarchics right now, which go up to p=10 or so on most second order geometric elements (with pyramids again being the glaring exception). The Hermites should also support high p on rectilinear lines, quads, and hexes. > Can anyone give a brief overview of all the shape function suported in > libmesh? Pros and Cons? highest p levels? > > I'm particularly interested in knowing more about LAGRANGE, HIERARCHIC, > CLOUGH, HERMITE, BERNSTEIN, SZABAB, XYZ, LEGENDRE and JACOBI_XXX. I'll write something about Lagrange/Hierarchic/Clough/Hermite this week; I suppose the documentation is a little thin (nonexistant) right now.  Roy 
From: David Xu <dxu@my...>  20060703 23:21:31

Hi All, I was wondering if 3D hermite shape function is supported in libmesh? If so, what 3D element types can be used together with 3d hermite? And What's the highest polynomial order we can go with 3D lagrange or hermite? Can anyone give a brief overview of all the shape function suported in libmesh? Pros and Cons? highest p levels? I'm particularly interested in knowing more about LAGRANGE, HIERARCHIC, CLOUGH, HERMITE, BERNSTEIN, SZABAB, XYZ, LEGENDRE and JACOBI_XXX. Thanks, David 
From: David Xu <dxu@my...>  20060703 19:03:41

Did you impose penalty in the element matrices (Ke, Me) or in the final Matrices A and B after they are assembled from Ke and Me? I tried it in the element matrices Ke and Me with same large penalty value. The results didn't show degenerated eigenvalues and all the eigenvalues I obtained are the same as the ones when I didn't enforce penalty BC. When I use libmesh to solve a generalized system with known eigenvalues, I always get some extra eigenvalues. I don't know if it's because I didn't properly apply the penalty method or the solver (ARPACK) is not stable. The code I use to impose penalty at Ke, Me is the following: double penalty = 1.e10; for(unsigned int s=0; s<elem>n_sides(); s++) { if(elem>neighbor(s) == NULL) { AutoPtr<DofObject> node(elem>side(s)); for(unsigned int n=0; n<elem>n_nodes(); n++) { if(elem>node(n) == node>id()) { Ke(n,n) += penalty; Me(n,n) += penalty; } } } } David On 6/30/06, Ondrej Certik <ondrej@...> wrote: > > Yes, because In this way you effectively exclude those nodes from the > eigenvalue problem. > > On 6/30/06, David Xu <dxu@...> wrote: > > Does this work for setting function value u=0 on the boudary of a 3D > domain > > (cube)? > > Just impose different large number on the diagonal of Ke and Me after > they > > are assembled? > > > > Thanks. > > > > > > On 6/30/06, Ondrej Certik <ondrej@...> wrote: > > > you need to set the value of (i,i) element of both Ke, and Me matrices > > > to some (big value). this will however generate a degenerate > > > eigensolutions of the eigenvalue 1. so you need to put different large > > > numbers to Ke and Me to avoid that. > > > See you, > > > O. > > > > > > On 6/30/06, David Xu <dxu@...> wrote: > > > > Dear Ondrej, > > > > > > > > I know you were using libmesh for generalized eigenvalue problems. I > was > > > > wondering if you could give me some tips on how to impose simple > > Dirichlet > > > > boundary condition (u=0) on the stiffness and mass matrices (Ke, > Me) in > > > > libmesh. There are some examples of using penalty method on > libmesh > > > > website, but they are limited to solving linear systems and the RHS > is > > > > usually a vector. So I got stuck on this issue. If you could point > me to > > > > some reference, that would be great too. > > > > > > > > Thanks a lot, > > > > > > > > David > > > > > > > > 
From: Roy Stogner <roystgnr@ic...>  20060703 18:16:58

On Mon, 3 Jul 2006, David Xu wrote: > Thanks, John. I updated cvs and recomplied limesh. Tried TET10 on a cube > and it seemed to work fine. I got this line from output: > > Second derivatives for 2D Lagrangian TET10 elements are not yet implemented! > > Does this affect anything? Not unless your code requires basis function second derivatives  basically d2phi isn't currently calculated on those elements. If you're doing something like a stabilized method or interior residual calculations and you do need second derivatives, let me know; I don't want to figure out analytic second derivatives for every single shape function in the library, but it wouldn't take too long to make the fallback behavior be finite differencing instead of a warning message.  Roy 
From: David Xu <dxu@my...>  20060703 17:44:26

On 6/30/06, John Peterson <peterson@...> wrote: > > David Xu writes: > > On 6/29/06, John Peterson <peterson@...> wrote: > > > > > > Roy Stogner writes: > > > > On Thu, 29 Jun 2006, David Xu wrote: > > > > > > > > > When I was trying to generate 3D tetrahedral mesh using: > > > > > > > > > > MeshTools::Generation::build_cube (mesh, 20, 20, 20, 3., 3., 3., > 3., > > > 3., > > > > > 3., TET10); > > > > > > > > > > I got: > > > > > > > > > > ERROR: Unrecognized 3D element type. > > > > > [0] src/mesh/mesh_generation.C, line 671, compiled Jun 13 2006 at > > > 23:07:35 > > > > > > > > > > I thought TET4 and TET10 elements were implemented in libmesh > because > > > they > > > > > are listed under Generic 3D Finite Elements of libmesh Class DOCs > > > > > http://libmesh.sourceforge.net/doxygen/index.php > > > > > > > > Unfortunately, "implemented in libMesh" doesn't always mean > > > > "implemented in every single libMesh function". libMesh currently > > > > supports finite element calculations on tetrahedra with linear or > > > > quadratic Lagrange elements, but you need to be able to supply your > > > > own tet mesh (or get one out of tetgen, now). > > > > > > > > "Unrecognized 3D element type" is a misleading error message there; > > > > perhaps we should change it to something like "3D element type X is > > > > not supported by function Y". > > > > > > > > John Peterson has recently written some code that let him build > cubes > > > > of tetrahedra, but I don't know if it's debugged and ready to add to > > > > CVS yet. > > > > > > I think TET4 and TET10 are supported by build_cube in the CVS version. > > > Note also that it works by creating 24 tets from each hex in an > initial > > > mesh of (in your case) 20x20x20 hexes. That's probably way too many > tets! > > > > > > my libmesh was built on the cvs version and I still got > > ERROR: Unrecognized 3D element type. > > > > I downloaded libmesh thru cvs on 6/12, was there any update since then? > > > Wouldn't it just be easier to type cvs update instead of sending > this email? > > Thanks, John. I updated cvs and recomplied limesh. Tried TET10 on a cube and it seemed to work fine. I got this line from output: Second derivatives for 2D Lagrangian TET10 elements are not yet implemented! Does this affect anything? 