Hi Ken, Sorry to persist, but I found a case that is not properly dealt with by the class FileSeriesReader in cooperation with the reader you kindly modified helping me out:
There are cases, though rare, where multiple files can contain identical
time step values. Think about a transient nonlinear solution process
where the linear solver exports its intermediate solutions to disk - all
files within one nonlinear step will contain the same time step value.
There are probably other cases as well.
By fixing bug 8892, you added (among others) these instructions to
Servers/Filters/vtkFileSeriesReader.cxx:
> int vtkFileSeriesReaderTimeRanges::GetAggregateTimeInfo([...])
> {
> [...]
> double timeRange[2];
> timeRange[0] = this->RangeMap.begin()->second
>
> ->Get(vtkStreamingDemandDrivenPipeline::TIME_RANGE())[0];
> timeRange[1] = (--this->RangeMap.end())->second
>
> ->Get(vtkStreamingDemandDrivenPipeline::TIME_RANGE())[1];
>
> // Special case: if the time range is a single value, supress it. This is
> // most likely from a data set that is a single file with no time anyway.
> // Even if it is not, how much value added is there for a single time value?
> if (timeRange[0] >= timeRange[1])
> {
> outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_RANGE());
> outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_STEPS());
> return 1;
> }
which lead to the situation that only the last file of a file series is
loaded by readers depending on class FileSeriesReader if the files
contain non-unique time step values. You can test it with the attached
reader plugin and the file series sampleinputfiles/sametimes*.foo.
You'll notice on STDOUT that only sametimes9.foo, the last file, is loaded.
I'd like to propose a patch that warns the user for such a file series
and falls back to fake time step values. I'm not sure about implications
for animation functions, though, I'm afraid. But having applied the
patch, one can step through sametimes*.foo as well.
(Actually, willing to support the same-time-step-values-in-all-files
case is the reason why I went through the trouble to have my own book
keeping in my reader.)
Karl
----- Original Message -----
From: "Moreland, Kenneth" <kmo...@sandia.gov>
To: Karl König <kkoeni...@web.de>
CC: "paraview@paraview.org" <paraview@paraview.org>
Sent: Sonntag, 6. September 2009 18:20:26
Subject: [Paraview] Problem with custom time-aware reader
> OOPS! STOP! BACK UP! I looked at your code too quickly, misunderstood
> what you were doing, and gave totally the wrong advise. Please ignore
> everything I said before.
>
> If you are using the file series reader, then your reader should be
> completely ignorant of any file series. It should read in only the file
> it is given, and if that file changes then it should ignore whatever
> file it was previously given. Therefore, the problem with your reader
> is that it is trying to collect time information over all the files.
> That is the job of the file series reader and as a result it is fouling
> up the operation of the file series reader.
>
> So, what your reader should do is read in the time value in the file it
> is given, set the TIME_STEPS key to ONLY that time value and set the
> TIME_RANGE to be only that range. Attached is a modified version of
> your reader example that has all that time series management stripped
> out. The resulting code is much smaller and actually works.
>
> Specifically what was happening was that by the time RequestInformation
> was called on the last time step, your reader had collected information
> about all the time steps and returned all the time steps in all the
> files. The file series reader thought you meant that the last file
> contained all those time steps (some file formats do contain multiple
> time steps in a single file). Because your reader said that the last
> file contained all the time steps, the file series reader was using that
> last file for all the time steps.
>
> -Ken
>
>
> On 9/3/09 11:24 PM, "Karl König" <kkoeni...@web.de> wrote:
>
> Hi Ken,
>
> Thanks again for your input.
>
> > You have the basic idea. The seg fault is probably happening because
> > the destructor of you class is trying to free the pointer you set
> to it,
> > which is probably actually pointing to some spot on the stack.
> >
> > You are probably not seeing this mapping/lookup in the VTK IO classes
> > because you are looking at classes that do not directly support time
> > (such as the legacy readers and XML readers). Those readers read
> > exactly one file with one time step in it. ParaView has a magic meta
> > reader called a FileSeriesReader that takes a real reader and a
> > collection of files and multiplexes the files to the reader based
> on the
> > time.
> >
> > In retrospect, this is probably an easier way to go (assuming your
> final
> > reader is a file series like this). Documentation on using the
> > FileSeriesReader is on the Wiki at
> >
> >
> http://www.paraview.org/Wiki/Restarted_Simulation_Readers#Customized_Restart_Reader
>
> I've been aware of that page. In fact, FooReader.xml and
> FooReaderGUI.xml of the tarball I posted already did make use of the
> FileSeriesReader. Together with calling
> outInfo->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), ...)
> outInfo->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), ...)
> in RequestInformation it is responsible for inspecting all files of the
> series between selecting them in the file open dialog and appearing of
> the Apply button.
>
> Anyway, I'll try to use again the mapping time step value -> file name
> and iron out the segfault on deletion of the reader object.
>
> I'll post the solution in case I can work it out and someone is
> interested.
>
> Karl
>
>
>
>
>
> **** Kenneth Moreland
> *** Sandia National Laboratories
> ***********
> *** *** *** email: kmo...@sandia.gov
> ** *** ** phone: (505) 844-8919
> *** web: http://www.cs.unm.edu/~kmorel
>
diff --git a/Servers/Filters/vtkFileSeriesReader.cxx
b/Servers/Filters/vtkFileSeriesReader.cxx
index 96d86fb..5aaf4af 100644
--- a/Servers/Filters/vtkFileSeriesReader.cxx
+++ b/Servers/Filters/vtkFileSeriesReader.cxx
@@ -553,6 +553,28 @@ int vtkFileSeriesReader::RequestInformation(
this->RequestInformationForInput(i, request, outputVector);
this->Internal->TimeRanges->AddTimeRange(i, outInfo);
}
+
+ // Catch case where multiple files set the same timestep
+ int numTimeSteps
+ = outInfo->Length(vtkStreamingDemandDrivenPipeline::TIME_STEPS());
+ if (numTimeSteps < numFiles)
+ {
+ vtkWarningMacro("Multiple files contain identical time step values. "
+ << "Reverting to fake time step values.");
+
+ this->Internal->TimeRanges->Reset();
+ outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_STEPS());
+ outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_RANGE());
+
+ // Input files have non-unique time steps. Fake a time step for each
equal to the
+ // index.
+ for (int i = 0; i < numFiles; i++)
+ {
+ double time = (double)i;
+ outInfo->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(), &time, 1);
+ this->Internal->TimeRanges->AddTimeRange(i, outInfo);
+ }
+ }
}
// Now that we have collected all of the time information, set the aggregate
FooReader.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
