On Fri, 8 Nov 2013, Kirk, Benjamin (JSC-EG311) wrote:
I maintain a lot of the complicating factors in the current format
are appropriate given its goals,
I didn't want to start a flamewar before (and also I've been wrecked
by illness and deadlines), but I mostly agree.
and I think your need
Excellent. I maintain a lot of the complicating factors in the current format
are appropriate given its goals, and I think your need will be better served
with this new approach.
-Ben
On Nov 7, 2013, at 6:08 PM, "Derek Gaston"
mailto:fried...@gmail.com>> wrote:
BTW - I'm a long way down thi
BTW - I'm a long way down this path now I am almost finished with
write(). I'll work on read() tonight...
Hopefully there will be a pull request in the morning...
Derek
On Thu, Nov 7, 2013 at 1:30 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> Sounds good. Feel free to
Sounds good. Feel free to grab anything useful from here:
https://github.com/libMesh/libmesh/tree/checkpoint
On Nov 7, 2013, at 2:26 PM, Derek Gaston
wrote:
> I'm thinking a new object: CheckpointIO
>
> So you do CheckpointIO.write()/read()
>
> Cody and I are starting on this now - I'll pro
I'm thinking a new object: CheckpointIO
So you do CheckpointIO.write()/read()
Cody and I are starting on this now - I'll provide a pull request once we
get a ways in so you can comment.
Derek
On Thu, Nov 7, 2013 at 12:27 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On No
On Nov 7, 2013, at 10:37 AM, Cody Permann
wrote:
> Yes I did, and we are still tweaking it even now. I just add the nodeset
> information a few days ago so lets figure out what we need in the current
> version before the next release!
If at all possible I'd like to treat the "unique ids" the
On Thu, Nov 7, 2013 at 8:36 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> On Nov 7, 2013, at 9:13 AM, Derek Gaston
> wrote:
>
> > 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
On Nov 7, 2013, at 9:43 AM, Derek Gaston
wrote:
> At this point I believe that the current goals of XDA (while really cool) are
> just not aligned with what I'm looking for. I literally just want a
> serialization of the Mesh and solution vectors. I want to be able to
> perfectly recreate
After thinking more about it - even getting the IDs right is not enough - I
need the nodes in the _nodes vector in Mesh to literally be inserted in the
exact same order (or else the solution vector passed to the ExodusIO will
be in a different order).
At this point I believe that the current goals
On Nov 7, 2013, at 9:13 AM, Derek Gaston
wrote:
> 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 everyth
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
On Nov 6, 2013, at 9:47 PM, "Derek Gaston" 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 n
I think we shouldn't be renumbering at all... we also want to read back
from the XDA file and get the exact same numbering we currently have...
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...
Derek
On We
On Nov 6, 2013, at 9:26 PM, "Derek Gaston" wrote:
> fix_broken_node_and_element_numbering() will destroy any non-contiguous,
> non-zero starting numbering - or any numbering where the numbering of nodes
> doesn't match the order they are added to the mesh. Note that last one: that
> is a seri
On Wed, Nov 6, 2013 at 6:36 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
> OK, so I've reminded myself of where this was left off - the parallel I/O
> for the equation systems is in place, while for the mesh it is not
> implemented yet. I'll review where things was left off, and
On Nov 6, 2013, at 8:54 PM, Cody Permann
wrote:
> Let us know where we can help. I was going to element IDs back to the
> connectivity arrays in XDA output and also add node IDs to that format for
> the first time too. That might be counter-productive if you are going
> another direction.
On Wed, Nov 6, 2013 at 6:36 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.k...@nasa.gov> wrote:
>
> On Nov 6, 2013, at 6:42 PM, "Kirk, Benjamin (JSC-EG311)" <
> benjamin.k...@nasa.gov>
> wrote:
>
> >>
> >> Unfortunately this has thrown an enormous monkey wrench into my current
> project (doing perfec
Sure - I understand. But a specialization for SerialMesh would make a lot of
sense in this case - saving a ton of parallel communication (and making it
possible to produce the exact same XDA file on one processor or thousands)
Derek
Sent from my iPhone
> On Nov 6, 2013, at 6:51 PM, "Kirk, Ben
On Nov 6, 2013, at 5:59 PM, Derek Gaston
wrote:
> Here's another issue: Why are we doing so much parallel communication of
> meshes in the case of Serial mesh? Why doesn't processor zero just go
> through and write the mesh out exactly as it is to XDA? Instead - there is a
> complicated rou
On Nov 6, 2013, at 6:42 PM, "Kirk, Benjamin (JSC-EG311)"
wrote:
>>
>> Unfortunately this has thrown an enormous monkey wrench into my current
>> project (doing perfect restart in MOOSE). I thought I was 99% done (it all
>> works in serial with compact meshes
On Nov 6, 2013, at 5:59 PM, "Derek Gaston" wrote:
> Is it time to just have a design discussion and lay out a new format all
> together?
No issue there - that's part of why I was asking if there is an obvious way to
extend an exodus file to contain the refinement hierarchy. But that's just one
I think I see - "globally consistent" ids are assigned then both the mesh
and solution vectors are written out together... then those ids are
"swapped" back.
Unfortunately - that "swap" is WRONG... and can in fact change the the ids
for your nodes and elements in the middle of your simulation just
I don't even understand how the current stuff works at all.
Since the node and element numbers change after running the mesh through an
XDA read and write - how do the dof ids match up with what was written out
with EquationSystems::write()??
Derek
On Wed, Nov 6, 2013 at 4:41 PM, Derek Gaston
On Nov 6, 2013, at 4:18 PM, Derek Gaston
wrote:
> Let me be a bit more clear:
>
> After writing an XDA file and reading it back in - I want _exactly_ the same
> Mesh structure that I had to start with same numbering, same everything…
That should be possible… The parallel format is loosel
For Parallel Mesh I was just thinking that each processor would write it's
own file... so that you could perfectly recreate the exact Mesh data
structure on read (not too mention being more amenable to parallel
filesystems like Panasas)
Derek
On Wed, Nov 6, 2013 at 4:33 PM, Kirk, Benjamin (JSC-E
Let me be a bit more clear:
After writing an XDA file and reading it back in - I want _exactly_ the
same Mesh structure that I had to start with same numbering, same
everything...
Derek
On Wed, Nov 6, 2013 at 4:16 PM, Derek Gaston wrote:
> As a follow on to this I think the XDA format is
As a follow on to this I think the XDA format is not currently done
properly.
It should go:
Meta Data
Nodes
Elements
BCs
Where the "Nodes" section has
node_id node_unique_id coord_x coord_y coord_z
That way you don't have to create "surrogate" nodes during read - you just
create the correct one
When you write and read an XDA file in parallel the node and element
numbering is changed.
This means that nodesets can't work through a "restart" in parallel... and
even worse if you are trying to "append" to the Exodus file it doesn't work
(because that Exodus file already has a different number
28 matches
Mail list logo
