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}
(28) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3
(1) 
4

5

6

7

8
(2) 
9
(6) 
10
(2) 
11
(10) 
12
(5) 
13
(3) 
14

15

16
(7) 
17

18
(2) 
19
(5) 
20
(2) 
21

22

23
(3) 
24
(11) 
25

26
(1) 
27

28







From: Andrea Hawkins <andjhawkins@gm...>  20100224 18:34:58

> There are some nice options in there to plot the linear solver convergence and nonlinear solution update  it can be informative. Thanks for these! I did not realize they were there. (PETSc is so useful when you know what you're looking for!) Using these I was able to find my problem. This generalized alpha is a predictorcorrector method. At the predictor stage I had been updating "local" (ghosted solution values) without updating the normal solution, thus when I entered the newton update and was using the normal solution, it clearly was not doing what it needed to. Thank you both, Jed and Ben, for you thoughts! On to the next bug! =) Andrea > > Ben > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: Kirk, Benjamin (JSCEG311); libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 10:18:46 2010 > Subject: Re: [Libmeshusers] Time Stepping > > That wouldn't explain it working after restarts though, would it? > Because with a restart, I'm seeding the initial condition with the > previous solution. So, the linear solver should be using this as an > initial guess, correct? > > Thanks, > Andrea > > > > On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) > <benjamin.kirk1@...> wrote: >> Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. >> >> Obviously this could be horribly wrong as you converge nonlinearly... >> >> Ben >> >> >> >>  Original Message  >> From: Andrea Hawkins <andjhawkins@...> >> To: libmeshusers <libmeshusers@...> >> Sent: Wed Feb 24 09:59:14 2010 >> Subject: [Libmeshusers] Time Stepping >> >> Hello >> >> I am running a nonlinear timedependent simulation and am currently >> attempting to implement the generalized alpha time stepping algorithm. >> As default I use PETSc for my linear solves and updates, but this >> method requires I write my own newton update. >> >> I had been setting those options outside of the time loop, but found >> out that the PetscNonlinearSolver was getting cleared after every time >> step so moving that into the time loop solved that problem. However, >> I'm now seeing some very peculiar behavior... The first time step >> things go fine. The second time step, things also seem to go fine, >> however the newton solver actually ends up converging back to the same >> solution it started with so that the third time step starts with the >> same values as the second. I have actually gone into the newton solver >> and seen that the first newton steps leave the initial values but >> converge back. >> >> While this issue could be many things, I have double checked (at >> length) with people familiar with this algorithm that I'm at least >> attempting to implement the correct thing. >> >> Is there something else I should be concerned about getting reset >> every time step? Because when I run it for only one time step and then >> restart and repeat, I do not see this behavior. >> >> Thanks! >> Andrea >> >>  >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and finetune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intelswdev >> _______________________________________________ >> Libmeshusers mailing list >> Libmeshusers@... >> https://lists.sourceforge.net/lists/listinfo/libmeshusers >> > 
From: Jed Brown <jed@59...>  20100224 18:13:13

On Wed, 24 Feb 2010 10:15:21 0600, Andrea Hawkins <andjhawkins@...> wrote: > I am using the SNES, I just utilized the SNESLineSearchSet to set my own update. Okay, is this better than the standard one for your problem? > So, if I do a diff between the output after the final newton step in > the zeroth time step with the the output after the first newton step > of the 1st time step I get > > broglie $ diff step0 step1 > 19c19 > < total: nonzeros=32153, allocated nonzeros=33489 >  > > total: nonzeros=32153, allocated nonzeros=40509 > 24c24 > < total: nonzeros=32153, allocated nonzeros=38169 >  > > total: nonzeros=32153, allocated nonzeros=40509 > 27d26 > < This is odd. Do you intend for the sparsity pattern of the matrix to change? If it really shouldn't change, then try setting MAT_NEW_NONZERO_ALLOCATION_ERR and see what triggers the error. > That wouldn't explain it working after restarts though, would it? > Because with a restart, I'm seeding the initial condition with the > previous solution. So, the linear solver should be using this as an > initial guess, correct? Do you mean that you're calling SNESSolve with the current solution in X? That just specifies the first Newton iterate, the Krylov solve will still start with a zero initial guess. (As a general rule with Newton, if you know a better initial guess than 0 for the linear solve, then you should have evaluated the function there.) PETSc solvers should be completely configured before the first XXXSolve. Modification after this should only be done if your code is taking active control (i.e. checking how convergence is proceeding and changing tolerances/preconditioners/etc in some problemspecific way). Maybe if you describe all the ways you modify the SNES/KSP/PC after the first call to SNESSolve, I can guess what is going on. Jed 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20100224 16:23:06

Yeah, and also I didn't realize you were using snes. cat ~benkirk/codes/fins/trunk/examples/Make.common There are some nice options in there to plot the linear solver convergence and nonlinear solution update  it can be informative. Ben  Original Message  From: Andrea Hawkins <andjhawkins@...> To: Kirk, Benjamin (JSCEG311); libmeshusers <libmeshusers@...> Sent: Wed Feb 24 10:18:46 2010 Subject: Re: [Libmeshusers] Time Stepping That wouldn't explain it working after restarts though, would it? Because with a restart, I'm seeding the initial condition with the previous solution. So, the linear solver should be using this as an initial guess, correct? Thanks, Andrea On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: > Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. > > Obviously this could be horribly wrong as you converge nonlinearly... > > Ben > > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 09:59:14 2010 > Subject: [Libmeshusers] Time Stepping > > Hello > > I am running a nonlinear timedependent simulation and am currently > attempting to implement the generalized alpha time stepping algorithm. > As default I use PETSc for my linear solves and updates, but this > method requires I write my own newton update. > > I had been setting those options outside of the time loop, but found > out that the PetscNonlinearSolver was getting cleared after every time > step so moving that into the time loop solved that problem. However, > I'm now seeing some very peculiar behavior... The first time step > things go fine. The second time step, things also seem to go fine, > however the newton solver actually ends up converging back to the same > solution it started with so that the third time step starts with the > same values as the second. I have actually gone into the newton solver > and seen that the first newton steps leave the initial values but > converge back. > > While this issue could be many things, I have double checked (at > length) with people familiar with this algorithm that I'm at least > attempting to implement the correct thing. > > Is there something else I should be concerned about getting reset > every time step? Because when I run it for only one time step and then > restart and repeat, I do not see this behavior. > > Thanks! > Andrea > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 16:18:56

That wouldn't explain it working after restarts though, would it? Because with a restart, I'm seeding the initial condition with the previous solution. So, the linear solver should be using this as an initial guess, correct? Thanks, Andrea On Wed, Feb 24, 2010 at 10:14 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: > Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. > > Obviously this could be horribly wrong as you converge nonlinearly... > > Ben > > > >  Original Message  > From: Andrea Hawkins <andjhawkins@...> > To: libmeshusers <libmeshusers@...> > Sent: Wed Feb 24 09:59:14 2010 > Subject: [Libmeshusers] Time Stepping > > Hello > > I am running a nonlinear timedependent simulation and am currently > attempting to implement the generalized alpha time stepping algorithm. > As default I use PETSc for my linear solves and updates, but this > method requires I write my own newton update. > > I had been setting those options outside of the time loop, but found > out that the PetscNonlinearSolver was getting cleared after every time > step so moving that into the time loop solved that problem. However, > I'm now seeing some very peculiar behavior... The first time step > things go fine. The second time step, things also seem to go fine, > however the newton solver actually ends up converging back to the same > solution it started with so that the third time step starts with the > same values as the second. I have actually gone into the newton solver > and seen that the first newton steps leave the initial values but > converge back. > > While this issue could be many things, I have double checked (at > length) with people familiar with this algorithm that I'm at least > attempting to implement the correct thing. > > Is there something else I should be concerned about getting reset > every time step? Because when I run it for only one time step and then > restart and repeat, I do not see this behavior. > > Thanks! > Andrea > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20100224 16:15:43

Since you are rolling your own newton you might need to set the linear solver initial guess to 0 (the newton delta)  by default the linear implicit system uses the current solution as the krylov initial guess. Obviously this could be horribly wrong as you converge nonlinearly... Ben  Original Message  From: Andrea Hawkins <andjhawkins@...> To: libmeshusers <libmeshusers@...> Sent: Wed Feb 24 09:59:14 2010 Subject: [Libmeshusers] Time Stepping Hello I am running a nonlinear timedependent simulation and am currently attempting to implement the generalized alpha time stepping algorithm. As default I use PETSc for my linear solves and updates, but this method requires I write my own newton update. I had been setting those options outside of the time loop, but found out that the PetscNonlinearSolver was getting cleared after every time step so moving that into the time loop solved that problem. However, I'm now seeing some very peculiar behavior... The first time step things go fine. The second time step, things also seem to go fine, however the newton solver actually ends up converging back to the same solution it started with so that the third time step starts with the same values as the second. I have actually gone into the newton solver and seen that the first newton steps leave the initial values but converge back. While this issue could be many things, I have double checked (at length) with people familiar with this algorithm that I'm at least attempting to implement the correct thing. Is there something else I should be concerned about getting reset every time step? Because when I run it for only one time step and then restart and repeat, I do not see this behavior. Thanks! Andrea  Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and finetune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intelswdev _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 16:15:33

I am using the SNES, I just utilized the SNESLineSearchSet to set my own update. So, if I do a diff between the output after the final newton step in the zeroth time step with the the output after the first newton step of the 1st time step I get broglie $ diff step0 step1 19c19 < total: nonzeros=32153, allocated nonzeros=33489  > total: nonzeros=32153, allocated nonzeros=40509 24c24 < total: nonzeros=32153, allocated nonzeros=38169  > total: nonzeros=32153, allocated nonzeros=40509 27d26 < This wouldn't be causing the behavior would it? Thanks, Andrea On Wed, Feb 24, 2010 at 10:08 AM, Jed Brown <jed@...> wrote: > On Wed, 24 Feb 2010 09:59:14 0600, Andrea Hawkins <andjhawkins@...> wrote: >> Is there something else I should be concerned about getting reset >> every time step? > > Does anything change if you run with ksp_view (this will dump solver > details at the end of each solve). If you are using Newtonlike > algorithms, there is significant benefit to using SNES (through > libmesh's wrapper if you like) since this will give you significant > algorithmic flexibility and robustness improvements over rolling your > own Newton. > > Jed > 
From: Jed Brown <jed@59...>  20100224 16:05:39

