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}
(31) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(7) 
2

3

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

11

12
(23) 
13

14
(3) 
15
(15) 
16
(3) 
17
(4) 
18
(3) 
19
(1) 
20
(26) 
21
(5) 
22

23

24
(1) 
25
(9) 
26

27
(8) 
28
(12) 
29
(1) 
30
(4) 
31







From: Roy Stogner <roystgnr@ic...>  20130301 20:58:30

On Thu, 21 Feb 2013, Manav Bhatia wrote: > Upon further study, it seems like the elem_fixed_solution stores the > element solution in situations where the elem_solution may contain > the velocity or delta solution. Is this correct? Currently, yes.  Roy 
From: Manav Bhatia <bhatiamanav@gm...>  20130301 20:31:32

Hi, I have adapted the navier_system.C example to solve the Euler equations. I have tested it for a sample problem (flow through a channel without disturbances, so that the solution should remain the same for all time steps) without AMR, and things seem to work fine. So, if I initialize the solution vector to U0, it stays at U0 (with some changes down to machine epsilon during the solves). Note that the dU term for call to mass_residual is expected to be 0 (or small epsilons) at all times. However, when I turn on AMR by setting the max_adaptivesteps to 1, the code crashes. Upon looking into this further, I realized that the call to mass_residual has the elem_solution (implying dU) is actually set to U0. I looked into euler_solver.C and it seems like solution is set to old_elem_solution  theta_solution. For some reason, old_elem_solution (which should be U0, and was U0 without AMR) is now zero. Printing out the old_elem_solution prints a zero vector. So, somewhere between the first solution of the equations, followed by refinement, and then the next solution, the old_nonlinear_sol seems to being zeroed out. I have not made any changes to libMesh, and feel like have not make any modifications to the time for loop in the example. Interestingly enough, changing the value of max_adaptivesteps to 1 in the navier_system example does not create any problems. I am still trying to figure out the source of this problem, but am curious if someone may have any quick guesses. Thanks, Manav 
From: Manav Bhatia <bhatiamanav@gm...>  20130301 20:20:22

Hi, In order to fix this, I ended up adding the following change to UnsteadySolver::reinit(). Currently, it returns after resizing the vector. I copied the portion after the if block in UnsteadySolver::advance_timestep after the resizing part in reinit(). This forces it to copy the system solution vector to the old_nonlinear_solution and then localize it. However, the assumption is that the system solution vector has been prolonged to match the mesh size. Things seem to be working alright for now, but I would appreciate comments on this change. Thanks, Manav On Fri, Mar 1, 2013 at 1:53 PM, Manav Bhatia <bhatiamanav@...> wrote: > One more observation: > > UnsteadySolver inherits from TimeSolver, but both of them define a member > variable old_local_nonlinear_solution. > > Since the UnsteadySolver operates and resizes this vector, it may be best > to remove it from TimeSolver to avoid confusion. > > Manav > > > > On Fri, Mar 1, 2013 at 1:46 PM, Manav Bhatia <bhatiamanav@...>wrote: > >> Ok, so I looked at the code, and here is my assessment. >> >> >> When using AMR, following the refine_and_coarsen_elements the >> equation_systems.reinit is called. >> This prolongs the vectors of the system, and reinitializes the values >> (not just size) of the system vectors. However, it only resizes the >> old_local_solution_vector of the unsteady solver (line 73 in >> unsteady_solver.C). >> >> So, as a result following the equation system reinit after ARM, the >> system vectors have legitimate values, but the UnsteadySolver vectors have >> been zeroed out. Now, this vector does not get updated till the next call >> to advance_time (line 290 in fem_system.C), which happens only after the >> additional solve required (line 284 in fem_system_ex1.C). >> >> Options may be: >> >>  in UnsteadySolver, the reinit should also project the old vector to >> the new vector after the solve. >>  do not call the additional system.solve() between ARM and >> advance_timestep >>  somehow force the first_solve variable to be true after AMR, but this >> does not seem a good fix >> >> Any comments? >> >> Thanks, >> Manav >> >> >> >> On Fri, Mar 1, 2013 at 10:00 AM, Manav Bhatia <bhatiamanav@...>wrote: >> >>> Hi, >>> >>> I have adapted the navier_system.C example to solve the Euler >>> equations. I have tested it for a sample problem (flow through a channel >>> without disturbances, so that the solution should remain the same for all >>> time steps) without AMR, and things seem to work fine. So, if I initialize >>> the solution vector to U0, it stays at U0 (with some changes down to >>> machine epsilon during the solves). Note that the dU term for call to >>> mass_residual is expected to be 0 (or small epsilons) at all times. >>> >>> However, when I turn on AMR by setting the max_adaptivesteps to 1, >>> the code crashes. Upon looking into this further, I realized that the call >>> to mass_residual has the elem_solution (implying dU) is actually set to >>> U0. I looked into euler_solver.C and it seems like solution is set to >>> old_elem_solution  theta_solution. For some reason, old_elem_solution >>> (which should be U0, and was U0 without AMR) is now zero. Printing out the >>> old_elem_solution prints a zero vector. >>> >>> So, somewhere between the first solution of the equations, followed >>> by refinement, and then the next solution, the old_nonlinear_sol seems to >>> being zeroed out. I have not made any changes to libMesh, and feel like >>> have not make any modifications to the time for loop in the example. >>> >>> Interestingly enough, changing the value of max_adaptivesteps to 1 >>> in the navier_system example does not create any problems. >>> >>> I am still trying to figure out the source of this problem, but am >>> curious if someone may have any quick guesses. >>> >>> Thanks, >>> Manav >>> >>> >> > 
From: Manav Bhatia <bhatiamanav@gm...>  20130301 18:53:25

