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}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(36) 
_{Mar}
(49) 
_{Apr}
(41) 
_{May}
(73) 
_{Jun}
(51) 
_{Jul}
(12) 
_{Aug}
(69) 
_{Sep}
(26) 
_{Oct}
(35) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3
(4) 
4
(14) 
5

6

7

8
(6) 
9
(4) 
10
(2) 
11

12

13
(1) 
14

15
(3) 
16

17

18
(1) 
19

20
(2) 
21

22
(2) 
23
(5) 
24
(1) 
25
(1) 
26

27

28

29
(1) 
30





From: Roy Stogner <roystgnr@ic...>  20101108 20:16:41

On Mon, 8 Nov 2010, Saurabh Srivastava wrote: > I am currently using Libmesh to develop a fluid solver for coupling > with particles/structures. I have a few related questions .. > > A) Does the reinit() function in equation system classs ..allows > solution to be projected onto new mesh? (as I recall from one of the > example problems) Yes. > while I use this functionality in conjunction with Hierarchic basis > function on Tri6 elements it seems the library throws an error. Indeed it does! I can replicate that (seeing an exception in the ghosted vector support) just by switching ex14 to cubic hierarchics. I'll look into this ASAP. > Does this projection also work with 3D elements? It should. > What other alternatives do I have for reinit/projection? Right now? Nothing. It would be possible to make the current System::ProjectVector object userreplaceable if you need a projection with some properties that the default lacks. > B) Does Libmesh provide higher order Hierarchic basis on Tet10? it > seems again the code would breakdown with such a choice, since only > a second order Lagrangian basis is possible on Tet10, I'm interested > in Hierarchic Tets for arbitrary higher order polynomials? The problem with adaptivity on hierarchic bases is a bug which (hopefully) should be fixed shortly. But the lack of hierarchic bases on Tet10 is a missing feature which won't be implemented until a new developer who needs them puts in the work. Most of the framework is there (fe_shape_hierarchic_3D.C supports hexes and fe_shape_hierarchic_2D.C supports simplices in 2D) but nobody's coded and tested that combination. > I did post this question on user's list but awaiting response yet. My apologies  I saw your question, didn't have time to get to it that week, then let it completely slip my mind. I'll let everyone know as soon as I have that regression pinned down.  Roy 
From: Roy Stogner <roystgnr@ic...>  20101108 16:26:57

On Mon, 8 Nov 2010, Tim Kroeger wrote: > Idea #4: Upon removing the columns of the matrix, automatically adjust > the right hand side. I think this would actually be quite easy to do > by the following procedure: > > 1. Remove the inactive rows of the matrix. > > 2. Let B denote the active columns of the matrix and C all the remaining (inactive) columns. > > 3. Subtract C*x from b (where b is the right hand side and x the solution vector). > > 4. Then solve with B as before. > > Idea #5: Follow Jed's prior objection that just leaving the inactive > components of the solution vector unchanged makes the whole thing > become a weird beast. For instance, this should be able to be > achieved by subtracting an appropriate vector before solving and > adding it again afterwards. > > Any thoughts? I dislike ideas #13; no opinion on #4 vs #5, but want to add: Idea #6: Add an example 24 (or 25, whatever's free when this is all finally finished) demonstrating a use of SystemSubset stuff. We added constrain_element_matrix_and_vector calls to even the nonadaptive examples a while back after the third time I helped someone fix their "why is my modifiedfromex4 application giving wrong results on adaptive meshes" bug, and this code is less intuitive than that. I'd like to be sure it doesn't get left out of regression testing too, in part for the same reason.  Roy 
From: Tim Kroeger <tim.kroeger@ce...>  20101108 15:55:04

On Mon, 8 Nov 2010, Tim Kroeger wrote: > Idea #4: Upon removing the columns of the matrix, automatically adjust > the right hand side. I think this would actually be quite easy to do > by the following procedure: > > 1. Remove the inactive rows of the matrix. > > 2. Let B denote the active columns of the matrix and C all the remaining (inactive) columns. > > 3. Subtract C*x from b (where b is the right hand side and x the solution vector). > > 4. Then solve with B as before. After thinking about this some more time, I am now unsure at which point in the code the complement (PETSc) index set should be determined. The most native point would be in PetscLinearSolver::restrict_solve_to(), since this is the point where to other (noncomplement) index set is created. But this is not possible because this method (with the current API) has no chance to determine the overall index range, because this method does not get a vector. My idea would be add ab extra method, e.g. PetscLinearSolver::create_complement_is(), to create the complement index set. This method would be called from any solve() method, and if the complement index set has already been computed before, it will do nothing. Any thoughts?  Dr. Tim Kroeger CeVis  Center of Complex Systems and Visualization University of Bremen tim.kroeger@... Universitaetsallee 29 tim.kroeger@... D28359 Bremen Phone +494212187710 Germany Fax +494212184236 
From: Tim Kroeger <tim.kroeger@ce...>  20101108 15:30:51

