[Paraview] Interesting bug when using windbladereader and multiple time steps

[Andy Bauer]

After talking to Berk and Utkarsh, I think the proper solution is to use the
time request for the requesting port for both the blade and the field
ports.  This will keep everything in sync.

Andy

On Mon, Jul 11, 2011 at 9:38 PM, Sohail Shafii <sohailshafii at yahoo.com>wrote:

> Hi,
>
> There is actually another bug (which may or may not be related) which did
> not happen before with ParaView 3.8.0 but appears with the release branch of
> the ParaView that I am using.  If I load a wind data set after connecting to
> 2-process localhost (mpirun -np 2 pvserver), the gradient of unstructured
> grid appears greyed out in the filters menu so I can't use that (which is
> necessary for me).
>
> If I run "mpirun -np 1 pvserver," this is not an issue. It's only an issue
> with 2 processes or above.  This doesn't happen if I load in a *foam file
> (i.e. openFOAM file); only with .wind and the most up-to-date release
> version of ParaView as opposed to 3.8.0.
>
>
> Sohail
>
> --- On *Fri, 7/8/11, Andy Bauer <andy.bauer at kitware.com>* wrote:
>
>
> From: Andy Bauer <andy.bauer at kitware.com>
> Subject: Re: [Paraview] Interesting bug when using windbladereader and
> multiple time steps
> To: "Sohail Shafii" <sohailshafii at yahoo.com>
> Cc: "Patricia KFasel" <pkf at lanl.gov>, paraview at paraview.org
> Date: Friday, July 8, 2011, 10:22 AM
>
>
> 3 or 4 time steps should be fine.
>
> Thanks,
> Andy
>
> On Fri, Jul 8, 2011 at 1:18 PM, Sohail Shafii <sohailshafii at yahoo.com<http://mc/compose?to=sohailshafii@yahoo.com>
> > wrote:
>
> Thank you for looking into this. I only modified the windbladereader to
> handle a slight format change, so my knowledge here is a bit limited (in
> regards to its original design) but I'll help out when necessary.  From what
> I see there are two outputs (one field, one blade).  I guess the nice thing
> about having a separate output for the blade is that I can render it
> separately from the field.
>
> I can send you a data set with more timesteps (similar to what you are
> using now, actually), problem is my DSL connection has a poor upload.  Would
> three or four timesteps do?
>
> Sohail
>
>
> --- On *Fri, 7/8/11, Andy Bauer <andy.bauer at kitware.com<http://mc/compose?to=andy.bauer@kitware.com>
> >* wrote:
>
>
> From: Andy Bauer <andy.bauer at kitware.com<http://mc/compose?to=andy.bauer@kitware.com>
> >
> Subject: Re: [Paraview] Interesting bug when using windbladereader and
> multiple time steps
> To: "Sohail Shafii" <sohailshafii at yahoo.com<http://mc/compose?to=sohailshafii@yahoo.com>>,
> "Fasel, Patricia K" <pkf at lanl.gov <http://mc/compose?to=pkf@lanl.gov>>
> Cc: paraview at paraview.org <http://mc/compose?to=paraview@paraview.org>
> Date: Friday, July 8, 2011, 9:59 AM
>
>
> Ok, I'm able to replicate the bug.  The test file I have (
> http://vtk.org/gitweb?p=VTKLargeData.git;a=tree;f=Data/WindBladeReader;h=3459e8ded59eb05796e922d90200bd4e83231df0;hb=HEAD)
> only has 2 time steps so I may need another set of files from you with more
> time steps.
>
> Playing around with the reader in ParaView, I think it may be worse than
> you realize.  Only the time information for the field is getting updated
> properly and if you go back in time steps, the blade time step either still
> increases or stays the same if it has hit the last time step.  I need to
> talk to our temporal pipeline expert to figure out the proper behavior.  One
> question though -- is there a reason that the reader doesn't return a
> multiblock with the 3 grids in it instead of having 3 separate output
> ports?  I'm thinking that if the output was changed to a multiblock then
> these time issues would go away.
>
> Andy
>
> On Thu, Jul 7, 2011 at 10:28 PM, Sohail Shafii <sohailshafii at yahoo.com<http://mc/compose?to=sohailshafii@yahoo.com>
> > wrote:
>
> I believe that data set went you (related to the updates I made for the
> wind blade reader)...the one with ten timesteps, should do the trick.  Do
> you still have it?
>
> Sohail
>
> --- On *Thu, 7/7/11, Andy Bauer <andy.bauer at kitware.com<http://mc/compose?to=andy.bauer@kitware.com>
> >* wrote:
>
>
> From: Andy Bauer <andy.bauer at kitware.com<http://mc/compose?to=andy.bauer@kitware.com>
> >
> Subject: Re: [Paraview] Interesting bug when using windbladereader and
> multiple time steps
> To: "Sohail Shafii" <sohailshafii at yahoo.com<http://mc/compose?to=sohailshafii@yahoo.com>
> >
> Cc: paraview at paraview.org <http://mc/compose?to=paraview@paraview.org>
> Date: Thursday, July 7, 2011, 7:09 PM
>
>
> I'll take a look at it.  I may need a time dependent data set if I can't
> figure it out though.
>
> Andy
>
> On Thu, Jul 7, 2011 at 9:13 PM, Sohail Shafii <sohailshafii at yahoo.com<http://mc/compose?to=sohailshafii@yahoo.com>
> > wrote:
>
> Hi,
>
> I've noticed a bug when using the windbladereader; the portion of the code
> that reads the blade file is one timestep behind the code that reads the
> field.  For instance, if one is at timestep i, the field data will
> correspond with timestep "i" but the blade data will correspond with the
> last timestep chosen.  When a data set is opened initially both the blade
> and field items are set to the initial timestep.  After one starts changing
> the timestep, the bug makes an appearance.
>
> In the code, the blade and field specify their timesteps (individually)
> based on the bladeInfo and fieldInfo objects, respectively.  These info
> objects are related to the outputVector of requestInformation -- I wonder if
> this is some kind of pipeline issue?
>
> Thanks,
> Sohail
>
> _______________________________________________
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110712/225bd9ad/attachment-0001.htm>