[Paraview] [Xdmf] Xdmf time series loads as Multi-block Dataset (UNCLASSIFIED)

[Eric E. Monson]

Hey Guys,

Thanks for the fixes, Jerry! It's working for most of my cases now  
(temporal collections of Polyvertex and Polygon grids). Also, for the  
first time, I can now load a saved state file in Python and do an  
animation with Xdmf files! I don't know if this got fixed with these  
recent changes, but with older versions of the reader I was never able  
to do that.

The only variant that is not bringing in data correctly is when I have  
a temporal collection which contains a 3dCoRecMesh grid at each time  
point. If I can't find a problem with my files in the next day or two,  
I'll try to cook up a small example that reproduces the behavior.

Thanks again,
-Eric


On Aug 18, 2008, at 4:13 PM, Jerry Clarke wrote:

> OK, the reader now produces uniform grids for temporal collections.
> I'm still testing but I've checked in the new version.
> Please give it a try on a variety of cases.
>
> Thanks
> Jerry
>
>
> John Biddiscombe wrote:
>> Further to my email the other day. Putting the commented line back  
>> in, did 'appear' to fix my temporal problem, but on closer  
>> inspection, although the time steps were correct, the data inside  
>> them was missing. Inspector showed no cells, points etc.
>> I reverted my own copy back a couple of revisions so that I could  
>> work with my own data. I await further developments, but am  
>> available (this week) for help/testing if need be
>> cheers
>> JB
>>> Classification:  UNCLASSIFIED Caveats: NONE
>>>
>>> All,
>>>
>>> I was out all of last week so I'm in catch up mode ....
>>>
>>> I was making significant changes to the XDMF reader and they are not
>>> finished yet. I checked in the changes that made the spatial  
>>> collection
>>> of temporal collections work. The issue was that the reader was  
>>> assuming
>>> that a temporal collection was at the first level (which may be  
>>> the most
>>> common case).
>>>
>>> As I recall (it will take me a few hours to get back into the  
>>> code) the changes that I made now treat spatial and temporal  
>>> collections similarly
>>> no matter the level. There's an internal flag to mark the temporal
>>> collections.
>>> That's why there is a big multiblock dataset for temporal  
>>> collections.
>>>
>>> The code to now make the output of a temporal collection the same  
>>> type
>>> as the children (and not a multiblock) is not yet working.  
>>> Hopefully I
>>> can get back to it today after fighting some other fires.
>>>
>>> The main problem I was dealing with (other than the above temporal
>>> collection
>>> multiblock issue) was getting the reader to work correctly in  
>>> parallel
>>> when
>>> the collection was not at the top level, i.e. not duplicating reads.
>>>
>>> Jerry Clarke
>>>
>>> -----Original Message-----
>>> From: xdmf-bounces at lists.kitware.com
>>> [mailto:xdmf-bounces at lists.kitware.com] On Behalf Of John  
>>> Biddiscombe
>>> Sent: Thursday, August 14, 2008 2:40 PM
>>> To: Eric E. Monson
>>> Cc: Renato N. Elias; xdmf at lists.kitware.com; ParaView List
>>> Subject: Re: [Xdmf] Xdmf time series loads as Multi-block Dataset
>>>
>>> at 1390 of xdmf reader
>>>        // we will not output a TemporalDataset, but use this as a  
>>> flag
>>> for later
>>>        // Jerry Change Me
>>>        sub->vtkType = VTK_TEMPORAL_DATA_SET; the sub->vtkType line  
>>> was
>>> commented out. Putting it back in fixes my problem, but could Renato
>>> send me a small example of (or link to) his grid of spatial/temporal
>>> mixmatch combination stuff so I can test the other kind. If large,  
>>> email
>>> me off lists for ftp info.
>>>
>>> thanks
>>>
>>> JB
>>>
>>>
>>>
>>>    Eric
>>>        I just tried xdmf for the first time in a couple of weeks an
>>> yes. It's     completely stuffed. I get a multiblock dataset with  
>>> 800 blocks,
>>> each     being one timestep - instead of a single (or possibly
>>> multi-block)     dataset with time varying stuff.
>>>        I Can see looking at Jerry's changes on immediate probable
>>> cause, but     I'd better read through the email he sent a few  
>>> days/week back
>>> and     review the changes. I see what Jerry has tried to do -  
>>> create a     multiblock xdmf structure and just fetch the correct  
>>> grid when
>>> you     request a timestep - thus giving us what we want. But  
>>> there's a
>>> flaw in     the logic when the actual output dataset is generated  
>>> - so that
>>> it     creates a multiblock one instead of the type givenm by the  
>>> Nth
>>> (=time)     dataset inside it when we are fetching a time step  
>>> which is not
>>> composite.
>>>        I need this to work, so I'll be looking at it soon. Ig Jerry
>>> reads this     before I fix it, then feel free to step in with the  
>>> correct
>>> patch :)
>>>        JB
>>>             Hey all,
>>>               Maybe I'm behind on my Xdmf XML format again, but my
>>> files that a          month or two ago loaded a time series of  
>>> unstructured
>>> grids now loads          into ParaView CVS as a Multi-block  
>>> Dataset with one
>>> block for each          time step at each time point.
>>>               Let's say I have 1200 Polyvertex time steps in my  
>>> file.
>>> I can (slowly)          step through the animation of my grid, but  
>>> at each time
>>> point the          progress bar is cycling through a bunch of  
>>> work, and
>>> each time point          lists (in the Information tab Data  
>>> Hierarchy pane) a
>>> Multi-block          Dataset made up of 1200 Unstructured Grids.  
>>> Clicking on
>>> each of these          blocks reveals that only the "current" time  
>>> step block
>>> has Data Arrays          associated with the grid. So, at each  
>>> time step of the
>>> animation, the          process seems very slow because 1200  
>>> blocks are being
>>> loaded, only one          of which actually has real data in it.  
>>> (The Time pane at
>>> the bottom of          the Information tab always lists the  
>>> correct time
>>> indices and values          for the whole series.)
>>>               Maybe this is just a change in the way time series are
>>> dealt with, but          it is much slower with my data sets, and  
>>> it made more
>>> sense to me to          have each time step able to be represented  
>>> as a simple
>>> grid, if          desired. (I have been using a self-modified
>>> vtkXdmfReader.cxx file for          a while, so I'm not sure when  
>>> this multi-block issue
>>> would have          appeared.)
>>>               Thanks,
>>>        -Eric
>>>               ------------------------------------------------------
>>>        Eric E Monson
>>>        Duke Visualization Technology Group
>>>                              
>>> _______________________________________________
>>>        Xdmf mailing list
>>>        Xdmf at lists.kitware.com
>>>        https://www.kitware.com/cgi-bin/mailman/listinfo/xdmf
>>>
>>>
>>>