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}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(7) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(2) 
2
(2) 
3
(6) 
4
(8) 
5
(10) 
6

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

19
(2) 
20

21

22
(5) 
23
(6) 
24
(6) 
25
(3) 
26
(2) 
27
(2) 
28
(5) 
29

30






From: Travis Austin <austint73@ya...>  20070417 08:46:26

Hi, I've been using BoomerAMG with success for diffusiontype problems. Please note that it was designed for what are called M matrices that have the property that they are symmetric. One shouldn't necessarily expect BoomerAMG to work well for every matrix out there. (It may not work at all in some cases) Thus I don't believe that the BoomerAMG method is broken in any way but must be used with care and thought as to when it is appropriate and when it is not. It is not a black box solver that you can throw any and all matrices at and expect it to work. There are actually loads of flags and settings that need tweaking for different systems of equations. I doubt that these have been explored with respect to libMesh problems. It may be useful to consider the other solvers in HYPRE (Parasails, PILUT, etc.) for these asymmetric problems. Once you start solving asymmetric problems the world of developing MG solvers gets more compilicated. Quite often these methods must be developed specifically for the equations at hand, like for strong convection. You need to understand what are the oscillatory and smooth modes for these problems to do it right. This is why people use AMG methods when they can. You could also use PETSc which has some MG capabilities. There are probably lots of examples out there but I think it is more than just throw it a matrix. I believe you have to use PETSc to do some of the discretization. Travis  Original Message  From: Roy Stogner <roystgnr@...> To: li pan <li76pan@...> Cc: libmeshusers@... Sent: Tuesday, April 17, 2007 4:03:20 AM Subject: Re: [Libmeshusers] multigrid method On Mon, 16 Apr 2007, li pan wrote: > I'm reading a book about multigrid method. The reason > to use MG method is, as I understand, to solve linear > equation faster. My question is, whether there is > advantage to implement MG in libmesh. Absolutely. We have algebraic multigrid (AMG) partially working via PETSc/HYPRE/BoomerAMG, and for the simple problems it handles correctly (symmetric positive definite matrices) it finishes large solves in minutes which would take a Krylov+ILU method hours. More complex PDEs won't get two orders of magnitude speedup, but there should still be a big improvement at least on fine meshes. Unfortunately, my experiments with BoomerAMG support seem to fail on strongly asymmetric problems and (more alarmingly) seem to "converge" to the wrong result on weakly asymmetric problems. I would be thrilled to see someone fix the algebraic multigrid support or add geometric multigrid support (at least through PETSc's MG interface), but doing either might be quite a bit of work.  Roy  This SF.net email is sponsored by DB2 Express Download DB2 Express C  the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
From: Roy Stogner <roystgnr@ic...>  20070417 03:55:27

On Tue, 17 Apr 2007, Shengli Xu wrote: > Hello, Libmesh Users, > I have a question about the structure of the result vector of libmesh > system. > The following codes are from the GMVIO class : > > 00379 for (unsigned int n=0; n<mesh.n_nodes(); n++) > 00380 out << std::setprecision(10) << (*v)[n*n_vars + c] << " "; > My question is : If the field variables of system don't use the equal > order shape function, such as Q84 for stokes flow. The answer is simple: v is NOT the result vector of your solution. Before an IO class's write_nodal_data function is called, a serial vector v of nodal function values is calculated from the parallel solution vector. This means that if you have mixed biquadratic/bilinear data on a quad element, for example, all variables will be plotted as four bilinear quads. Unfortunately, this also means that if you have biquintic data on a quad element, it will still be plotted as four bilinear quads  currently the only format we have that supports the "raw" field variables is .xda/.xdr files.  Roy 
From: Shengli Xu <shengli.xu@gm...>  20070417 03:37:18

Hello, Libmesh Users, I have a question about the structure of the result vector of libmesh system. The following codes are from the GMVIO class : 00377 out << (*solution_names)[c] << " 1\n"; 00378 00379 for (unsigned int n=0; n<mesh.n_nodes(); n++) 00380 out << std::setprecision(10) << (*v)[n*n_vars + c] << " "; 00381 00382 out << "\n\n"; 00383 00384 #endif My question is : If the field variables of system don't use the equal order shape function, such as Q84 for stokes flow. the four corner nodes have three variables : U, V, P. other four nodes on the middle of line have two variables: U, V. c is 0 for U, c is 1 for V, c is 2 for P. n_vars is 3. When n is not the coner node, it only has two variable. (*v)[n*n_vars+0] is U , (*v)[n*n_vars+1] is V. I want to know what is (*v)[n*n_vars+2] for this node?  Best regards, Yours sincerely ShengliXu Department of Engineering Mechanics State Key Laboratory of Structural Analysis for Industrial Equipment Dalian University of Technology Dalian, 116023, P. R. China Email:shengli@... shengli.xu.xu@... ========================== 