[MOAB-dev] moab file format and solution in time

[Tim Tautges]

Handling time-dependent data is on my radar, though I'm not sure yet when it'll happen.  The general design I have in 
mind would be to write the field data as indexed tag data, where a given tag could have a distinct value for each index 
and a tag handle/index value stored similarly to the way a dense tag is stored now.  This would allow the actual time 
values to be decoupled from the fields indexed to that time field, and would allow different fields to be indexed with 
different time or other series.  The field data for a given tag at a given time would be contiguous in memory for a 
contiguous series of entity handles.  The hdf5 and maybe a few other writers would be modified to allow writing of new 
tag data, and we'd probably also want the ability to deallocate space for older indices/time steps for one or more tags.

Of course, this design is just vapor at this point, and Jason hasn't weighed in on it.  OTOH, I've thought about this 
issue almost since we started MOAB in '01, and I think it would fit nicely into the current data model.

- tim

Jed Brown wrote:
> Lukasz Kaczmarczyk wrote:
>> Hello,
>>
>> I solving time dependent problems, each time when I store data I save
>> mesh coordinates and connectivity. Very often for each time step I
>> have the same mesh with different tags data.
> 
> My solution to this (somewhat in flux, I still haven't finished the
> VisIt plugin) is that I don't put transient data (like model state) in
> tags and don't necessarily use the coordinates that MOAB stores for
> nodes.  Thus I'm using the mesh to handle topology and relations, but
> not really geometry and definitely not field values.  I write my own
> HDF5 file with the name of relevant tags and external links to iMesh
> output.  If tag metadata changes frequently, I'll create a new tag each
> time.  When appropriate, this metadata can be flushed, but the write
> interval is decoupled from my time-steps and need to write model state.
> If mesh topology is changing over time, it should be possible to
> compress these changes, but I think it would be a colossal waste of time
> in almost all applications because the mesh doesn't change every time
> step and the mesh rarely requires more storage than a few steps of model
> state.
> 
> Jed
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706