Re: [Libmesh-devel] XDA Node/Element Numbering

[Derek G. <fri...@gm...>]

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) <
ben...@na...> wrote:

> On Nov 6, 2013, at 9:47 PM, "Derek Gaston" <fri...@gm...> 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
>
>