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) 
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) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

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) 
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) 
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) 
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) 
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) 
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) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(20) 
_{Dec}
(12) 
2015 
_{Jan}
(25) 
_{Feb}
(2) 
_{Mar}
(16) 
_{Apr}
(13) 
_{May}
(21) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(9) 
_{Oct}
(30) 
_{Nov}
(8) 
_{Dec}

2016 
_{Jan}
(16) 
_{Feb}
(31) 
_{Mar}
(43) 
_{Apr}
(18) 
_{May}
(21) 
_{Jun}
(11) 
_{Jul}
(13) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3

4

5

6

7

8

9

10

11
(1) 
12

13

14

15

16

17

18

19

20

21
(1) 
22
(2) 
23

24

25

26

27

28

29

30
(1) 


From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20040930 18:44:03

I've been too quiet on this list lately, what with my day job and all. Just wanted to check in and see what people are up to. If you have a minute I'd love to hear what's going on (related or unrelated to libMesh). I'm doing aerothermodynamics work here at NASA Johnson Space Center. Sometimes that means running CFD, sometimes it is experimental work, and sometimes it is supporting realtime mission stuff. I'm also still working on my PhD, and my wife and I are expecting a daughter at the end of October. I've been using libMesh quite regularly for various things, but I haven't contributed anything major in a little while. Hopefully that will change soon.  Benjamin S. Kirk benjamin.kirk@... NASA/JSC, Applied Aerosciences & CFD Branch 2814839491 
From: John Peterson <peterson@cf...>  20040922 00:39:57

Yes, it looks like one needs to call MatAssemblyBegin() and MatAssembl= yEnd() before trying to call MatZeroEntries(). John Martin L=FCthi writes: > Hi >=20 > PETSc 2.2.1 complains about following call in the Newmark_System > (line 180)=20 >=20 > void NewmarkSystem::compute_matrix () > { > // zero the global matrix > this>matrix>zero(); >=20 > with >=20 > [0]PETSC ERROR: MatZeroEntries() line 3730 in src/mat/interface/matr= ix.c > [0]PETSC ERROR: Object is in wrong state! > [0]PETSC ERROR: Not for matrices where you have set values but not y= et assembled! > [0]PETSC ERROR: User provided function() line 170 in unknowndirector= y/src/numerics/petsc_matrix.C >=20 > Any clues what to do with this? >=20 
From: <luthi@gi...>  20040922 00:11:05

Hi PETSc 2.2.1 complains about following call in the Newmark_System (line 180)=20 void NewmarkSystem::compute_matrix () { // zero the global matrix this>matrix>zero(); with [0]PETSC ERROR: MatZeroEntries() line 3730 in src/mat/interface/matrix.= c [0]PETSC ERROR: Object is in wrong state! [0]PETSC ERROR: Not for matrices where you have set values but not yet = assembled! [0]PETSC ERROR: User provided function() line 170 in unknowndirectory/s= rc/numerics/petsc_matrix.C Any clues what to do with this? Best, Martin =20 Martin L=FCthi University of Alaska, Fairbanks Dr. sc. nat. tel: +1 (907) 474 7443 fax: +1 (907) 474 7290 mel: luthi@... http://gi.alaska.edu/~luthi/ 
From: <luthi@gi...>  20040921 23:50:16

Hi Petsc changed their solver interface a little. So here is a trivial patch for petsc_interface.C Best, Martin 
From: Benjamin S. Kirk <benkirk@cf...>  20040911 03:37:46

You are right that the variable and element order are related, but sadly the relationship is a little more complicated that what you described... In general, the Elem::order() defines the "natural" order of the element. This is the order implied by a Lagrange nodal basis that employs all the nodes of the element. This is the basis that is used for geometrical operations, like mapping the physical element to a reference element for shape function evaluation, computing the element Jacobian, etc... Right now Elem::order() is hardcoded for each element type to be what you would expect: Quad4::order() is FIRST, Quad8::order() is SECOND, Quad9::order() is SECOND, etc... If we had a Quad16 bicubic element its order would be THIRD. Since this is the order that is used in the geometric mapping a 2D mesh composed of Quad9's and Tri6's can represent quadratic boundaries exactly since the elements may have secondorder curved edges. (Note that hardcoding Elem::order() in this case may be inefficient: if the sides are straight with equispaced nodes then there is no need to compute a secondorder map. In the future fullorder mapping may only be applied to elements touching the boundary of the domain.) On the other hand, the approximation order is exactly that: the polynomial degree used in approximating an unknown. This is where the element order and approximation order get a bit confusing...  For Lagrange finite elements (the default) you have *at most* one DOF per node, so here your approximation order must be <= the element order. For example: o You *could* do firstorder approximation on a Quad9, there will just not be any DOFs at the edge or center node. o You *cannot* do secondorder approximation on a Quad4.  For Hierarchic finite elements there may be multiple DOFs per node, so in this case your approximation order may be higher than the element order. Another example: o You *can* do thirdorder approximation on a Quad9. In this case there will be 1 DOF per corner node, 2 DOFs per edge node, and 4 DOFs at the center node  For DG finite elements you can have any approximation order on any element order. As for the other questions: A mesh should contain elements of the same order. A mix of Quad8, Quad9, and Tri6's is valid, but a mix of Tri3's and Quad9's is not. (In the former case all edges have a middle node, in the latter only some would.) You can add variables of whatever order you want, provided you observe the previous "rules." Sometimes, however, the equations you are solving actually limit the choice of variable approximation. See for example, uh, example 11. There we solve the Stokes equations for a lowspeed incompressible fluid. We use second order approximation for the Cartesian velocity components, but only first order for the pressure. In the case of the Stokes equations using equalorder interpolation for the velocity and pressure can actually produce a mathematically unstable approximation. If you are curious about similar restrictions for the class of problems you are interested in I recommend checking the finite element literature related to such applications... If there is no endless babble about approximation space compatibility, LBB, infsup, etc... then equalorder approximation is probably safe. Let me know if you have any more questions, Ben PS: A longterm goal is to add socalled prefinement support, in which case the approximation order can actually vary from element to element. Manav Bhatia wrote: > Hi > I needed some help in understanding the order of the > variable that we add to a system and that of the > elements. > As I would guess, the former has to be less than or > equal to the latter. But I can not understand the > following: >  what would happen if the mesh has elements of mixed > order, say first and second, and then we add a > variable of order first? >  what would happen if we have to variables in the > same system of the same order? >  are there any specific guidelines about choosing > the variable's order in such mixed cases? > > Thanks in advance. > > Regards > Manav > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail  50x more storage than other providers! > http://promotions.yahoo.com/new_mail > > >  > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 