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}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(4) 
2
(1) 
3

4
(2) 
5
(1) 
6
(1) 
7

8
(2) 
9

10

11

12

13
(6) 
14
(8) 
15
(1) 
16
(1) 
17
(2) 
18
(2) 
19
(2) 
20
(5) 
21
(15) 
22

23
(1) 
24

25
(5) 
26
(7) 
27
(7) 
28
(3) 
29
(18) 

From: Lorenzo Botti <bottilorenzo@gm...>  20080213 21:55:47

Hi David and John, I have a dirty DG ex14. It works with h and p refinement with a little change in DofMap::compute_sparsity(...) after the condition if(implicit_neighbor_dofs){....} 
From: John Peterson <peterson@cf...>  20080213 14:39:06

Short answer: yes. Thread here: http://sourceforge.net/mailarchive/message.php?msg_id=41E893F9.9000104%40cfdlab.ae.utexas.edu No examples yet but this would probably be a good idea. Ben  do you have any toy DG codes we could make into an example? J David Knezevic writes: > Hi all, I was just wondering if anyone has done any discontinuous > Galerkin computations using libMesh? I'm just asking this out of > curiousity, I'm not looking to do any DG computations at the moment... > > Thanks, > Dave > 
From: David Knezevic <david.knezevic@ba...>  20080213 11:54:13

Hi all, I was just wondering if anyone has done any discontinuous Galerkin computations using libMesh? I'm just asking this out of curiousity, I'm not looking to do any DG computations at the moment... Thanks, Dave 
From: Benjamin Kirk <benjamin.kirk@na...>  20080213 02:14:08

> Now, I am wondering how algebraic method constrains hanging nodes. Whether > does it set the values at hanging nodes to zero? I output the matrix > assembled in libmesh using PetSC function, I find lots of zero values in > matrix. Because the matrix in Petsc is stored using sparse compressed strage > format, zero values should not appear. Could you give me some hints? The constraint u_f = 1/2 u_c1 + 1/2 u_c2 is a typical constraint  it says the fine value is the average of the coarse values on an edge. It can be imposed through the linear system by zeroing the entire row for u_f and the righthandside entry and replacing it with [u_c1] [ 0 ... 1/2 1 1/2 ...0 ] [u_f ] = [0] [u_c2] Strictly speaking, you could eliminate the u_f row & column from the sparse matrix and the resulting linear system would be 1 dof smaller. In practice though that is more trouble than it is worth. It would take a pathological case (like everyother element in a checkerboard pattern is refined) for the savings gained by reducing the size of the linear system to be worth the effort. Now, the reason there are a number of zeros in that row is simple... In 2D for linear quadrilateral elements a typical row will have 9 nonzero entries, and this is what gets allocated for that row. A typical linear constraint only involves 3 dofs, though, so you are left with some zeros. A quadratic Lagrange quadrilateral typically has 25 nonzeros on a row, but a constraint involves 4 dofs. So, there are 21 stored zeros in that row. This functionality is implemented in the DofMap::constrain_element_matrix_an_vector() function  see http://libmesh.sourceforge.net/doxygen/classDofMap.php It takes the element matrix and vector written in terms of unconstrained dofs and alters them so that they are written entirely in terms of unconstrained dofs. Finally, Is PETSc outputting a compressed matrix, or is it giving you the square matrix and padding with zeros itself? Ben 
From: Roy Stogner <roystgnr@ic...>  20080213 02:04:05

On Tue, 12 Feb 2008, Yujie wrote: > Now, I am wondering how algebraic method constrains hanging nodes. By default, the matrix line corresponding to each hanging node is the constraint equation which sets its value. This constrains each hanging node to whatever precision your linear solver gives; the hanging node degree of freedom coefficient is then not zero, it's whatever value is correct for the degree of freedom equation on the fine elements. > Whether does it set the values at hanging nodes to zero? With nondefault options set, the matrix line for each hanging node is (like the matrix column) just a "1" on the diagonal, with a corresponding 0 on the residual vector, so that the node coefficient is zero immediately after the linear solve. In this case, user code (or higher level library code like NewtonSolver::solve()) must then use the constraint equations to set the hanging node coefficients to their correct values. > I output the matrix assembled in libmesh using PetSC function, I > find lots of zero values in matrix. Because the matrix in Petsc is > stored using sparse compressed strage format, zero values should not > appear. That is incorrect. The sparsity pattern we tell PETSc to use comes from the connectivity of your mesh, which is much more efficient than building it on the fly as you assemble the matrix with your particular equation. Some multivariable equations (NavierStokes, in particular) and/or some choices of basis functions can then leave you with zero entries. If your equation is of the former type you can use DofObject::_dof_coupling to tell libMesh not to bother allocating matrix entries that you know will always be zero. However, it's also possible that we're allocating too many entries in the sparsity pattern. Can you come up with a specific example of two DoFs that you know shouldn't be coupled?  Roy 
From: Yujie <recrusader@gm...>  20080213 01:47:46

Hi, everyone Now, I am wondering how algebraic method constrains hanging nodes. Whether does it set the values at hanging nodes to zero? I output the matrix assembled in libmesh using PetSC function, I find lots of zero values in matrix. Because the matrix in Petsc is stored using sparse compressed strage format, zero values should not appear. Could you give me some hints? thanks a lot. Regards, Yujie 