On Wed, Apr 10, 2013 at 12:18 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@nasa.gov> wrote:
I'm reviewing the code now…  Is there a restart file with this case, or is it a fresh start?

Fresh Start
If the latter, you may be able to turn libMesh::MeshCommunication::find_global_indices() into a no-op - just with a naked 'return;' at the top.

OOoooooh!  Really?  That sounds perfect!  I'll try it!
The goal of a partition-agnistoc node ordering is still something I'd like to achieve, but the current implementation has been the source of way too much woe.  I'll revisit the discussion on the list from a few years ago and figure out what a proper path forward should be.

Yeah - we know it causes problems with restart with solid mechanics for instance.... because we might actually have some "penetration" of one part of the mesh into another part of the mesh in a restart file... which causes the global_indices to get assigned differently from how they were assigned at the beginning of the simulation.  That's a nasty problem.
Is this mesh something I can get my hands on down the road for testing?

Hmmm - I might be able to send it to you down the road.  I'd have to double check on that.  It's actually not all that interesting though.  A pretty good approximation can be built from:

MeshTools::Generation::build_cube(mesh, 60, 256, 60, 0, 1, 0, 4, 0, 1);

It is being read in with the Exodus reader though.... and it does have quite a few subdomains (I don't know if that matters).

Thanks for looking at this!