Just to close the conversation:
My objective here is to map values from one mesh to another.
Does libMesh offer convenient tools for that?
I am manually L2 mapping on element basis.
Any smarter suggestion?
On Sat, May 4, 2019 at 9:36 PM Alexander Lindsay <alexlindsay...@gmail.com>
wrote:
> Whether you’re reading in from an exodus file doesn’t matter. After
> reading, the mesh will delete remote non-ghosted elements if you’re using a
> DistributedMesh. However, you’re using the Mesh class which inherits from
> ReplicatedMesh unless you passed the —enable-parmesh flag during configure.
>
> Presuming you did not pass that flag, then the active elements should be
> the same across processes to the best of my knowledge.
>
> On May 4, 2019, at 2:17 PM, Renato Poli <rebp...@gmail.com> wrote:
>
> 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
