Definitely! Thanks,
-Ben On Jun 21, 2013, at 8:53 AM, "Manav Bhatia" <bhatiama...@gmail.com<mailto:bhatiama...@gmail.com>> 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 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 <royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>> 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
