Appending a bug report from the web tracker; I think I'm not the only one that prefers to worry about this stuff in email?
The _next_free_unpartitioned_elem_id code is a consequence of ParallelMesh: because each processor can have the need to add nodes that no other processor can see, but we want those nodes to have unique ids just the same, we use modular arithmetic to decide what new IDs to give everything. With N CPUs we work mod N+1, so that for instance CPU 0 can add elements 0,5,10,etc. while CPU2 adds 2,7,12... and any elements added to all processors at once become elements 4,9,14, and so on. This should temporarily give you some very messy and sparse numbering, but MeshBase::prepare_for_use() then renumbers everything nicely to give continuous ranges on each processor. Not sure how this is causing a bug yet, though. For one thing, we don't do anything that complicated on SerialMesh. I'm busy at a conference then on vacation this week; could anyone with more Exodus experience see if they can replicate this bug? --- Roy ---------- Forwarded message ---------- Date: Wed, 27 Jan 2010 18:18:30 +0000 From: SourceForge.net <[email protected]> To: [email protected] Subject: [Libmesh-devel] [ libmesh-Bugs-2941168 ] _next_free_unpartitioned_elem_id initialization problem Bugs item #2941168, was opened at 2010-01-27 18:18 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=530254&aid=2941168&group_id=71130 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: _next_free_unpartitioned_elem_id initialization problem Initial Comment: When calling addelem on an unpartitioned element, the element id is set to _next_free_unpartitioned_elem_id which is initialized to the size of the communicator. This creates a problem for some functions in libmesh that assume the first element id is 0. For instance, the following code seg faults in ExodusII_IO::write: ::Mesh libMesh ( 3 ); ::ExodusII_IO io ( libMesh ); io.verbose ( true ); io.read ( "block.e" ); io.write ( "out.e" ); I have attached block.e for verification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=530254&aid=2941168&group_id=71130 ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