On Mon, 8 Nov 2010, Derek Gaston wrote: > I haven't followed this whole thread so forgive me if this has been > explained... but how do you end up with a refined element (D) being > in a different subdomain from it's parent (that made up ABCD)? Is > your subdomain evolving throughout the simulation? Because without > that happening this wouldn't be a problem. Yes, the subdomain_id values are changing throughout the simulation. Actually, what happens is that in a certain situation I collect the elements that will belong to the subset using certain criteria, and I then just use (one bit of) subdomain_id as a flag. Each time I do this, the subset can be different. Best Regards, Tim  Dr. Tim Kroeger CeVis  Center of Complex Systems and Visualization University of Bremen tim.kroeger@... Universitaetsallee 29 tim.kroeger@... D28359 Bremen Phone +494212187710 Germany Fax +494212184236 
From: Derek Gaston <friedmud@gm...>  20101108 15:18:01

On Nov 8, 2010, at 8:07 AM, Tim Kroeger wrote: > The next difficulty with my solveonpartofdomain stuff has now > shown up. It is the constraineddof issue now, which Roy already > predicted and I didn't believe. Luckily enough, my application seems > to be sufficiently complicated for any potential problem to actually > occur. > > Let's assume the following situation: > > a    b    c        d >     >  A  B   >     > e    f    g E  >     >  C  D   >     > h    i    j        k >    >    >    >  F  G  >    >    >    > l        m        n I haven't followed this whole thread so forgive me if this has been explained... but how do you end up with a refined element (D) being in a different subdomain from it's parent (that made up ABCD)? Is your subdomain evolving throughout the simulation? Because without that happening this wouldn't be a problem. Derek 
From: Tim Kroeger <tim.kroeger@ce...>  20101108 15:07:47

The next difficulty with my solveonpartofdomain stuff has now shown up. It is the constraineddof issue now, which Roy already predicted and I didn't believe. Luckily enough, my application seems to be sufficiently complicated for any potential problem to actually occur. Let's assume the following situation: a    b    c        d      A  B       e    f    g E       C  D       h    i    j        k           F  G           l        m        n Elements A, B, and C are inside the active subdomain, the others are outside. My application hence imposes Dirichlet boundary conditions for dofs h, i, f, g, and c, where the values equal the current_local_solution values at the respective dofs. However, using the constrainig procedure, the equation for dof i is replaced with the condition that dof i be the mean value of dofs h and j (likewise for dof g). On first sight, this is no problem because these two dofs are fixed as well, and their mean value coincides with the value of dof i. But then, as PetscLinearSolver creates the submatrix, the matrix row and column corresponding to dof j are removed from the matrix, resulting in the equation that dof i be half the value of dof h. This of course results in a completely wrong solution. To resolve this problem, I thought of the following possibilities: Idea #1: Add constraining dofs (in this case, dof j) to the set of active dofs. The problem with this is that I currently don't assemble anything on element D, so that dof j doesn't have an equation. Idea #2: Ensure that refined elements whose neighbors are not refined are either completely contained in the active subdomain or not at all. I don't like this because it restricts the user's choice of the subdomain. Idea #3: Remove row j from the matrix, but not column j. This results in a nonquadratic matrix, namely an underdetermined system. I wonder what PETSc would do then. I don't think it will do what I would like it to do in this situation. (Jed?) Idea #4: Upon removing the columns of the matrix, automatically adjust the right hand side. I think this would actually be quite easy to do by the following procedure: 1. Remove the inactive rows of the matrix. 2. Let B denote the active columns of the matrix and C all the remaining (inactive) columns. 3. Subtract C*x from b (where b is the right hand side and x the solution vector). 4. Then solve with B as before. Idea #5: Follow Jed's prior objection that just leaving the inactive components of the solution vector unchanged makes the whole thing become a weird beast. For instance, this should be able to be achieved by subtracting an appropriate vector before solving and adding it again afterwards. Any thoughts? Well, the more I think about this, the more I find that #4 is the best choice. It can be done in PetscLinearSolver and will work quite generally (if I don't overlook something), so that the user wouldn't have to care about. Best Regars, Tim  Dr. Tim Kroeger CeVis  Center of Complex Systems and Visualization University of Bremen tim.kroeger@... Universitaetsallee 29 tim.kroeger@... D28359 Bremen Phone +494212187710 Germany Fax +494212184236 