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 <bhatiama...@gmail.com> 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 <bhatiama...@gmail.com>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 >> >> > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
