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 multithreading for matrix/vector assembly. Life is good again.. !!
I think this should work for any exodusII file. I implemented this as a read_parallel() method in the ExodusII_IO API, but it uses a few nemesis calls to work. I will test it out a little more, and send a patch/pull request out if others are interested. Thanks, Manav On Thu, Jun 20, 2013 at 2:33 AM, Roy Stogner <[email protected]>wrote: > > 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 - I'm on vacation and way behind on things. > > IIRC at this point in the code you're expected to have consistent > processor id labeling of your nodes. If you have to add > subpartition-boundary nodes on multiple processors, then you need to > determine which processor is to own that node. There's some code in > the MeshRefinement/ElemRefinement paths to handle this in the case of > element subdivision; you might be able to find that and repurpose it. > --- > Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
