Roy, Ben, others,
I've nearly finished my implementation of the DOF object unique id and
updated the PR.
https://github.com/libMesh/libmesh/pull/133
I believe I have addressed all of John and Roy's comments in this branch.
I'm going with changing the actual packed size of the element at configure
time so there should be no impacts if you don't enable this feature. John
and I tested this PR on both MPICH2 and OpenMPI stacks with the 8-byte
unique-ids and everything is working just fine. I plan to do some runs on
our cluster this afternoon so I'll be testing with MVAPICH as well.
There are two remaining tasks left to complete. The first piece is the
parallel_node communication. I've been focusing on the elements so I simply
missed this piece. The second piece is writing out the new field in the XDR
file. I'm not sure of how things have been done in the past with this
format so I'll toss out what I'm thinking and seek comments from the rest
of you.
I propose raising the file format version number and ALWAYS writing the new
field under this new version number whether libMesh is configured with
--enable-unique-id or not. We'll simply ignore the value if it's not
configured.
One thing I'm going to look for is the impact in memory usage with this
extra id turned on. Right now our parallel_elems typically occupy 40 bytes
in the packed data structure (header_size=10 * largest_id_type=4). With
the new id turned on and defaulting to 8 bytes this will jump to 88 bytes
(header_size=11 * largest_id_type=8). When the data is in memory it
certainly won't double the size of the structure. It should no more than
15 bytes in a worst case scenario and most likely just 8 (data alignment
issues). I suppose there are several ways we could try to reduce the
impact of this larger number in the packed structure. We could potentially
split the representation of the 8 byte number into two 4 byte numbers to
keep things lean. Also we could experiment with defaulting the unique id
to 4 bytes. I'll look at this if it's necessary.
I plan to run some large simulations today with adaptivity to see if I can
break the 4 byte limit. This theoretically should be possible with a large
parallel run with plenty of adaptivity. I would like to know where this
line is at. Additionally I'll be running our memory logger utility to
study the impacts of the extra struct size.
Finally, back to the XDR issue. If I'm going to be making a change to the
format, I'd like to go ahead and get the "block/sideset/nodeset" names
written to the file as well. This will lead to less version specific logic.
Comments?
Thanks,
Cody
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