One more observation: UnsteadySolver inherits from TimeSolver, but both of them define a member variable old_local_nonlinear_solution. Since the UnsteadySolver operates and resizes this vector, it may be best to remove it from TimeSolver to avoid confusion. Manav On Fri, Mar 1, 2013 at 1:46 PM, Manav Bhatia <bhatiamanav@...> wrote: > Ok, so I looked at the code, and here is my assessment. > > > When using AMR, following the refine_and_coarsen_elements the > equation_systems.reinit is called. > This prolongs the vectors of the system, and reinitializes the values (not > just size) of the system vectors. However, it only resizes the > old_local_solution_vector of the unsteady solver (line 73 in > unsteady_solver.C). > > So, as a result following the equation system reinit after ARM, the system > vectors have legitimate values, but the UnsteadySolver vectors have been > zeroed out. Now, this vector does not get updated till the next call to > advance_time (line 290 in fem_system.C), which happens only after the > additional solve required (line 284 in fem_system_ex1.C). > > Options may be: > >  in UnsteadySolver, the reinit should also project the old vector to > the new vector after the solve. >  do not call the additional system.solve() between ARM and > advance_timestep >  somehow force the first_solve variable to be true after AMR, but this > does not seem a good fix > > Any comments? > > Thanks, > Manav > > > > On Fri, Mar 1, 2013 at 10:00 AM, Manav Bhatia <bhatiamanav@...>wrote: > >> Hi, >> >> I have adapted the navier_system.C example to solve the Euler >> equations. I have tested it for a sample problem (flow through a channel >> without disturbances, so that the solution should remain the same for all >> time steps) without AMR, and things seem to work fine. So, if I initialize >> the solution vector to U0, it stays at U0 (with some changes down to >> machine epsilon during the solves). Note that the dU term for call to >> mass_residual is expected to be 0 (or small epsilons) at all times. >> >> However, when I turn on AMR by setting the max_adaptivesteps to 1, >> the code crashes. Upon looking into this further, I realized that the call >> to mass_residual has the elem_solution (implying dU) is actually set to >> U0. I looked into euler_solver.C and it seems like solution is set to >> old_elem_solution  theta_solution. For some reason, old_elem_solution >> (which should be U0, and was U0 without AMR) is now zero. Printing out the >> old_elem_solution prints a zero vector. >> >> So, somewhere between the first solution of the equations, followed >> by refinement, and then the next solution, the old_nonlinear_sol seems to >> being zeroed out. I have not made any changes to libMesh, and feel like >> have not make any modifications to the time for loop in the example. >> >> Interestingly enough, changing the value of max_adaptivesteps to 1 in >> the navier_system example does not create any problems. >> >> I am still trying to figure out the source of this problem, but am >> curious if someone may have any quick guesses. >> >> Thanks, >> Manav >> >> > 
From: Manav Bhatia <bhatiamanav@gm...>  20130301 18:53:04

