On Fri, Oct 11, 2013 at 1:47 PM, roystgnr <notifications@github.com> wrote:

> In src/mesh/xdr_io.C:
>
> > @@ -41,6 +41,7 @@
> >  namespace libMesh
> >  {
> >
> > +//#define LIBMESH_USE_64BIT_XDR
>
> Hmm... xdr_id_type matching largest_id_type is definitely the way to
> start. But what I'd do is put those stored encoding sizes
>

One for each type?  So my less efficient version will look like this:

# assuming they are using libMesh defaults so largest_id_type = 4
4       # boundary_id_type
4       # dof_id_type
4       # unique_id_type (if this is turned off, it'll still get written
but won't participate in the size selection)
4       # processor_id_type
4       # subdomain_id_type

This is essentially what's happening right now anyway so now I'm just
making it explicit.  I'll get this all coded up and put out a pull request.
 If you want, I could optionally output unique_ids, we aren't really doing
this with any of the rest of the connectivity fields in practice, but it
wouldn't be terribly difficult to handle and detect, just one more field in
the header saying which fields are written.

in the new format version's header *anyway*, write them out with
> sizeof(xdr_id_type), when when reading them back in assert that they match
> sizeof(xdr_id_type). That will at least make it easier for people to figure
> the problem out once the inevitable "he wrote this file with 4 byte ints,
> but I'm configured to use 8 byte ints" or vice-versa occurs, and it'll mean
> that we can make the reader and writer code more flexible later without
> requiring another format change.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/libMesh/libmesh/pull/156/files#r6924926>
> .
>