<br><font size=2 face="sans-serif">Hi Karl,</font>
<br>
<br><font size=2 face="sans-serif">We had a similar pb to yours : our times
are not 1D, but 2D in the sense that each physical time can be associated
to one or several iterations.</font>
<br><font size=2 face="sans-serif">What I did was to provide a TimeMode
parameter : </font>
<br><font size=2 face="sans-serif">If the TimeMode is set the PhysicalTime
(the default), then the reader exposes the available physical times in
the request Information pass, and always provides the last iteration available
when requested a given time.</font>
<br><font size=2 face="sans-serif">When the time mode is set to Iteration,
the user also has to provide the physical time he want to look at, and
then the reader exposes the available iterations for this given physical
time in the information pass, and outputs the good iteration when asked
for.</font>
<br>
<br><font size=2 face="sans-serif">Just to share ideas...</font>
<br>
<br><font size=2 face="sans-serif">Stephane<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>kmorel@sandia.gov</b> </font>
<br><font size=1 face="sans-serif">Envoyé par : paraview-bounces@paraview.org</font>
<p><font size=1 face="sans-serif">11/09/2009 00:45</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">A</font></div>
<td><font size=1 face="sans-serif">kkoenig11@web.de</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">paraview@paraview.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Objet</font></div>
<td><font size=1 face="sans-serif">Re: [Paraview] Problem with custom time-aware
reader</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 face="Calibri">Actually, we designed the file series reader
with the understanding that time ranges might overlap, but with a different
use case in mind. Our users often have to run simulations far past
the mean time to failure of the platforms they are running on. To
handle the problem of the inevitable crash of the system, the simulation
periodically writes out checkpoint files. When the system fails,
the simulation is “backed back” to the last checkpoint and restarted.
As the simulation reruns from this point, it will recompute some
time steps and rewrite out the data for those times. The file series
reader understands that these time steps are duplicated and picks the one
most likely to be correct.<br>
<br>
So the problem is that your case excludes this case. If the file
series reader declared an error whenever it encountered multiple versions
of the same time, it would not be reading in the restarted simulation data
correctly. The problem is, your case does not really represent an
actual time series in the physical sense. I can see the utility of
looking at the intermediate solutions, but these intermediate solutions
are not a real progression of events in a physical sense. It is by
removing the intermediate results that you get a progression of actual
physical events. In fact, I can see utility in viewing the data in
either way.<br>
<br>
So instead, I suggest some workarounds. First, your reader might
be able to sense which iterative intermediate result it is reading and
then add some delta to the time to make the file series reader recognize
them as different times. This is probably the most hack-ish, as,
again, these intermediate results do not really represent a time series
(even if you want them animated as such). Second, you could have
a flag in your reader to ignore time. If your reader does not set
the time keys, the file series reader will treat the files as an ordinary
sequence. Third, you (or I) could add a flag to the file series reader
that would force it to ignore the time in the reader. This flag would
be hidden for most readers, but could be exposed for your reader.<br>
<br>
-Ken<br>
<br>
<br>
On 9/9/09 8:46 AM, "Karl König" <</font><a href=kkoenig11@web.de><font size=2 color=blue face="Calibri"><u>kkoenig11@web.de</u></font></a><font size=2 face="Calibri">>
wrote:<br>
</font>
<br><font size=2 face="Calibri">Hi Ken,<br>
<br>
Sorry to persist, but I found a case that is not properly dealt with by<br>
the class FileSeriesReader in cooperation with the reader you kindly<br>
modified helping me out:<br>
<br>
There are cases, though rare, where multiple files can contain identical<br>
time step values. Think about a transient nonlinear solution process<br>
where the linear solver exports its intermediate solutions to disk - all<br>
files within one nonlinear step will contain the same time step value.<br>
There are probably other cases as well.<br>
<br>
By fixing bug 8892, you added (among others) these instructions to<br>
Servers/Filters/vtkFileSeriesReader.cxx:<br>
<br>
> int vtkFileSeriesReaderTimeRanges::GetAggregateTimeInfo([...])<br>
> {<br>
> [...]<br>
> double timeRange[2];<br>
> timeRange[0] = this->RangeMap.begin()->second<br>
>
->Get(vtkStreamingDemandDrivenPipeline::TIME_RANGE())[0];<br>
> timeRange[1] = (--this->RangeMap.end())->second<br>
>
->Get(vtkStreamingDemandDrivenPipeline::TIME_RANGE())[1];<br>
><br>
> // Special case: if the time range is a single value, supress
it. This is<br>
> // most likely from a data set that is a single file with no
time anyway.<br>
> // Even if it is not, how much value added is there for a single
time value?<br>
> if (timeRange[0] >= timeRange[1])<br>
> {<br>
> outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_RANGE());<br>
> outInfo->Remove(vtkStreamingDemandDrivenPipeline::TIME_STEPS());<br>
> return 1;<br>
> }<br>
<br>
which lead to the situation that only the last file of a file series is<br>
loaded by readers depending on class FileSeriesReader if the files<br>
contain non-unique time step values. You can test it with the attached<br>
reader plugin and the file series sampleinputfiles/sametimes*.foo.<br>
You'll notice on STDOUT that only sametimes9.foo, the last file, is loaded.<br>
<br>
I'd like to propose a patch that warns the user for such a file series<br>
and falls back to fake time step values. I'm not sure about implications<br>
for animation functions, though, I'm afraid. But having applied the<br>
patch, one can step through sametimes*.foo as well.<br>
(Actually, willing to support the same-time-step-values-in-all-files<br>
case is the reason why I went through the trouble to have my own book<br>
keeping in my reader.)<br>
<br>
Karl<br>
<br>
<br>
----- Original Message -----<br>
From: "Moreland, Kenneth" <</font><a href=kmorel@sandia.gov><font size=2 color=blue face="Calibri"><u>kmorel@sandia.gov</u></font></a><font size=2 face="Calibri">><br>
To: Karl König <</font><a href=kkoenig11@web.de><font size=2 color=blue face="Calibri"><u>kkoenig11@web.de</u></font></a><font size=2 face="Calibri">><br>
CC: "</font><a href=paraview@paraview.org><font size=2 color=blue face="Calibri"><u>paraview@paraview.org</u></font></a><font size=2 face="Calibri">"
<</font><a href=paraview@paraview.org><font size=2 color=blue face="Calibri"><u>paraview@paraview.org</u></font></a><font size=2 face="Calibri">><br>
Sent: Sonntag, 6. September 2009 18:20:26<br>
Subject: [Paraview] Problem with custom time-aware reader<br>
> OOPS! STOP! BACK UP! I looked at your code too quickly,
misunderstood<br>
> what you were doing, and gave totally the wrong advise. Please
ignore<br>
> everything I said before.<br>
><br>
> If you are using the file series reader, then your reader should be<br>
> completely ignorant of any file series. It should read in only
the file<br>
> it is given, and if that file changes then it should ignore whatever<br>
> file it was previously given. Therefore, the problem with your
reader<br>
> is that it is trying to collect time information over all the files.<br>
> That is the job of the file series reader and as a result it
is fouling<br>
> up the operation of the file series reader.<br>
><br>
> So, what your reader should do is read in the time value in the file
it<br>
> is given, set the TIME_STEPS key to ONLY that time value and set the<br>
> TIME_RANGE to be only that range. Attached is a modified version
of<br>
> your reader example that has all that time series management stripped<br>
> out. The resulting code is much smaller and actually works.<br>
><br>
> Specifically what was happening was that by the time RequestInformation<br>
> was called on the last time step, your reader had collected information<br>
> about all the time steps and returned all the time steps in all the<br>
> files. The file series reader thought you meant that the last
file<br>
> contained all those time steps (some file formats do contain multiple<br>
> time steps in a single file). Because your reader said that
the last<br>
> file contained all the time steps, the file series reader was using
that<br>
> last file for all the time steps.<br>
><br>
> -Ken<br>
><br>
><br>
> On 9/3/09 11:24 PM, "Karl König" <</font><a href=kkoenig11@web.de><font size=2 color=blue face="Calibri"><u>kkoenig11@web.de</u></font></a><font size=2 face="Calibri">>
wrote:<br>
><br>
> Hi Ken,<br>
><br>
> Thanks again for your input.<br>
><br>
> > You have the basic idea. The seg fault is
probably happening because<br>
> > the destructor of you class is trying to free the
pointer you set<br>
> to it,<br>
> > which is probably actually pointing to some spot
on the stack.<br>
> ><br>
> > You are probably not seeing this mapping/lookup
in the VTK IO classes<br>
> > because you are looking at classes that do not
directly support time<br>
> > (such as the legacy readers and XML readers). Those
readers read<br>
> > exactly one file with one time step in it. ParaView
has a magic meta<br>
> > reader called a FileSeriesReader that takes a real
reader and a<br>
> > collection of files and multiplexes the files to
the reader based<br>
> on the<br>
> > time.<br>
> ><br>
> > In retrospect, this is probably an easier way to
go (assuming your<br>
> final<br>
> > reader is a file series like this). Documentation
on using the<br>
> > FileSeriesReader is on the Wiki at<br>
> ><br>
> > </font><a href=http://www.paraview.org/Wiki/Restarted_Simulation_Readers#Customized_Restart_Reader><font size=2 color=blue face="Calibri"><u>http://www.paraview.org/Wiki/Restarted_Simulation_Readers#Customized_Restart_Reader</u></font></a><font size=2 face="Calibri"><br>
><br>
> I've been aware of that page. In fact, FooReader.xml
and<br>
> FooReaderGUI.xml of the tarball I posted already did
make use of the<br>
> FileSeriesReader. Together with calling<br>
> outInfo->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(),
...)<br>
> outInfo->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(),
...)<br>
> in RequestInformation it is responsible for inspecting
all files of the<br>
> series between selecting them in the file open dialog
and appearing of<br>
> the Apply button.<br>
><br>
> Anyway, I'll try to use again the mapping time step
value -> file name<br>
> and iron out the segfault on deletion of the reader
object.<br>
><br>
> I'll post the solution in case I can work it out and
someone is<br>
> interested.<br>
><br>
> Karl<br>
><br>
><br>
><br>
><br>
><br>
> **** Kenneth Moreland<br>
> *** Sandia National Laboratories<br>
> *********** <br>
> *** *** *** email: </font><a href=kmorel@sandia.gov><font size=2 color=blue face="Calibri"><u>kmorel@sandia.gov</u></font></a><font size=2 face="Calibri"><br>
> ** *** ** phone: (505) 844-8919<br>
> *** web: </font><a href=http://www.cs.unm.edu/~kmorel><font size=2 color=blue face="Calibri"><u>http://www.cs.unm.edu/~kmorel</u></font></a><font size=2 face="Calibri"><br>
><br>
<br>
</font>
<br><font size=2 face="Consolas"><br>
<br>
**** Kenneth Moreland<br>
*** Sandia National Laboratories<br>
*********** <br>
*** *** *** email: </font><a href=kmorel@sandia.gov><font size=2 color=blue face="Consolas"><u>kmorel@sandia.gov</u></font></a><font size=2 face="Consolas"><br>
** *** ** phone: (505) 844-8919<br>
*** web: </font><a href=http://www.cs.unm.edu/~kmorel><font size=2 color=blue face="Consolas"><u>http://www.cs.unm.edu/~kmorel</u></font></a><font size=2 face="Calibri"><br>
</font><tt><font size=2>_______________________________________________<br>
Powered by www.kitware.com<br>
<br>
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView<br>
<br>
Follow this link to subscribe/unsubscribe:<br>
http://www.paraview.org/mailman/listinfo/paraview<br>
</font></tt>
<br>
<pre>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________
This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
</pre>