Ok, so I looked at the code, and here is my assessment. When using AMR, following the refine_and_coarsen_elements the equation_systems.reinit is called. This prolongs the vectors of the system, and reinitializes the values (not just size) of the system vectors. However, it only resizes the old_local_solution_vector of the unsteady solver (line 73 in unsteady_solver.C). So, as a result following the equation system reinit after ARM, the system vectors have legitimate values, but the UnsteadySolver vectors have been zeroed out. Now, this vector does not get updated till the next call to advance_time (line 290 in fem_system.C), which happens only after the additional solve required (line 284 in fem_system_ex1.C). Options may be:  in UnsteadySolver, the reinit should also project the old vector to the new vector after the solve.  do not call the additional system.solve() between ARM and advance_timestep  somehow force the first_solve variable to be true after AMR, but this does not seem a good fix Any comments? Thanks, Manav On Fri, Mar 1, 2013 at 10:00 AM, Manav Bhatia <bhatiamanav@...> wrote: > Hi, > > I have adapted the navier_system.C example to solve the Euler > equations. I have tested it for a sample problem (flow through a channel > without disturbances, so that the solution should remain the same for all > time steps) without AMR, and things seem to work fine. So, if I initialize > the solution vector to U0, it stays at U0 (with some changes down to > machine epsilon during the solves). Note that the dU term for call to > mass_residual is expected to be 0 (or small epsilons) at all times. > > However, when I turn on AMR by setting the max_adaptivesteps to 1, the > code crashes. Upon looking into this further, I realized that the call to > mass_residual has the elem_solution (implying dU) is actually set to U0. I > looked into euler_solver.C and it seems like solution is set to > old_elem_solution  theta_solution. For some reason, old_elem_solution > (which should be U0, and was U0 without AMR) is now zero. Printing out the > old_elem_solution prints a zero vector. > > So, somewhere between the first solution of the equations, followed by > refinement, and then the next solution, the old_nonlinear_sol seems to > being zeroed out. I have not made any changes to libMesh, and feel like > have not make any modifications to the time for loop in the example. > > Interestingly enough, changing the value of max_adaptivesteps to 1 in > the navier_system example does not create any problems. > > I am still trying to figure out the source of this problem, but am > curious if someone may have any quick guesses. > > Thanks, > Manav > > 
From: Manav Bhatia <bhatiamanav@gm...>  20130301 07:07:17

Thanks a lot for the response, Roy. I did study the code further, and was able to make some progress. I am currently debugging some AMR issues in my code. I think some clarity in the API would be helpful. I learnt the hard way since I assumed that my flux boundary conditions were supposed to go into side_constraint, only to realize that it was not going to get multiplied by dt unless it was in side_residual. Making the change did solve the problem, but there was a confusion about what was supposed to go into side_constraint vs side_residual. Maybe documenting it would be helpful. As a followup, when elem_residual is called, is it possible to get access to the du/dt term? I have one more question. (I had sent a separate email earlier this morning, but seems like I am having trouble with my emails and it got lost somewhere). So, here is the question: Lines 419 in newton_solver.cpp sets the steplength to 1.0, line 420 makes a call to line_search which returns the value of step length. However, there is no lvalue speficied to the call to line search, so that steplength remain 1.0. I think the call to line_search should be Real steplength = this>line_search(.....); Comment? Thanks, Manav On Thu, Feb 28, 2013 at 3:05 PM, Roy Stogner <roystgnr@...>wrote: > > On Thu, 21 Feb 2013, Manav Bhatia wrote: > > Upon further study, it seems like the elem_fixed_solution stores the >> element solution in situations where the elem_solution may contain >> the velocity or delta solution. Is this correct? >> > > Currently, yes. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20130301 01:54:12

On Thu, 28 Feb 2013, Manav Bhatia wrote: > I think some clarity in the API would be helpful. I learnt the hard way since I assumed that my > flux boundary conditions were supposed to go into side_constraint, only to realize that it was > not going to get multiplied by dt unless it was in side_residual. Making the change did solve > the problem, but there was a confusion about what was supposed to go into side_constraint vs > side_residual. Maybe documenting it would be helpful. See what you think about the updated diff_physics.h method comments in 96ca8ddf3208b29d20ba203750524aea3573f3be ? > As a followup, when elem_residual is called, is it possible to get access to the du/dt term? Right now, no. That's one of the other motivations for an API change.  Roy 