I understand what you're saying - but the current format is so very close
to what I actually currently need. If it had element and node ids in it
and tried to restore those ids when you loaded the file I believe that it
would do everything I currently need it to do.
Can we do something simple in the interim like a configure option to write
IDs to the XDA file?
After we have that working we can take a look at doing something better.
For instance, I currently have these patches that add Silo (
https://wci.llnl.gov/codes/silo/ ) support to libMesh (from a developer at
Livermore)... maybe we can take a look at what he's done and improve upon
it and make it our official format (one nice thing is that Paraview and
ViSit actually read that format - so you could actually look at the files
you dump out... and it natively supports AMR).
But - I really just need a quick fix for now to allow progress to continue
on my current task...
Derek
On Thu, Nov 7, 2013 at 5:40 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Nov 6, 2013, at 9:47 PM, "Derek Gaston" <fried...@gmail.com> wrote:
>
> > I think I may be missing the reason why we are renumbering. To me, I
> just want a direct representation of the current mesh in XDA form...
>
> For the serialized solution XDA, it is all about M->N restarts. Forget the
> mesh for the moment, its not relevant to this case.
>
> Building a cube on 1 or 10 processors, has historically produced a
> different element/node ordering in libMesh. Same thing will happen if you
> invoke different partitioners on the same mesh.
> Same thing will happen if you build a square with 4 elements vs. building
> one and refining it once.
>
> We need a way to restart the same solution on topologically the same mesh
> regardless of the ordering, and the serialized solution format is designed
> to handle that need.
>
> So at the moment the parallel solution I/O stuff proceeds from that
> history. I agree if we are limiting the parallel restart capability to (1)
> always require an associated mesh and (2) only work in the M->M case, we
> can likely remove the reordering.
>
> The mesh is different - we do not reorder it explicitly, but we write the
> elements by level so that can change the "natural" ordering with
> refinement. This was done as a logical way to get the refinement tree out
> and also not require additional IDs. As I mentioned yesterday for the
> parallel mesh case I expect we'll need Ids in any case. I'm also open to
> constructing some kind of integer graph instead to represent the refinement
> hierarchy, but I don't clearly see what that looks like so we need to think
> about it. It may be as easy as the current parent index bit, but read after
> the elements...
>
> -Ben
>
>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
