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 <bhatiama...@gmail.com> 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 <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
