Is there any "close all" call?
On Fri, Feb 22, 2019 at 5:03 PM John Peterson <jwpeter...@gmail.com> wrote:
>
>
> On Fri, Feb 22, 2019 at 1:53 PM Renato Poli <rebp...@gmail.com> wrote:
>
>> Hi John
>>
>> Thanks for the reply.
>> It seems that I moved one small step forward.
>> I added the coupling_functor as you advised - following miscellaneous_ex9.
>> This way, I succeeded to solve the first timestep.
>> I found out I needed to reinit the equation_systems to get the coupling
>> updated.
>>
>> However, now I got stuck in the second timestep, as the
>> equation_systems.reinit() fails.
>> See below.
>> Why whould a v.closed() fail?
>> It doesn't make sense to me.
>> (I am running in a single processor...)
>>
>
> Even on one processor, we keep track of the closed/not closed state of
> vectors and check it before doing certain operations. Without line numbers
> in your stack trace, it's difficult to say exactly where the crash is
> coming from, but it's possible it's the following lines in petsc_vector.C:
>
> // FIXME: Workaround for a strange bug at large-scale.
> // If we have ghosting, PETSc lets us just copy the solution, and
> // doing so avoids a segfault?
> if (v_local_in.type() == GHOSTED &&
> this->type() == PARALLEL)
> {
> v_local_in = *this;
> return;
> }
>
> This would mean that current_local_solution is not closed for some reason,
> but that's likely a bug in libmesh that we just haven't encountered because
> we haven't done what you are trying to do before...
>
> --
> John
>
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
