Re: [Libmesh-users] Initializing ParallelMesh

2013-06-21 Thread Roy Stogner
On Fri, 21 Jun 2013, Manav Bhatia wrote: I think I got this to work !!   So, now my grid with 40million cells gets read and the system gets initialized for analysis in less than a minute (down from ~35 minutes), and the memory footprint per node (with 16 processors) is down from 35 GB to 17 G

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-21 Thread Kirk, Benjamin (JSC-EG311)
Definitely! Thanks, -Ben On Jun 21, 2013, at 8:53 AM, "Manav Bhatia" mailto:[email protected]>> wrote: I think I got this to work !! So, now my grid with 40million cells gets read and the system gets initialized for analysis in less than a minute (down from ~35 minutes), and the memory

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-21 Thread Manav Bhatia
I think I got this to work !! So, now my grid with 40million cells gets read and the system gets initialized for analysis in less than a minute (down from ~35 minutes), and the memory footprint per node (with 16 processors) is down from 35 GB to 17 GB. So far, I had been using a SerialMesh with mu

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-19 Thread Roy Stogner
On Wed, 19 Jun 2013, Manav Bhatia wrote:    I am tripping the assert on line 771 of parallel_mesh.C:   libmesh_assert  ( !obj || procid == min_procid );      It is likely that I have a bug in my initialization, but I wanted to see if you had any quick thoughts on this error. "quick" is right

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-19 Thread Kirk, Benjamin (JSC-EG311)
That would definitely be helpful. Send it to the list but to Roy and me directly too. I will be traveling a lot for a few days so I am not sure when I can get to it, but I would like to help make sure you get going... -Ben On Jun 19, 2013, at 5:46 PM, "ng a Bhatia" wrote: > Hi, > > If thi

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-19 Thread Manav Bhatia
Hi, If this is helpful, I prepared a small example that mimics what I am trying to do, and trips the same exception. Any insight would be appreciated. Thanks, Manav On Wed, Jun 19, 2013 at 9:28 AM, Manav Bhatia wrote: > As an additional piece of info, this is being thrown when the met

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-19 Thread Manav Bhatia
As an additional piece of info, this is being thrown when the method libmesh_assert_valid_parallel_object_ids is being called for the nodes. I am wondering if this assert for my case needs to be true. Since I have partitioned elements, some nodes will be duplicated between processors. So, the min_

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-19 Thread Manav Bhatia
Hi Roy, I followed the procedure as discussed earlier to initialize ParallelMesh. Elements are partitioned and all relevant nodes are added to each processor with the ids of the elements and nodes set before addition. I am tripping the assert on line 771 of parallel_mesh.C: libmesh_assert

Re: [Libmesh-users] Initializing ParallelMesh

2013-06-06 Thread Roy Stogner
On Thu, 6 Jun 2013, Manav Bhatia wrote: >I am curious if there is an advisable strategy to add nodes and > elements to the ParallelMesh? Usually what we do in mesh refinement is give each processor "ownership" of dof ids which are equal to the processor id modulo n_processors+1. That way, n

[Libmesh-users] Initializing ParallelMesh

2013-06-06 Thread Manav Bhatia
Hi, I am curious if there is an advisable strategy to add nodes and elements to the ParallelMesh? If an initial approximate mesh partition is available from a space-filling algorithm, then is it OK to add the partitioned nodes to the ParallelMesh on its respective processor? Following thi