On Wed, 24 Feb 2010 09:59:14 0600, Andrea Hawkins <andjhawkins@...> wrote: > Is there something else I should be concerned about getting reset > every time step? Does anything change if you run with ksp_view (this will dump solver details at the end of each solve). If you are using Newtonlike algorithms, there is significant benefit to using SNES (through libmesh's wrapper if you like) since this will give you significant algorithmic flexibility and robustness improvements over rolling your own Newton. Jed 
From: Andrea Hawkins <andjhawkins@gm...>  20100224 15:59:23

Hello I am running a nonlinear timedependent simulation and am currently attempting to implement the generalized alpha time stepping algorithm. As default I use PETSc for my linear solves and updates, but this method requires I write my own newton update. I had been setting those options outside of the time loop, but found out that the PetscNonlinearSolver was getting cleared after every time step so moving that into the time loop solved that problem. However, I'm now seeing some very peculiar behavior... The first time step things go fine. The second time step, things also seem to go fine, however the newton solver actually ends up converging back to the same solution it started with so that the third time step starts with the same values as the second. I have actually gone into the newton solver and seen that the first newton steps leave the initial values but converge back. While this issue could be many things, I have double checked (at length) with people familiar with this algorithm that I'm at least attempting to implement the correct thing. Is there something else I should be concerned about getting reset every time step? Because when I run it for only one time step and then restart and repeat, I do not see this behavior. Thanks! Andrea 
From: Roy Stogner <roystgnr@ic...>  20100224 02:20:21

On Tue, 23 Feb 2010, Yujie wrote: > Without mesh refinement, how to solve the linear equation with multiple > rhses. In current libmesh framework, > > one can use "equation_systems.get_system("system").solve()" to get the > solution with one rhs. > > In .solve(), there are assemble() and solver() functions. rhs can be > replaced in assemble(). However, which parameters need to be reinitialized > after finishing one rhs? Whether it is ok to call equation_systems.reinit() > to reinitialize necessary parameters for multiple rhses? Thanks a lot. Depends on how complicated your system is, but in general you shouldn't need to reset anything except (perhaps) the solution (which gets used as a starting guess in iterative solvers) before solving with a new right hand side. Take a look at the parameter sensitivity methods in implicit_system.C for some examples; since we use multiple solution and rhs vectors there we don't have to reinitialize anything at all.  Roy 
From: Yujie <recrusader@gm...>  20100224 02:19:16

Thanks, Roy. According to your advice. Maybe, it should be better to clear the solution vector after finishing the rhs. Regards, Yujie On Tue, Feb 23, 2010 at 7:48 PM, Roy Stogner <roystgnr@...>wrote: > > On Tue, 23 Feb 2010, Yujie wrote: > > Without mesh refinement, how to solve the linear equation with multiple >> rhses. In current libmesh framework, >> >> one can use "equation_systems.get_system("system").solve()" to get the >> solution with one rhs. >> >> In .solve(), there are assemble() and solver() functions. rhs can be >> replaced in assemble(). However, which parameters need to be reinitialized >> after finishing one rhs? Whether it is ok to call >> equation_systems.reinit() >> to reinitialize necessary parameters for multiple rhses? Thanks a lot. >> > > Depends on how complicated your system is, but in general you > shouldn't need to reset anything except (perhaps) the solution (which > gets used as a starting guess in iterative solvers) before solving > with a new right hand side. Take a look at the parameter sensitivity > methods in implicit_system.C for some examples; since we use multiple > solution and rhs vectors there we don't have to reinitialize anything > at all. >  > Roy > 
From: Yujie <recrusader@gm...>  20100224 01:14:23

Dear Libmesh Developers, Without mesh refinement, how to solve the linear equation with multiple rhses. In current libmesh framework, one can use "equation_systems.get_system("system").solve()" to get the solution with one rhs. In .solve(), there are assemble() and solver() functions. rhs can be replaced in assemble(). However, which parameters need to be reinitialized after finishing one rhs? Whether it is ok to call equation_systems.reinit() to reinitialize necessary parameters for multiple rhses? Thanks a lot. Regards, Yujie 