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}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2

3

4

5

6
(6) 
7
(6) 
8
(5) 
9
(4) 
10

11

12
(1) 
13

14

15
(14) 
16
(2) 
17

18

19
(1) 
20
(1) 
21
(6) 
22
(10) 
23
(7) 
24

25

26
(2) 
27
(6) 
28
(10) 
29
(8) 
30
(2) 

From: Kirk, Benjamin \(JSCEG\) <benjamin.kirk1@na...>  20060606 18:14:31

My guess is the=20 #ifdef DEBUG ... #endif=20 Block in the dof_map.h header file at line 563. Try commenting that idfef out and see how it goes... I coded up the sort_sparsity_row to do some optimized sorting for a very special case, but wanted to make sure the algorithm *always* worked and introduced the #ifdef... Since noone has hit the ifdef it looks like it does work, however it makes me sleep better knowing it is in there ;) Still, try commenting it out and see what that does for you. Just don't check in the commented out version. Ben =20 Original Message From: libmeshdevelbounces@... [mailto:libmeshdevelbounces@...] On Behalf Of Roy Stogner Sent: Tuesday, June 06, 2006 12:28 PM To: libmeshdevel@... Subject: [Libmeshdevel] What's so slow with METHOD=3Ddbg? 1.) linking libmesh.so 2.) compute_sparsity_pattern() I don't know what's making these things take so long lately (was it a recent change in libMesh? in gcc's debugging options?), nor do I really expect anyone to fix them. But together they've added a minute to every one of the (too many) debug/compile/run cycles I've been doing recently, and I can't let that go by without griping...  Roy _______________________________________________ Libmeshdevel mailing list Libmeshdevel@... https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Roy Stogner <roystgnr@ic...>  20060606 17:28:34

