Well that would give us the most efficient packing but would require a fair
amount of rework indeed with all of the chunked I/O.  Sounds like a good CS
student summer project!

Since I'm not too inclined to bite that off right now, how about I define
"xdr_id_type" to match "largest_id_type" and put in that single encoding
value in the header?  That'll allow those of us who are going to start
using unique_ids the ability to move to a 64-bit file encoding while
leaving everything else status quo for those using default libMesh
configuration options.  Once that's in place, it's just be plug'n'chug for
somebody who has a bit of free time to pack things tightly!  For the most
part, we are still using XDA format so we aren't too concerned about file
size just yet.

Cody

On Fri, Oct 11, 2013 at 1:17 PM, roystgnr <notifications@github.com> wrote:

> In src/mesh/xdr_io.C:
>
> > @@ -41,6 +41,7 @@
> >  namespace libMesh
> >  {
> >
> > +//#define LIBMESH_USE_64BIT_XDR
>
> My personal preference would be to add not just one "stored encoding size"
> to the header, but one per data type. Then we could actually store unpadded
> 4 byte dof ids, 2 byte subdomain ids, etc. even in cases which need an 8
> byte unique id. That's a significant bit of work, though.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/libMesh/libmesh/pull/156/files#r6924203>
> .
>