On Fri, Jun 10, 2011 at 19:21, Roy Stogner wrote:
> It sounds as if we ought to allow a couple optional bool arguments to
> the PetscVector(Vec) constructor?
>
Yeah, and of course you could have a way to change them later.
> There's no way for that method to
> efficiently infer the state of a
On Fri, 10 Jun 2011, Cody Permann wrote:
> I just commited an app (r4583) to update subdomain, sideset, and
> nodeset IDs on existing meshes.
Thanks!
> By the way, I think there is a
> small corner case you are missing in the app you committed
> yesterday. On line 151 of meshbcid.C you are usi
On Fri, 10 Jun 2011, David Andrs wrote:
Roy Stogner wrote on 06/10/2011 10:11:16 AM:
> David, would you try adding this->close() before line 695 of
> petsc_vector.h and see if that solves the problem for you?
That fixed the issue with non-closed PetscVectors in our nonlinear system.
Than
Roy,
I just commited an app (r4583) to update subdomain, sideset, and nodeset IDs on
existing meshes. By the way, I think there is a small corner case you are
missing in the app you committed yesterday. On line 151 of meshbcid.C you are
using the "scalar" version of the boundary_id function.
Thanks very much, Jed.
It sounds as if we ought to allow a couple optional bool arguments to
the PetscVector(Vec) constructor? There's no way for that method to
efficiently infer the state of a Vec (you'd need all-to-all
communication equivalent to a redundant close() just to determine that
ther
Roy Stogner wrote on 06/10/2011 10:11:16 AM:
>
> On Fri, 10 Jun 2011, Derek Gaston wrote:
>
> > On Jun 10, 2011, at 9:35 AM, Roy Stogner wrote:
> >
> >> Could you identify where in your failure case the solution vector is
> >> getting left open?
> >
> > This happens during the call to update()
On Fri, Jun 10, 2011 at 17:56, Derek Gaston wrote:
> This happens during the call to update() in the Petsc callback to compute
> the residual (and other callbacks). It's not from user code at all. Petsc
> is actually giving us a vector that isn't closed.
This comes from an impedance mismatch
On Fri, 10 Jun 2011, Derek Gaston wrote:
> On Jun 10, 2011, at 9:35 AM, Roy Stogner wrote:
>
>> Could you identify where in your failure case the solution vector is
>> getting left open?
>
> This happens during the call to update() in the Petsc callback to
> compute the residual (and other callba
On Jun 10, 2011, at 9:35 AM, Roy Stogner wrote:
> Almost. This call is crucial if the solution vector is ghosted and
> not already closed. But it's also redundant global communication if
> the solution vector is already closed, which (without any special
> effort in user-level code) is the case
On Fri, 10 Jun 2011, Derek Gaston wrote:
I'm still doing testing on System::update() with the large systems
that are giving us problems. I haven't been able to isolate the
problem yet but I'm working on it.
Thanks!
Any chance I could get a look at the (tail of the) stack trace to
help?
On Fri, 10 Jun 2011, David Andrs wrote:
> So we bumped into another issue with the recent libMesh update. It
> seems that System::update() does not close() the solution vector any
> more, however this call is crucial if the solution vector is
> ghosted.
Almost. This call is crucial if the solut
I'm still doing testing on System::update() with the large systems that are
giving us problems. I haven't been able to isolate the problem yet but I'm
working on it. I am thinking that the issue might actually be elsewhere but
it's causing the failure in System::update() I'm somewhat h
Hi!
So we bumped into another issue with the recent libMesh update. It seems
that System::update() does not close() the solution vector any more,
however this call is crucial if the solution vector is ghosted.
Attached is the patch that fixes it.
Thanks,
--
David
0001-Ghosted-solution-has-t
13 matches
Mail list logo
