I'm just reading in from a Exodus file.
That would be a replicated mesh, right?
==== CODE
libMesh::Mesh lm_mesh(init.comm());
lm_mesh.read( exofn );
On Sat, May 4, 2019 at 5:10 PM Alexander Lindsay <alexlindsay...@gmail.com>
wrote:
> Are you using a replicated or a distributed mesh? A distributed mesh will
> not have the same active elements.
>
> > On May 4, 2019, at 1:52 PM, Renato Poli <rebp...@gmail.com> wrote:
> >
> > Hi Roy
> >
> > I found what is breaking the flow.
> > Please consider the code below.
> >
> > I thought the "active_elements" were the same across the processors. It
> > seems that is not the case?
> > Then the point_locator (which is a collective task - right?) breaks sync
> > across processors.
> >
> > My code intends to map values from one mesh to the other.
> > What is the best construction for that?
> > Should I use "elements_begin/end" iterator instead?
> >
> > === CODE
> > MBcit el = mesh.active_elements_begin();
> > MBcit end_el = mesh.active_elements_end();
> > for ( ; el != end_el; ++el) {
> > ...
> > UniquePtr<PointLocatorBase> plocator = mesh.sub_point_locator();
> > elem = (*plocator)( pt );
> > ...
> > }
> >
> >
> >> On Fri, May 3, 2019 at 9:30 PM Renato Poli <rebp...@gmail.com> wrote:
> >>
> >> Thanks.
> >>
> >> Should I call "parallel_object_only()" throughout the code to check when
> >> it lost sync?
> >> Any smarter way to do that?
> >> What GDB can do for me?
> >> Parallel debugging is really something new to me...
> >>
> >> On Fri, May 3, 2019 at 7:34 PM Stogner, Roy H <royst...@ices.utexas.edu
> >
> >> wrote:
> >>
> >>>
> >>>> On Fri, 3 May 2019, Renato Poli wrote:
> >>>>
> >>>> I see a number of error messages, as below.
> >>>> I am struggling to understand what they mean and how to move forward.
> >>>> It is related to manually setting a system solution and closing the
> >>>> "solution" vector afterwards.
> >>>> Any idea?
> >>>>
> >>>> Assertion
> >>>>
> >>>
> `(this->comm()).verify(std::string("./include/libmesh/petsc_vector.h").size())'
> >>>> failed.
> >>>> Assertion
> >>>> `(this->comm()).verify(std::string("src/mesh/mesh_base.C").size())'
> >>> failed.
> >>>> [Assertion
> >>>>
> >>>
> `(this->comm()).verify(std::string("./include/libmesh/petsc_vector.h").size())'
> >>>> failed.
> >>>> [2] Assertion
> >>>>
> >>>
> `(this->comm()).verify(std::string("./include/libmesh/petsc_vector.h").size())'
> >>>> failed.[0] ./include/libmesh/petsc_vector.h, line 812, compiled Feb 22
> >>> 2019
> >>>> at 17:56:59
> >>>> 1] src/mesh/mesh_base.C, line 511, compiled Feb 22 2019 at 17:55:09
> >>>> ./include/libmesh/petsc_vector.h, line 812, compiled Feb 22 2019 at
> >>> 17:56:59
> >>>> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
> >>>> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 1
> >>>> application called MPI_Abort(MPI_COMM_WORLD, 1) - process 2
> >>>>
> >>>> Thanks,
> >>>> Renato
> >>>
> >>> You're running in parallel, but your different processors have gotten
> >>> out of sync. At least 1 is at mesh_base.C line 511, and at least 2 or
> >>> 3 are at petsc_vector.h 812. Are you not calling PetscVector::close()
> >>> on every processor, perhaps? Then the missing processor would
> >>> continue to whatever the next parallel-only operation is and the
> >>> dbg/devel mode check for synchronization would fail.
> >>> ---
> >>> Roy
> >>>
> >>
> >
> > _______________________________________________
> > Libmesh-users mailing list
> > Libmesh-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