1.) linking libmesh.so 2.) compute_sparsity_pattern() I don't know what's making these things take so long lately (was it a recent change in libMesh? in gcc's debugging options?), nor do I really expect anyone to fix them. But together they've added a minute to every one of the (too many) debug/compile/run cycles I've been doing recently, and I can't let that go by without griping...  Roy 
From: John Peterson <peterson@cf...>  20060606 05:54:22

Unknown, but they recently upgraded the mailing list management software. J Roy Stogner writes: > > I'm not sure what's going haywire with the mailing list, but I sent > this stuff like 36 hours ago! > > Hmmm... maybe I should say, "I sent this stuff on Sunday!", otherwise > my complaint won't make sense when it's finally received 36 hours from > now... >  > Roy > > On Sun, 4 Jun 2006, Roy Stogner wrote: > > > On Sun, 4 Jun 2006, vikramvgarg@... wrote: > > > >> Quoting Roy Stogner <roystgnr@...>: > >> > >>> On Sun, 4 Jun 2006, vikramvgarg@... wrote: > >>> > >>>> Ex 13 wont work with Re=0 unless the pressure terms are nonzero. > >>> > >>> Explain what you mean by "pressure terms are nonzero"? Do you mean > >>> that pinning a pressure node fixes things? Or do you mean that you've > >>> got Re attached to a pressure term?  that wouldn't be correct. > >> > >> I mean that if I solve just vector Laplacian u = 0 by turning the > >> appropriate K matrix entries to zero the I get the u = v = 0 solution as the > >> other day. If the Kpu Kpv etc terms are nonzero the solver works fine. > > > > Okay, then  the problem is just that you're turning off too much. > > The Reynolds number is a coefficient of the convection term and the > > corresponding Newton terms, but it doesn't scale the pressure term or > > the continuity equation. > > > >>> In the meantime, I'd be curious to know more about how this bug > >>> behaves. What happens if you set Re=0.0001, for example? Do the > >>> solutions at 0.001 and 0.0001 look essentially the same, like they > >>> should? > > > >> Re = 0.001 > >> Works fine > >> Re = 0.0001 > >> Works fine, solution similar to Re = 0.001 > >> Re = 0.00001 > >> [0]PETSC ERROR: Detected zero pivot in LU factorization! > >> Re = 0.00001 with zero pivot tolerance = 1.e30 > >> Works fine, correct solution > >> Re = 0 > >> Will not work even with zero pivot tolerance = 1.e50 > >> > >> It seems to be a solver issue. > > > > Okay, this just sounds like the unpinned pressure mode is screwing up > > your preconditioner. I didn't realize that was a Reynolds number > > dependent problem, but it is an expected problem. > > > > We probably ought to explicitly pin a pressure node in example 13, > > rather than passing the buck on to the linear solver. > > > >>>> The same is true for my steady state and transient codes. > >> > >> About matching those two, well it turns out that the velocity is extremely > >> transient initially and then quickly settles to a steady state, so by using a > >> very small timestep (0.001) for the first 25 steps and then switching to dt = > >> .1 I was able to get the correct steady state solution. > > > > What happens if dt is too large initially? This is odd; if you use > > theta=1, then as dt > infinity you should be solving the steady state > > problem. An implicit timestepping scheme shouldn't be so sensitive > > to dt. > >  > > Roy 
From: Roy Stogner <roystgnr@ic...>  20060606 05:35:43

I'm not sure what's going haywire with the mailing list, but I sent this stuff like 36 hours ago! Hmmm... maybe I should say, "I sent this stuff on Sunday!", otherwise my complaint won't make sense when it's finally received 36 hours from now...  Roy On Sun, 4 Jun 2006, Roy Stogner wrote: > On Sun, 4 Jun 2006, vikramvgarg@... wrote: > >> Quoting Roy Stogner <roystgnr@...>: >> >>> On Sun, 4 Jun 2006, vikramvgarg@... wrote: >>> >>>> Ex 13 wont work with Re=0 unless the pressure terms are nonzero. >>> >>> Explain what you mean by "pressure terms are nonzero"? Do you mean >>> that pinning a pressure node fixes things? Or do you mean that you've >>> got Re attached to a pressure term?  that wouldn't be correct. >> >> I mean that if I solve just vector Laplacian u = 0 by turning the >> appropriate K matrix entries to zero the I get the u = v = 0 solution as the >> other day. If the Kpu Kpv etc terms are nonzero the solver works fine. > > Okay, then  the problem is just that you're turning off too much. > The Reynolds number is a coefficient of the convection term and the > corresponding Newton terms, but it doesn't scale the pressure term or > the continuity equation. > >>> In the meantime, I'd be curious to know more about how this bug >>> behaves. What happens if you set Re=0.0001, for example? Do the >>> solutions at 0.001 and 0.0001 look essentially the same, like they >>> should? > >> Re = 0.001 >> Works fine >> Re = 0.0001 >> Works fine, solution similar to Re = 0.001 >> Re = 0.00001 >> [0]PETSC ERROR: Detected zero pivot in LU factorization! >> Re = 0.00001 with zero pivot tolerance = 1.e30 >> Works fine, correct solution >> Re = 0 >> Will not work even with zero pivot tolerance = 1.e50 >> >> It seems to be a solver issue. > > Okay, this just sounds like the unpinned pressure mode is screwing up > your preconditioner. I didn't realize that was a Reynolds number > dependent problem, but it is an expected problem. > > We probably ought to explicitly pin a pressure node in example 13, > rather than passing the buck on to the linear solver. > >>>> The same is true for my steady state and transient codes. >> >> About matching those two, well it turns out that the velocity is extremely >> transient initially and then quickly settles to a steady state, so by using a >> very small timestep (0.001) for the first 25 steps and then switching to dt = >> .1 I was able to get the correct steady state solution. > > What happens if dt is too large initially? This is odd; if you use > theta=1, then as dt > infinity you should be solving the steady state > problem. An implicit timestepping scheme shouldn't be so sensitive > to dt. >  > Roy > > > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel > 
From: Roy Stogner <roystgnr@ic...>  20060606 02:59:20

On Sun, 4 Jun 2006, vikramvgarg@... wrote: > Ex 13 wont work with Re=0 unless the pressure terms are nonzero. Explain what you mean by "pressure terms are nonzero"? Do you mean that pinning a pressure node fixes things? Or do you mean that you've got Re attached to a pressure term?  that wouldn't be correct. And I assume that by "won't work" you mean the same thing we were seeing with your code the other day  that the solution becomes u = v = 0? I do wonder if there's something incorrect in the ex13 NavierStokes formulation. I'm currently refactoring ex13 to use the "element_residual()" type implementation which we've been talking about putting in libMesh for years, and the bilinear form I saw didn't quite look right. I'm used to solving for deltau and getting rid of the pressure variable entirely with divfree elements, though, so I'd just assumed that the u^new solution and velocitypressure formulation had confused me. On the other hand, it's possible that you're just not turning off the right set of terms when you go to Re=0. You're getting rid of both the convection terms and their associated Newton terms, right? I'm going to copy this to libmeshdevel, in case Ben or John or someone wants to try switching ex13 to Stokes flow and see if your bug can be duplicated. In the meantime, I'd be curious to know more about how this bug behaves. What happens if you set Re=0.0001, for example? Do the solutions at 0.001 and 0.0001 look essentially the same, like they should? > The same is true for my steady state and transient codes. Well, you're basically building straight off of ex13 with more interesting boundary conditions, right? So that's not surprising. It was a good idea to go back to ex13 itself to check that.  Roy 
From: Roy Stogner <roystgnr@ic...>  20060606 02:28:23

On Sun, 4 Jun 2006, vikramvgarg@... wrote: > Quoting Roy Stogner <roystgnr@...>: > >> On Sun, 4 Jun 2006, vikramvgarg@... wrote: >> >>> Ex 13 wont work with Re=0 unless the pressure terms are nonzero. >> >> Explain what you mean by "pressure terms are nonzero"? Do you mean >> that pinning a pressure node fixes things? Or do you mean that you've >> got Re attached to a pressure term?  that wouldn't be correct. > > I mean that if I solve just vector Laplacian u = 0 by turning the > appropriate K matrix entries to zero the I get the u = v = 0 solution as the > other day. If the Kpu Kpv etc terms are nonzero the solver works fine. Okay, then  the problem is just that you're turning off too much. The Reynolds number is a coefficient of the convection term and the corresponding Newton terms, but it doesn't scale the pressure term or the continuity equation. >> In the meantime, I'd be curious to know more about how this bug >> behaves. What happens if you set Re=0.0001, for example? Do the >> solutions at 0.001 and 0.0001 look essentially the same, like they >> should? > Re = 0.001 > Works fine > Re = 0.0001 > Works fine, solution similar to Re = 0.001 > Re = 0.00001 > [0]PETSC ERROR: Detected zero pivot in LU factorization! > Re = 0.00001 with zero pivot tolerance = 1.e30 > Works fine, correct solution > Re = 0 > Will not work even with zero pivot tolerance = 1.e50 > > It seems to be a solver issue. Okay, this just sounds like the unpinned pressure mode is screwing up your preconditioner. I didn't realize that was a Reynolds number dependent problem, but it is an expected problem. We probably ought to explicitly pin a pressure node in example 13, rather than passing the buck on to the linear solver. >>> The same is true for my steady state and transient codes. > > About matching those two, well it turns out that the velocity is extremely > transient initially and then quickly settles to a steady state, so by using a > very small timestep (0.001) for the first 25 steps and then switching to dt = > .1 I was able to get the correct steady state solution. What happens if dt is too large initially? This is odd; if you use theta=1, then as dt > infinity you should be solving the steady state problem. An implicit timestepping scheme shouldn't be so sensitive to dt.  Roy 