Re: [Paraview] Maintain triangulation of slive from vtk to numpy

[Gallagher, Timothy P]

Kyle,


Once you get a slice, you can extract the underlying vtkUnstructuredGrid and 
use that to extract the connectivity. For example:


uns_grid = servermanager.Fetch(slice)


npts = uns_grid.GetNumberOfCells()


for n in xrange(npts):

ptids = vtk.vtkIdList()

uns_grid.GetCellPoints(0, ptids)

print [ptids.GetId(i) for i in xrange(ptids.GetNumberOfIds())]


And you can interchange the words Point and Cell to get the inverse information 
(all of the cells using a given point).


I tried playing around with something along the lines of:


uns_grid.BuildLinks()

links = uns_grid.GetCellLinks()

npts = uns_grid.GetNumberOfPoints()


for i in xrange(npts)

print links.GetCells(i)


but GetCells returns a vtkIdType pointer, which in Python shows up as a string 
containing an address in memory. I couldn't figure out how to translate that 
back into something meaningful.


Tim



From: ParaView  on behalf of Schau, Kyle A 

Sent: Wednesday, March 1, 2017 12:35 PM
To: paraview@paraview.org
Subject: [Paraview] Maintain triangulation of slive from vtk to numpy


Hello All


Does anyone know if the capability exists to extract slice data through the 
python interface of paraview that contains the triangulation data of the slice? 
This would allow one to pull flattened VTK data in the form of numpy arrays, 
but still plot non-convex slice geometries easily with mayplotlib.tricont()


Thanks for your help.


Kyle A. Schau


Graduate Research Assistant


Computational Combustion Lab

Georgia Institute of Technology

Atlanta, GA


(269)-986-4579
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Finding volume enclosed by a contour.

[Gallagher, Timothy P]

I was suggesting trying a pipeline like:


OpenFOAM Reader -> Threshold -> IntegrateVariables -> IntegrateVariables


So your second IV filter is applied to the first IV filter.


Again, no idea if that will help. Hopefully somebody else can come along and 
give you a solution.


Tim



From: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>
Sent: Saturday, March 4, 2017 1:44 PM
To: Gallagher, Timothy P; paraview@paraview.org
Subject: RE: Finding volume enclosed by a contour.


Hi Tim;



Yes I do think so it is somehow related to the OpenFOAM reader. I just tried a 
tutorial case from the CFD package and I still have the same data set with no 
additional data related to the volume/ area/ length.



I am not sure if I understood your idea right, do you mean apply 
integrateVariables twice on the same threshold data set?



“Sorry, I tried!”

No worries this has been a long standing problem for my work. I am really happy 
that you shared your ideas with me.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 18:07
To: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>; paraview@paraview.org
Subject: Re: Finding volume enclosed by a contour.



Hmmm, interesting. It must be a function of the type of data from the OpenFOAM 
reader and I am unfamiliar with that reader.



All of my datasets are structured and behave the way I mentioned earlier. I'm 
not sure how to get the volume from the dataset you have.



Somebody else will have to chime in on this one. Just out of curiosity, if you 
IntegrateVariables again, does it condense the data into a single set of 
values? (That's a totally random guess -- maybe the first IntegrateVariables is 
coming up with the cell-averaged values from an unstructured dataset, and the 
second would do the integral of all the cell-averages).



Sorry, I tried!



Tim





From: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>
Sent: Saturday, March 4, 2017 1:00 PM
To: Gallagher, Timothy P; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: RE: Finding volume enclosed by a contour.



Tim,



I did try to vary from pointData to cellData but I see the same fields present. 
That is, I see no additional field being added.



Attached is a screenshot (all the data from U are the variables being computed 
from my solver). I tried it over 4.x and 5.x versions of paraview so, I guess I 
am doing something wrong.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 17:36
To: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>; 
paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: Finding volume enclosed by a contour.



The IntegrateVariables filter creates a spreadsheet of PointData (or CellData, 
depending on where your data is stored in the filter just before 
IntegrateVariables) with the integral of your data over the volume/area/length 
depending on if it is 3D/2D/1D data respectively.



It also adds a field to the CellData array that will be Volume/Area/Length 
respectively.



My guess is if you aren't seeing it immediately it is because you are looking 
at the PointData array and not the CellData array. In the SpreadSheetView that 
opens up, change the Attribute dropdown from Point Data to Cell Data.



Also, as a note -- the values for your variables (pressure, velocity, whatever) 
are multiplied by the length scale, so if you want the average value in the 
domain, you need to divide it by the length scale.



Tim





From: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>
Sent: Saturday, March 4, 2017 12:30 PM
To: Gallagher, Timothy P; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: RE: Finding volume enclosed by a contour.



Thanks Tim;



I could precisely extract the bubble using the threshold filter as you said 
(attached picture).



Coming to the 2nd step: I applied the integrate variables filter on the 
threshold data but I get the general data set values within individual cells 
like the computed velocity, pressure, etc….



How do I integrate the the region in space to find the enclosed volume?



Sorry, if it’s a basic question.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 17:09
To: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>; 
paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: Finding volume enclosed by a contour.



Your best bet would be to use the Threshold filter to extract the region where 
the scalar is greater (or less than) 0.5 and then use the IntegrateVariables 
filter on the Threshold.



It's not entirely clear your exact pipeline, but

Re: [Paraview] Finding volume enclosed by a contour.

[Gallagher, Timothy P]

Hmmm, interesting. It must be a function of the type of data from the OpenFOAM 
reader and I am unfamiliar with that reader.


All of my datasets are structured and behave the way I mentioned earlier. I'm 
not sure how to get the volume from the dataset you have.


Somebody else will have to chime in on this one. Just out of curiosity, if you 
IntegrateVariables again, does it condense the data into a single set of 
values? (That's a totally random guess -- maybe the first IntegrateVariables is 
coming up with the cell-averaged values from an unstructured dataset, and the 
second would do the integral of all the cell-averages).


Sorry, I tried!


Tim



From: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>
Sent: Saturday, March 4, 2017 1:00 PM
To: Gallagher, Timothy P; paraview@paraview.org
Subject: RE: Finding volume enclosed by a contour.


Tim,



I did try to vary from pointData to cellData but I see the same fields present. 
That is, I see no additional field being added.



Attached is a screenshot (all the data from U are the variables being computed 
from my solver). I tried it over 4.x and 5.x versions of paraview so, I guess I 
am doing something wrong.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 17:36
To: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>; paraview@paraview.org
Subject: Re: Finding volume enclosed by a contour.



The IntegrateVariables filter creates a spreadsheet of PointData (or CellData, 
depending on where your data is stored in the filter just before 
IntegrateVariables) with the integral of your data over the volume/area/length 
depending on if it is 3D/2D/1D data respectively.



It also adds a field to the CellData array that will be Volume/Area/Length 
respectively.



My guess is if you aren't seeing it immediately it is because you are looking 
at the PointData array and not the CellData array. In the SpreadSheetView that 
opens up, change the Attribute dropdown from Point Data to Cell Data.



Also, as a note -- the values for your variables (pressure, velocity, whatever) 
are multiplied by the length scale, so if you want the average value in the 
domain, you need to divide it by the length scale.



Tim





From: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>
Sent: Saturday, March 4, 2017 12:30 PM
To: Gallagher, Timothy P; paraview@paraview.org<mailto:paraview@paraview.org>
Subject: RE: Finding volume enclosed by a contour.



Thanks Tim;



I could precisely extract the bubble using the threshold filter as you said 
(attached picture).



Coming to the 2nd step: I applied the integrate variables filter on the 
threshold data but I get the general data set values within individual cells 
like the computed velocity, pressure, etc….



How do I integrate the the region in space to find the enclosed volume?



Sorry, if it’s a basic question.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 17:09
To: Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>; 
paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: Finding volume enclosed by a contour.



Your best bet would be to use the Threshold filter to extract the region where 
the scalar is greater (or less than) 0.5 and then use the IntegrateVariables 
filter on the Threshold.



It's not entirely clear your exact pipeline, but it sounds like you are using 
the IntegrateVariables filter on the Contour, which would give you the surface 
area of the region instead.



Tim





From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>
Sent: Saturday, March 4, 2017 11:36 AM
To: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: [Paraview] Finding volume enclosed by a contour.



Hi guys;



I am using a numerical method (Volume of fluid, just for information) to look 
at the breaking of a bubble in a micro-channel. Attached picture.



As mostly, the bubbles are of uniform size, I would like to know the volume of 
any one bubble formed.



The bubble is represented by a scalar data set represented by 1 and bounded by 
the same data set with values 0.



I think to clip the region enclosing one bubble and draw a contour where the 
scalar value is 0.5. Now, I tried the integrate variables filter but I did not 
find a data representing the volume.  Any idea how can I get the volume 
enclosed by this contour?



Any help appreciated.



Thanks;

SaiD
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please ke

Re: [Paraview] Finding volume enclosed by a contour.

[Gallagher, Timothy P]

The IntegrateVariables filter creates a spreadsheet of PointData (or CellData, 
depending on where your data is stored in the filter just before 
IntegrateVariables) with the integral of your data over the volume/area/length 
depending on if it is 3D/2D/1D data respectively.


It also adds a field to the CellData array that will be Volume/Area/Length 
respectively.


My guess is if you aren't seeing it immediately it is because you are looking 
at the PointData array and not the CellData array. In the SpreadSheetView that 
opens up, change the Attribute dropdown from Point Data to Cell Data.


Also, as a note -- the values for your variables (pressure, velocity, whatever) 
are multiplied by the length scale, so if you want the average value in the 
domain, you need to divide it by the length scale.


Tim



From: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>
Sent: Saturday, March 4, 2017 12:30 PM
To: Gallagher, Timothy P; paraview@paraview.org
Subject: RE: Finding volume enclosed by a contour.


Thanks Tim;



I could precisely extract the bubble using the threshold filter as you said 
(attached picture).



Coming to the 2nd step: I applied the integrate variables filter on the 
threshold data but I get the general data set values within individual cells 
like the computed velocity, pressure, etc….



How do I integrate the the region in space to find the enclosed volume?



Sorry, if it’s a basic question.



Saideep



From: Gallagher, Timothy P [mailto:tim.gallag...@gatech.edu]
Sent: 04 March 2017 17:09
To: Saideep Pavuluri <saideep.pavul...@pet.hw.ac.uk>; paraview@paraview.org
Subject: Re: Finding volume enclosed by a contour.



Your best bet would be to use the Threshold filter to extract the region where 
the scalar is greater (or less than) 0.5 and then use the IntegrateVariables 
filter on the Threshold.



It's not entirely clear your exact pipeline, but it sounds like you are using 
the IntegrateVariables filter on the Contour, which would give you the surface 
area of the region instead.



Tim





From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Saideep Pavuluri 
<saideep.pavul...@pet.hw.ac.uk<mailto:saideep.pavul...@pet.hw.ac.uk>>
Sent: Saturday, March 4, 2017 11:36 AM
To: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: [Paraview] Finding volume enclosed by a contour.



Hi guys;



I am using a numerical method (Volume of fluid, just for information) to look 
at the breaking of a bubble in a micro-channel. Attached picture.



As mostly, the bubbles are of uniform size, I would like to know the volume of 
any one bubble formed.



The bubble is represented by a scalar data set represented by 1 and bounded by 
the same data set with values 0.



I think to clip the region enclosing one bubble and draw a contour where the 
scalar value is 0.5. Now, I tried the integrate variables filter but I did not 
find a data representing the volume.  Any idea how can I get the volume 
enclosed by this contour?



Any help appreciated.



Thanks;

SaiD
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Finding volume enclosed by a contour.

[Gallagher, Timothy P]

Your best bet would be to use the Threshold filter to extract the region where 
the scalar is greater (or less than) 0.5 and then use the IntegrateVariables 
filter on the Threshold.


It's not entirely clear your exact pipeline, but it sounds like you are using 
the IntegrateVariables filter on the Contour, which would give you the surface 
area of the region instead.


Tim



From: ParaView  on behalf of Saideep Pavuluri 

Sent: Saturday, March 4, 2017 11:36 AM
To: paraview@paraview.org
Subject: [Paraview] Finding volume enclosed by a contour.


Hi guys;



I am using a numerical method (Volume of fluid, just for information) to look 
at the breaking of a bubble in a micro-channel. Attached picture.



As mostly, the bubbles are of uniform size, I would like to know the volume of 
any one bubble formed.



The bubble is represented by a scalar data set represented by 1 and bounded by 
the same data set with values 0.



I think to clip the region enclosing one bubble and draw a contour where the 
scalar value is 0.5. Now, I tried the integrate variables filter but I did not 
find a data representing the volume.  Any idea how can I get the volume 
enclosed by this contour?



Any help appreciated.



Thanks;

SaiD
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Cataylst pipeline not updating

[Gallagher, Timothy P]

Hi Andy,


Looks like passing the current time step into the UpdatePipeline calls made it 
work as expected. Sorry for the delay in reporting, it took a long time for the 
job to move through the queue!


Anyway, looks like it's working properly and I am getting the data as expected.


For future reference, should I always just pass the time in? Or are the 
possibly other, unintended side effects from that as well to watch out for?


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Monday, February 13, 2017 11:30 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Cataylst pipeline not updating

Hi Tim,

It's possible that there's something funky going on when the data set being 
passed through parts of the pipeline are empty. I'm hoping for the easy fix 
with passing in the time since I've know that has caused unexpected behavior 
before. If that doesn't solve your issue then I'll probably have to do 
something similar and run it locally to see what's going on.

Cheers,
Andy

On Mon, Feb 13, 2017 at 11:06 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

The RequestDataDescription is the same as the default output from the script 
generator, so I didn't include it. The DoCoProcessing gets called every time 
step and the volumeIntegrals data is updated and written correctly every 
delta_t, so I'm confident in that part.


I will add the calls you suggested and re-run. It takes some time for it to 
evolve to the point something will happen -- I don't have it saving data 
frequently enough to run a quick test, I was expecting the pipeline to save it 
for me!


The other thing that occurred to me -- is there something about the Contour 
filter that turns it off/disables it when the pipeline is built and there is no 
surface at that contour level?


Thanks,


Tim



From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Monday, February 13, 2017 10:56 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Cataylst pipeline not updating

Hi Tim,

Try adding in the current time to the UpdatePipeline() calls, e.g. 
*.UpdatePipeline(datadescription.GetCurrentTime())

It's tough to tell with RequestDataDescription() missing but I assume that 
DoCoProcessing() is getting called when you want, correct?

Let me know if that doesn't solve the problem.

Best,
Andy

On Mon, Feb 13, 2017 at 5:45 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Back with another question!


I have a pipeline that has 1 input and 4 outputs. The simplest is a 
IntegrateVariables filter hooked up to the input. Another branch of the 
pipeline goes through several PythonCalculator filters and a 
CellDataToPointData filter and then arrives at the three outputs:


1. The CD2PD filter is connected to a Contour filter with a single level, X. 
This is then connected to an IntegrateVariables filter (used to compute the 
area of the Contour) and a Writer.

2. The CD2PD filter is also connected to another Contour filter with a single 
level Y. This is connected to an IntegrateVariables and Writer just as in 1.

3. The CD2PD filter is sliced two times with each slice in a different render 
view to save images.


I have the coprocessor running every delta_t seconds. The initial 
IntegrateVariables filter is updated with UpdatePipeline and then the values 
are saved to disk. This works every step, no issues.


I then call UpdatePipeline on both of the Contour and both of the 
IntegrateVariables filters in 1 and 2. I check if the 'Area' field in the 
IntegrateVariables exceeds a threshold, and if it does, I save the Contour's to 
disk as a VTK file. This is not working correctly.


If I start the simulation from a point where the Contour's exist in the flow 
already, then everything works great and the Area field changes in time and it 
saves the Contour's.


However, if the simulation starts without the Contours already in the flow, the 
Area fields stay zero forever. It's as if the pipeline isn't updating or 
something. I have attached the DoCoProcessing function used. I don't see 
anything immediately obvious that would prevent it from updating or getting the 
correct values for the Area.


Am I missing something about how the pipeline or contour filters update?


Thanks,


Tim

___
Powered by www.kitware.com<http://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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscrib

Re: [Paraview] Cataylst pipeline not updating

[Gallagher, Timothy P]

The RequestDataDescription is the same as the default output from the script 
generator, so I didn't include it. The DoCoProcessing gets called every time 
step and the volumeIntegrals data is updated and written correctly every 
delta_t, so I'm confident in that part.


I will add the calls you suggested and re-run. It takes some time for it to 
evolve to the point something will happen -- I don't have it saving data 
frequently enough to run a quick test, I was expecting the pipeline to save it 
for me!


The other thing that occurred to me -- is there something about the Contour 
filter that turns it off/disables it when the pipeline is built and there is no 
surface at that contour level?


Thanks,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Monday, February 13, 2017 10:56 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Cataylst pipeline not updating

Hi Tim,

Try adding in the current time to the UpdatePipeline() calls, e.g. 
*.UpdatePipeline(datadescription.GetCurrentTime())

It's tough to tell with RequestDataDescription() missing but I assume that 
DoCoProcessing() is getting called when you want, correct?

Let me know if that doesn't solve the problem.

Best,
Andy

On Mon, Feb 13, 2017 at 5:45 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Back with another question!


I have a pipeline that has 1 input and 4 outputs. The simplest is a 
IntegrateVariables filter hooked up to the input. Another branch of the 
pipeline goes through several PythonCalculator filters and a 
CellDataToPointData filter and then arrives at the three outputs:


1. The CD2PD filter is connected to a Contour filter with a single level, X. 
This is then connected to an IntegrateVariables filter (used to compute the 
area of the Contour) and a Writer.

2. The CD2PD filter is also connected to another Contour filter with a single 
level Y. This is connected to an IntegrateVariables and Writer just as in 1.

3. The CD2PD filter is sliced two times with each slice in a different render 
view to save images.


I have the coprocessor running every delta_t seconds. The initial 
IntegrateVariables filter is updated with UpdatePipeline and then the values 
are saved to disk. This works every step, no issues.


I then call UpdatePipeline on both of the Contour and both of the 
IntegrateVariables filters in 1 and 2. I check if the 'Area' field in the 
IntegrateVariables exceeds a threshold, and if it does, I save the Contour's to 
disk as a VTK file. This is not working correctly.


If I start the simulation from a point where the Contour's exist in the flow 
already, then everything works great and the Area field changes in time and it 
saves the Contour's.


However, if the simulation starts without the Contours already in the flow, the 
Area fields stay zero forever. It's as if the pipeline isn't updating or 
something. I have attached the DoCoProcessing function used. I don't see 
anything immediately obvious that would prevent it from updating or getting the 
correct values for the Area.


Am I missing something about how the pipeline or contour filters update?


Thanks,


Tim

___
Powered by www.kitware.com<http://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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Cataylst pipeline not updating

[Gallagher, Timothy P]

Back with another question!


I have a pipeline that has 1 input and 4 outputs. The simplest is a 
IntegrateVariables filter hooked up to the input. Another branch of the 
pipeline goes through several PythonCalculator filters and a 
CellDataToPointData filter and then arrives at the three outputs:


1. The CD2PD filter is connected to a Contour filter with a single level, X. 
This is then connected to an IntegrateVariables filter (used to compute the 
area of the Contour) and a Writer.

2. The CD2PD filter is also connected to another Contour filter with a single 
level Y. This is connected to an IntegrateVariables and Writer just as in 1.

3. The CD2PD filter is sliced two times with each slice in a different render 
view to save images.


I have the coprocessor running every delta_t seconds. The initial 
IntegrateVariables filter is updated with UpdatePipeline and then the values 
are saved to disk. This works every step, no issues.


I then call UpdatePipeline on both of the Contour and both of the 
IntegrateVariables filters in 1 and 2. I check if the 'Area' field in the 
IntegrateVariables exceeds a threshold, and if it does, I save the Contour's to 
disk as a VTK file. This is not working correctly.


If I start the simulation from a point where the Contour's exist in the flow 
already, then everything works great and the Area field changes in time and it 
saves the Contour's.


However, if the simulation starts without the Contours already in the flow, the 
Area fields stay zero forever. It's as if the pipeline isn't updating or 
something. I have attached the DoCoProcessing function used. I don't see 
anything immediately obvious that would prevent it from updating or getting the 
correct values for the Area.


Am I missing something about how the pipeline or contour filters update?


Thanks,


Tim

#  Processing method 
def WriteDataFile(comm, object, filename, curTime, CellData=True):
  object.UpdatePipeline()

  if CellData:
data = object.CellData
  else:
data = object.PointData

  if comm.Get_rank() == 0:
with  open(filename, 'a+') as fid:
  # Rewind the file to see if it is empty or not
  fid.seek(0)
  if len(fid.read(1)) == 0:
# The file is empty, we need to create the header
outputStr = '# Time '
for var in data.keys():
  outputStr += '%s  ' % var
outputStr += '\n'
fid.write(outputStr)

  outputStr = '%15.7e ' % curTime
  for var in data.keys():
value = data[var].GetRange()[0]
outputStr += '%15.7e' % value
  outputStr += '\n'
  fid.write(outputStr)

def DoCoProcessing(datadescription):
"Callback to do co-processing for current timestep"
global coprocessor
global lastTime
global deltaT
global comm
global paths

# Update the coprocessor by providing it the newly generated simulation data.
# If the pipeline hasn't been setup yet, this will setup the pipeline.
coprocessor.UpdateProducers(datadescription)

curTime = datadescription.GetTime()
timestep = datadescription.GetTimeStep()

if curTime >= lastTime + deltaT:
  lastTime = curTime

  coprocessor.Pipeline.volumeIntegrals.UpdatePipeline()

  WriteDataFile(comm, coprocessor.Pipeline.volumeIntegrals,
paths['outdir']+'/post/volumeIntegrals.dat',
curTime,
CellData = True)

  # Check if we need to write images and the first flameArea datasets to disk
  coprocessor.Pipeline.flameArea.UpdatePipeline()
  area = np.zeros(1)

  if comm.Get_rank() == 0:
try:
  area[0] = coprocessor.Pipeline.flameArea.CellData['Area'].GetRange()[0]
except AttributeError:
  area[0] = 0.0
  else:
area[0] = 0.0

  comm.Bcast(area, root=0)
  if area[0] > 1e-9:
# Write image capture (Last arg: rescale lookup table), if appropriate.
coprocessor.WriteImages(datadescription, rescale_lookuptable=False)

# Write out the surface and the area
coprocessor.Pipeline.flameSurfaceWriter.FileName = paths['outdir']+'/post/flameSurface_%07i.vtm' % timestep
coprocessor.Pipeline.flameSurfaceWriter.UpdatePipeline(curTime)

WriteDataFile(comm, coprocessor.Pipeline.flameArea,
  paths['outdir']+'/post/flameArea.dat',
  curTime,
  CellData = False)


  # Check for the second flame surface
  coprocessor.Pipeline.flameArea2.UpdatePipeline()
  area = np.zeros(1)

  if comm.Get_rank() == 0:
try:
  area[0] = coprocessor.Pipeline.flameArea2.CellData['Area'].GetRange()[0]
except AttributeError:
  area[0] = 0.0
  else:
area[0] = 0.0

  comm.Bcast(area, root=0)
  if area[0] > 1e-9:
# Write image capture (Last arg: rescale lookup table), if appropriate.

Re: [Paraview] Pipeline update with Catalyst

[Gallagher, Timothy P]

Okay, I'm solidly impressed now.


I know it says all over the place that because Paraview uses Python, you can 
use Python. But for some reason, I always just look at it as using the 
grammar/structure of Python to interface with vtk and Paraview -- for some 
reason it takes me some time to recognize that I can use everything that comes 
with Python. Not sure why since I use Python every day for a lot of things.


I also get stuck on what is a transparent, helper function and what is an 
opaque interface to some vtk C++ function. For example, it didn't occur to me 
that the coprocessor.WriteData() function just looped over a list of writers, 
formatted the file name, and then updated the filter. I thought it was 
something in C++ that did things that weren't exposed to the Python interface.


Now that I'm slowly recognizing those things though, Catalyst is immensely more 
useful than the way I was using it before. I was sort of pigeonholed into 
thinking it had to look identical to the output from the generator and the only 
thing to tweak was in the pipeline.


I've got it set up now to track volume integrated variables every fixed unit of 
time and also to check if different features appear in the solution. If they 
appear, it writes some different data files and images. I've attached the 
processing method just to close the loop and provide an example of how to do 
the things I couldn't figure out (and didn't think was possible). I know 
there's several things that could probably be done better in it, but it works 
for me at the moment.


Thanks again!


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Tuesday, February 7, 2017 11:03 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Pipeline update with Catalyst

Indeed it is possibly to write whenever you choose instead of just based on 
time step number. If you skip the RegisterWriter() when making a Pipeline 
object writer and then setting the file name and writing it manually you will 
get what you want. It would look something like the attached file.

Note that I've set the outputfrequency to 1 here since I want to have 
DoCoProcessing() called every time step. You can put more logic into 
RequestDataDescription() if you don't want to have to create your grid and have 
DoCoProcessing() called every time step.

Thanks for asking detailed questions! There is a whole lot of flexibility 
provided by using the Python scripts in Catalyst but it can take a bit of 
expertise to get exactly what you want. I am glad that you are taking advantage 
of this.

Cheers,
Andy



On Tue, Feb 7, 2017 at 10:33 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Along those lines, is it possible to turn on/off specific data writers based on 
something other than time step number?


I have the data collection based on something from IntegrateVariables (it did 
require a broadcast from root), but I am creating multiple surfaces and would 
like to only save the data files when the surface appears.


Is there a way to turn on/off the writers through the coprocessor.Pipeline 
object, or maybe through arguments to WriteData?


As always, thanks for your help.


Tim


From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Tuesday, February 7, 2017 10:05 AM

To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Pipeline update with Catalyst

The pipeline is update mechanism is often called a lazy update scheme meaning 
only do the requested work and no more. If the UpdateProducers() method 
automatically updated all of the filters there would be a lot of unneeded work 
that would be done. Think about a Catalyst script that branched into 3 separate 
outputs with a lot of work done in each branch. If only one output was wanted 
during a time step that could potentially be a lot of extra, unneeded work.

As for parallel communication in Catalyst, again it's an efficiency thing 
meaning that if we can avoid communication we may as well do it. In interactive 
mode (i.e. through the GUI) it's useful to know things like the total number of 
points and cells, bounds and field ranges which requires communication. In 
Catalyst this information isn't usually needed so that's the type of 
information that would need to be globally communicated. For filters like the 
Integrate Attributes filter, you should get the same behavior in the GUI as in 
Catalyst with regard to parallel output since the filter itself does not know 
how ParaView is running. Some filters (e.g. Resample with Dataset) though only 
have non-empty results on process 0 so it is definitely safest to check filters 
like Integrate Attributes in parallel.

Cheers,
Andy


On Tue, Feb 7, 2017 at 7:51 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...

Re: [Paraview] Pipeline update with Catalyst

[Gallagher, Timothy P]

Along those lines, is it possible to turn on/off specific data writers based on 
something other than time step number?


I have the data collection based on something from IntegrateVariables (it did 
require a broadcast from root), but I am creating multiple surfaces and would 
like to only save the data files when the surface appears.


Is there a way to turn on/off the writers through the coprocessor.Pipeline 
object, or maybe through arguments to WriteData?


As always, thanks for your help.


Tim


From: Andy Bauer <andy.ba...@kitware.com>
Sent: Tuesday, February 7, 2017 10:05 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Pipeline update with Catalyst

The pipeline is update mechanism is often called a lazy update scheme meaning 
only do the requested work and no more. If the UpdateProducers() method 
automatically updated all of the filters there would be a lot of unneeded work 
that would be done. Think about a Catalyst script that branched into 3 separate 
outputs with a lot of work done in each branch. If only one output was wanted 
during a time step that could potentially be a lot of extra, unneeded work.

As for parallel communication in Catalyst, again it's an efficiency thing 
meaning that if we can avoid communication we may as well do it. In interactive 
mode (i.e. through the GUI) it's useful to know things like the total number of 
points and cells, bounds and field ranges which requires communication. In 
Catalyst this information isn't usually needed so that's the type of 
information that would need to be globally communicated. For filters like the 
Integrate Attributes filter, you should get the same behavior in the GUI as in 
Catalyst with regard to parallel output since the filter itself does not know 
how ParaView is running. Some filters (e.g. Resample with Dataset) though only 
have non-empty results on process 0 so it is definitely safest to check filters 
like Integrate Attributes in parallel.

Cheers,
Andy


On Tue, Feb 7, 2017 at 7:51 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Thanks Andy,


I had a feeling the pipeline had to be manually updated. I thought maybe the 
UpdateProducers also updated the pipeline. Thanks for clarifying that.


I also have the same concern about the value stored in each block's CellData 
field. I couldn't find any documentation that indicates how the 
IntegrateVariables filter distributes the data. But, looking at the block VTK 
files that are written out, they all contain the same value of Area so I think 
a global reduction is done in the filter and all blocks have the total values. 
I could be wrong though.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Tuesday, February 7, 2017 7:44 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Pipeline update with Catalyst

Hi Tim,

The short answer is that  you need to do 
coprocessor.Pipeline.flameArea.UpdatePipeline() before checking for the area. 
You also may need to use MPI to do the global sum or broadcast of the value 
since I think that value will either just have local values or maybe just the 
proper global value on processor 0. You should have access to mpi4py in the 
Python script in order to do that.

The long answer is that ParaView & VTK use a demand-driven pipeline design 
meaning that until something explicitly tells a pipeline to update it won't. 
For the Catalyst scripts this is done in the coprocessor.WriteData(), 
coprocessor.WriteImages() and coprocessor.DoLiveVisualization() calls for each 
output that is required (e.g. for a writer that is supposed to output at that 
time step but not for other writers that are not supposed to output at that 
time step). You can manually force a filter to update by using the 
UpdatePipeline() method which will update that pipeline along with everything 
it depends on. It won't update any filters though that don't have an effect on 
it computing its requested information which means that for the flameArea 
filter it won't affect any writers or image output stuff which is what you want.

There is some information on Catayst script details at 
https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/ but I 
don't think that contains this information.
[https://blog.kitware.com/source/files/Small.4_447936566.jpg]<https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/>

Anatomy of a ParaView Catalyst Python Script | The Kitware 
...<https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/>
blog.kitware.com<http://blog.kitware.com>
Introduction. ParaView Catalyst has yielded some amazing results. Such results 
include iso-surfacing and generating images with 256K Message Passing Interface

Re: [Paraview] Pipeline update with Catalyst

[Gallagher, Timothy P]

Thanks Andy,


I had a feeling the pipeline had to be manually updated. I thought maybe the 
UpdateProducers also updated the pipeline. Thanks for clarifying that.


I also have the same concern about the value stored in each block's CellData 
field. I couldn't find any documentation that indicates how the 
IntegrateVariables filter distributes the data. But, looking at the block VTK 
files that are written out, they all contain the same value of Area so I think 
a global reduction is done in the filter and all blocks have the total values. 
I could be wrong though.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Tuesday, February 7, 2017 7:44 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Pipeline update with Catalyst

Hi Tim,

The short answer is that  you need to do 
coprocessor.Pipeline.flameArea.UpdatePipeline() before checking for the area. 
You also may need to use MPI to do the global sum or broadcast of the value 
since I think that value will either just have local values or maybe just the 
proper global value on processor 0. You should have access to mpi4py in the 
Python script in order to do that.

The long answer is that ParaView & VTK use a demand-driven pipeline design 
meaning that until something explicitly tells a pipeline to update it won't. 
For the Catalyst scripts this is done in the coprocessor.WriteData(), 
coprocessor.WriteImages() and coprocessor.DoLiveVisualization() calls for each 
output that is required (e.g. for a writer that is supposed to output at that 
time step but not for other writers that are not supposed to output at that 
time step). You can manually force a filter to update by using the 
UpdatePipeline() method which will update that pipeline along with everything 
it depends on. It won't update any filters though that don't have an effect on 
it computing its requested information which means that for the flameArea 
filter it won't affect any writers or image output stuff which is what you want.

There is some information on Catayst script details at 
https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/ but I 
don't think that contains this information.
[https://blog.kitware.com/source/files/Small.4_447936566.jpg]<https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/>

Anatomy of a ParaView Catalyst Python Script | The Kitware 
...<https://blog.kitware.com/anatomy-of-a-paraview-catalyst-python-script/>
blog.kitware.com
Introduction. ParaView Catalyst has yielded some amazing results. Such results 
include iso-surfacing and generating images with 256K Message Passing Interface 
(MPI ...



Cheers,
Andy

On Tue, Feb 7, 2017 at 7:14 AM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hello again,


I am working on a pipeline using Catalyst that writes data only when features 
are detected. The idea is to have a 3D contour generated in the pipeline, and 
when it is big enough, start recording data. There is a long lead-up to when 
the features appear, and then they disappear rapidly, so I would like to only 
collect data when the features are present.


To that end, my DoCoProcessing() function has something that checks the 'Area' 
value in the CellData of an IntegrateVariables filter. The full function is 
below. However, this doesn't ever write any images or data. It also doesn't 
throw any errors, so I have a feeling the pipeline isn't actually 
evaluated/updated after the call to UpdateProducers.


So, my question -- at what point in the DoCoProcessing function is the pipeline 
actually evaluated? Do all the filters execute when the UpdatedProducers 
function is called? Or do they only update when the outputs to which they are 
connected are called, ie. WriteData and WriteImages?


Thanks,


Tim


def DoCoProcessing(datadescription):
"Callback to do co-processing for current timestep"
global coprocessor
global lastTime
global deltaT

# Update the coprocessor by providing it the newly generated simulation 
data.
# If the pipeline hasn't been setup yet, this will setup the pipeline.
coprocessor.UpdateProducers(datadescription)

curTime = datadescription.GetTime()

if curTime >= lastTime + deltaT:
  lastTime = curTime

  if coprocessor.Pipeline.flameArea.CellData['Area'] > 1e-9:
# Write output data, if appropriate.
coprocessor.WriteData(datadescription);

# Write image capture (Last arg: rescale lookup table), if appropriate.
coprocessor.WriteImages(datadescription, rescale_lookuptable=False)

# Live Visualization, if enabled.
coprocessor.DoLiveVisualization(datadescription, "localhost", 2)


___
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at 
http:

[Paraview] Pipeline update with Catalyst

[Gallagher, Timothy P]

Hello again,


I am working on a pipeline using Catalyst that writes data only when features 
are detected. The idea is to have a 3D contour generated in the pipeline, and 
when it is big enough, start recording data. There is a long lead-up to when 
the features appear, and then they disappear rapidly, so I would like to only 
collect data when the features are present.


To that end, my DoCoProcessing() function has something that checks the 'Area' 
value in the CellData of an IntegrateVariables filter. The full function is 
below. However, this doesn't ever write any images or data. It also doesn't 
throw any errors, so I have a feeling the pipeline isn't actually 
evaluated/updated after the call to UpdateProducers.


So, my question -- at what point in the DoCoProcessing function is the pipeline 
actually evaluated? Do all the filters execute when the UpdatedProducers 
function is called? Or do they only update when the outputs to which they are 
connected are called, ie. WriteData and WriteImages?


Thanks,


Tim


def DoCoProcessing(datadescription):
"Callback to do co-processing for current timestep"
global coprocessor
global lastTime
global deltaT

# Update the coprocessor by providing it the newly generated simulation 
data.
# If the pipeline hasn't been setup yet, this will setup the pipeline.
coprocessor.UpdateProducers(datadescription)

curTime = datadescription.GetTime()

if curTime >= lastTime + deltaT:
  lastTime = curTime

  if coprocessor.Pipeline.flameArea.CellData['Area'] > 1e-9:
# Write output data, if appropriate.
coprocessor.WriteData(datadescription);

# Write image capture (Last arg: rescale lookup table), if appropriate.
coprocessor.WriteImages(datadescription, rescale_lookuptable=False)

# Live Visualization, if enabled.
coprocessor.DoLiveVisualization(datadescription, "localhost", 2)

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Experimental Data Interpolate/Extrapolate to Custom Volume Mesh

[Gallagher, Timothy P]

If I understand you correctly, you were able to take each experimental plane 
and sample it in a the CFD data on the same plane? Now you would like to stack 
your experimental planes together and interpolate it onto the CFD grid?


I haven't done this, so I'm not sure if it's going to work, but can't you do a 
little preprocessing and then do the steps in reverse from before? What I mean 
is:


1. Take all your experimental planes (u, v, w, x, y) at a given z and 
concatenate the files together, adding the z coordinate at the end, to get (u, 
v, w, x, y, z)

2. Load this into Paraview and use the TableToPoints filter

3. Load your CFD grid

4. Select your TableToPoints filter and do:

a. ResampleWithDataset -- select the TableToPoints as the input and the CFD 
grid as the Source


This should then give you the data points from the experimental data 
interpolated onto the CFD grid.


Does that seem like what you are trying to do?


Tim



From: tree...@gmail.com <tree...@gmail.com> on behalf of Mike Tree 
<tree...@gatech.edu>
Sent: Thursday, December 1, 2016 2:30 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Experimental Data Interpolate/Extrapolate to Custom 
Volume Mesh

Tim,

I successfully used my experimental data planes to sample my CFD data for 
comparison, but now I've got another procedure to tackle.

I am looking to interpolate between my experimental planes and fill in the 
volumetric velocity data. I've spent significant time working with the 
GaussianResample filter, but it seems to eliminate some of my data. 
Specifically, GaussianResample can only interpolate scalars, so I have to 
decompose my velocity vector into its components. This seems to work fine, 
except that when the GaussianResample filter is applied the negative values of 
these components are eliminated. Then, when I re-calculate my velocity vector 
as a sum of the component it is obviously wrong because none of the components 
are permitted to be negative.

Are there any other filters in existence that I can use for interpolation?

Any help will be most appreciated.

-Mike Tree

On Tue, Nov 8, 2016 at 9:42 AM, Mike Tree 
<tree...@gatech.edu<mailto:tree...@gatech.edu>> wrote:
Tim,

Seems pretty straight forward. Thanks! I'll let you know if I have any issues.

-MT

On Mon, Nov 7, 2016 at 12:00 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Mike,


Your state file doesn't work without the data files that go along with it.


That said, here is how you can do it:


1. Load your .dat file and use the TableToPoints filter to create points from 
the data table -- select your x, y, z appropriately

2. Load your CFD data file

3. Select your CFD data file and then do:

a. ResampleWithDataset -- select the CFD data as the Input and the 
TableToPoints as the Source

4. This will give you the data interpolated to the points in the table, if you 
want a plane from this data, apply the Delaunay2D filter and select 
Best-Fitting Plane (if the points are not X-Y points only).


That should give you the data from your CFD simulation on the same plane as 
your PIV data.


I see you are at GT -- let me know if you are still unclear on these steps and 
would like to talk in person.


Tim



From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Mike Tree <tree...@gatech.edu<mailto:tree...@gatech.edu>>
Sent: Tuesday, November 17, 2015 5:32 PM
To: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: [Paraview] Experimental Data Interpolate/Extrapolate to Custom Volume 
Mesh

I have three planes of experimental PIV data with velocity point data in .dat 
format loaded in Paraview. I am hoping to use these planes to 
interpolate/extrapolate velocity values onto a custom volumetric mesh (i.e. 
from a CFD simulation) to compare experimental results with simulation results 
in hopes of validating the simulation. I have attached my Paraview state file. 
Any help will be much appreciated.

Thanks,
-MT

--
Mike Tree, PhD Student
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu<mailto:tree...@gatech.edu>
678-249-0922
[https://mailfoogae.appspot.com/t?sender=adHJlZW0yMkBnbWFpbC5jb20%3D=zerocontent=82092feb-f151-4b75-8a88-41da2f2b684b]?



--
Mike Tree, PhD Candidate
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu<mailto:tree...@gatech.edu>
678-249-0922<tel:(678)%20249-0922>



--
Mike Tree, PhD Candidate
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu<mailto:tree...@gatech.edu>
678-249-0922
___
Powered by www.kitware.com

Visit other Kitware open-source pro

Re: [Paraview] Experimental Data Interpolate/Extrapolate to Custom Volume Mesh

[Gallagher, Timothy P]

Mike,


Your state file doesn't work without the data files that go along with it.


That said, here is how you can do it:


1. Load your .dat file and use the TableToPoints filter to create points from 
the data table -- select your x, y, z appropriately

2. Load your CFD data file

3. Select your CFD data file and then do:

a. ResampleWithDataset -- select the CFD data as the Input and the 
TableToPoints as the Source

4. This will give you the data interpolated to the points in the table, if you 
want a plane from this data, apply the Delaunay2D filter and select 
Best-Fitting Plane (if the points are not X-Y points only).


That should give you the data from your CFD simulation on the same plane as 
your PIV data.


I see you are at GT -- let me know if you are still unclear on these steps and 
would like to talk in person.


Tim



From: ParaView  on behalf of Mike Tree 

Sent: Tuesday, November 17, 2015 5:32 PM
To: paraview@paraview.org
Subject: [Paraview] Experimental Data Interpolate/Extrapolate to Custom Volume 
Mesh

I have three planes of experimental PIV data with velocity point data in .dat 
format loaded in Paraview. I am hoping to use these planes to 
interpolate/extrapolate velocity values onto a custom volumetric mesh (i.e. 
from a CFD simulation) to compare experimental results with simulation results 
in hopes of validating the simulation. I have attached my Paraview state file. 
Any help will be much appreciated.

Thanks,
-MT

--
Mike Tree, PhD Student
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu
678-249-0922
[https://mailfoogae.appspot.com/t?sender=adHJlZW0yMkBnbWFpbC5jb20%3D=zerocontent=82092feb-f151-4b75-8a88-41da2f2b684b]?
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Loading XML configuration file from pvpython

[Gallagher, Timothy P]

Hello,


I have a programmable filter that is wrapped into a custom plugin using an XML 
configuration file. If I use the GUI and go to the Manage Plugins and load it, 
everything is fine.


However, I can't figure out how to load it inside pvpython. I am trying to do:


servermanager.ProxyManager().LoadConfigurationXML("/path/to/my_plugin.xml")
servermanager.updateModules(servermanager)

but that gives me:

ERROR: In ParaView/VTK/IO/XMLParser/vtkXMLParser.cxx, line 483
vtkPVXMLParser (0x2cb9b80): Error parsing XML in stream at line 1, column 0, 
byte index 0: not well-formed (invalid token)

I looked through the header files and the C++ classes have a 
LoadConfigurationXML, which takes a vtkPVXMLElement, and a 
LoadConfigurationXMLFromString which takes a const char pointer. I can call the 
former, but the latter does not seem to be exposed through the python interface.

Is it not possible to pass the file name in as the argument here like it is 
with LoadCustomProxyDefinitions()? Is there something I'm missing?

Thanks,

Tim

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Non-blocking coprocessing

[Gallagher, Timothy P]

Hello again!


I'm looking at using coprocessing for something that may take awhile to 
actually compute, so I would like to do it in a non-blocking fashion. 
Essentially I am going to be extracting data from the simulation into some 
numpy arrays (so once copied, the original data in the pipeline can change) and 
then send it to the root processor to do some global operations.


The global operations may take some time (not minutes, but longer than I want 
my simulation to wait for it to complete). Is there a way to do part of the 
pipeline in a non-blocking fashion, where the script calls a function that will 
write out a data file when processing and then returns control to the 
simulation prior to the function completion? Will I have to do something in 
native-python, like spawn a new thread to do the function call, or is there a 
way to do it with how Paraview operates?


On a related note, I may not want to have the root processor of the 
coprocessing to have any simulation code running on it. If I am running my 
simulation on N cores, is it possible to have N+1 cores running the coprocessor 
pipeline where the extra core receives the global data reduction from the N 
cores and does the crunching? Or am I starting to ask for too much there?


Thanks as always,


Tim
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Function JOIN of XDMF in Paraview

[Gallagher, Timothy P]

The thing that jumps out at me is missing the Dimensions tag on the function 
itself. For instance, we create our grids as:



grid.h5:/Domain_1/x
grid.h5:/Domain_1/y
grid.h5:/Domain_1/z



We also use a comma between the JOIN, not a semicolon -- not sure if that 
matters or not.


If you change your JOIN to look like:




  EvolvingSquare_01.h5:Coordinates

  EvolvingSquare_02.h5:Coordinates




does that fix the problem?


Tim


From: ParaView  on behalf of dl...@cornell.edu 

Sent: Monday, September 19, 2016 10:20 PM
To: paraview@paraview.org
Subject: [Paraview] Function JOIN of XDMF in Paraview


Hi,

I am now working on a project which needs the use of JOIN function in xdmf to 
concatenate the data from multiple h5 files and visualize those files in 
Paraview. I have created a small trial to test this JOIN function. I create two 
h5 files, each of which contains two points of a unit square. For each point, I 
assign a value to it as its attribute. Then I write one xdmf file, which uses 
function JOIN to concatenate the dataset from two h5 files. But when I load my 
xdmf file into Paraview, Paraview just crashes directly.  This is the xdmf file 
I have written:





http://www.w3.org/2001/XInclude; Version="2.97">

  



  



  EvolvingSquare_01.h5:Coordinates

 EvolvingSquare_02.h5:Coordinates



  

  

  



  EvolvingSquare_01.h5:Attributes

  EvolvingSquare_02.h5:Attributes



  



  





To avoid the problem of h5 file itself, I have also written two separate xdmf 
files for each h5 file and load each xdmf file separately into Paraview. I can 
successfully load these two h5 files separately into Paraview, so the problem 
might no be my h5 files. Can anyone help me with this problem? Are there any 
mistakes of my ways of using JOIN function in xdmf?

Thanks


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Function JOIN of XDMF in Paraview

[Gallagher, Timothy P]

Maybe to be more clear (because there are some differences in the grid 
definition in some other places), here is what our full grid definition looks 
like:


   



/grid.h5:/Domain_1/x
/grid.h5:/Domain_1/y
/grid.h5:/Domain_1/z






The first difference is the 2DSMesh in yours instead of the 3DSMesh in mine. 
But we also use Dimensions in the Topology tag (instead of the 
NumberOfElements). We also interleave our coordinates (that's what the comma 
does) instead of appending the arrays (that's what the semicolon does) in the 
JOIN.


I would skip the attribute for now and focus on getting the format correct for 
the coordinates, and then look at the attribute. We also use the JOIN to create 
velocity vectors from individual arrays and it follows the same format as the 
grid coordinates.


Tim


From: Gallagher, Timothy P
Sent: Monday, September 19, 2016 10:41 PM
To: dl...@cornell.edu; paraview@paraview.org
Subject: Re: [Paraview] Function JOIN of XDMF in Paraview


The thing that jumps out at me is missing the Dimensions tag on the function 
itself. For instance, we create our grids as:



grid.h5:/Domain_1/x
grid.h5:/Domain_1/y
grid.h5:/Domain_1/z



We also use a comma between the JOIN, not a semicolon -- not sure if that 
matters or not.


If you change your JOIN to look like:




  EvolvingSquare_01.h5:Coordinates

  EvolvingSquare_02.h5:Coordinates




does that fix the problem?


Tim


From: ParaView <paraview-boun...@paraview.org> on behalf of dl...@cornell.edu 
<dl...@cornell.edu>
Sent: Monday, September 19, 2016 10:20 PM
To: paraview@paraview.org
Subject: [Paraview] Function JOIN of XDMF in Paraview


Hi，

I am now working on a project which needs the use of JOIN function in xdmf to 
concatenate the data from multiple h5 files and visualize those files in 
Paraview. I have created a small trial to test this JOIN function. I create two 
h5 files, each of which contains two points of a unit square. For each point, I 
assign a value to it as its attribute. Then I write one xdmf file, which uses 
function JOIN to concatenate the dataset from two h5 files. But when I load my 
xdmf file into Paraview, Paraview just crashes directly.  This is the xdmf file 
I have written:





http://www.w3.org/2001/XInclude; Version="2.97">

  



  



  EvolvingSquare_01.h5:Coordinates

 EvolvingSquare_02.h5:Coordinates



  

  

  



  EvolvingSquare_01.h5:Attributes

  EvolvingSquare_02.h5:Attributes



  



  





To avoid the problem of h5 file itself, I have also written two separate xdmf 
files for each h5 file and load each xdmf file separately into Paraview. I can 
successfully load these two h5 files separately into Paraview, so the problem 
might no be my h5 files. Can anyone help me with this problem? Are there any 
mistakes of my ways of using JOIN function in xdmf?

Thanks


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

Hi Utkarsh,


Have you had a chance to take a look at this yet? I will have some time later 
this week to pick it back up -- just wanted to check if there was anything new 
about it before I dove back in.


Thanks,


Tim



From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Tuesday, August 30, 2016 7:51 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Thanks, Tim. I'll take a look in next few days.

Utkarsh

On Mon, Aug 29, 2016 at 4:12 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

I have to throw in the towel on this one for now and get back to some other 
deadlines... but, I put what I have so far online and created a merge request 
with information about the error and an example dataset attached.


Hopefully somebody better with VTK than I am can take a look and figure out 
what I'm missing. I tried comparing the files for Chombo against the original 
Visit source files to see if any special modifications were required and none 
are (the only changes are HDF5 related). It looks like the Chombo reader is 
from Visit 2.7.0 -- the Boxlib files I added are from 2.10.3, but I tried it 
with the Boxlib reader from Visit 2.7.0 also and it's the same issue.


If anybody has a chance to take a look, I'd appreciate it. Hopefully it's 
something simple. If not, I'll try to pick it back up in a few days. I 
apologize for the hacked CMakeLists to link against the library, I will fix it 
to do it properly once everything else works!


Tim



From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>>
Sent: Monday, August 29, 2016 12:41 PM

To: Utkarsh Ayachit
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader


Thanks for the quick response, the case didn't match between the two files and 
that was the issue. I'm able to use the reader to select the file and it sees 
the names of the variables in it properly, but when I hit Apply it throws:


ERROR: In 
/data4/PVBoxLibTest/paraview/VTK/Common/DataModel/vtkAMRInformation.cxx, line 
573
vtkAMRInformation (0x44210f0): Invalid grid description for a vtkUniformGrid


I have a feeling this might get beyond my paraview knowledge to fix.


One potential source of the problem -- what version of Visit are the other 
readers pulled from? I have the Boxlib files from the latest version, but 
looking at some of the other readers, they are from older versions.

The latest date I see in the copyright for existing readers is 2013 and looking 
through the Visit Release notes, the last release in 2013 says it was upgraded 
to use VTK-6.0.


Is it possible the bridge is based on Visit before that major VTK upgrade and I 
need to pull the reader code from a version earlier than that?


Thanks for your help. If I can't find something I know how to fix soon, I can 
create a merge request and see if anybody else can get it the rest of the way.


Tim


From: Utkarsh Ayachit 
<utkarsh.ayac...@kitware.com<mailto:utkarsh.ayac...@kitware.com>>
Sent: Monday, August 29, 2016 12:17 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

It doesn't know what the class is. Multiple things could have gone wrong:
1. is there call to ADD_VISIT_READER() for the new reader?
2. does the case match between the XML's class="" and the name specified in 1?

If it makes it easier, create a MR on the 
https://gitlab.kitware.com/paraview/visitbridge repo with your changes, and I 
can do the necessary fixes.
[https://gitlab.kitware.com/uploads/project/avatar/12/VisitBridge_Icon__3_.png]<https://gitlab.kitware.com/paraview/visitbridge>

ParaView / VisItBridge<https://gitlab.kitware.com/paraview/visitbridge>
gitlab.kitware.com<http://gitlab.kitware.com>
Bridge between VisIt and ParaView to use VisIt readers in ParaView.


Utkarsh

On Mon, Aug 29, 2016 at 12:06 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Utkarash,


Thanks, I had added it to the xml file, but I didn't reconfigure (just rebuilt) 
so it didn't get added to the list.


I'm making some progress it seems, it is picking the right reader now. But it 
is crashing with a rather unhelpful message:


ERROR: In 
/data4/PVBoxLibTest/paraview/ParaViewCore/ServerImplementation/Core/vtkSIProxy.cxx,
 line 310
vtkSISourceProxy (0x3e87420): Failed to create vtkVisItBoxlib2DReader. Aborting 
for debugging purposes.


I thought compiling with a Debug build type would give more verbose messages, 
but it's the same.


Is there documentation or su

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

I have to throw in the towel on this one for now and get back to some other 
deadlines... but, I put what I have so far online and created a merge request 
with information about the error and an example dataset attached.


Hopefully somebody better with VTK than I am can take a look and figure out 
what I'm missing. I tried comparing the files for Chombo against the original 
Visit source files to see if any special modifications were required and none 
are (the only changes are HDF5 related). It looks like the Chombo reader is 
from Visit 2.7.0 -- the Boxlib files I added are from 2.10.3, but I tried it 
with the Boxlib reader from Visit 2.7.0 also and it's the same issue.


If anybody has a chance to take a look, I'd appreciate it. Hopefully it's 
something simple. If not, I'll try to pick it back up in a few days. I 
apologize for the hacked CMakeLists to link against the library, I will fix it 
to do it properly once everything else works!


Tim



From: ParaView <paraview-boun...@paraview.org> on behalf of Gallagher, Timothy 
P <tim.gallag...@gatech.edu>
Sent: Monday, August 29, 2016 12:41 PM
To: Utkarsh Ayachit
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader


Thanks for the quick response, the case didn't match between the two files and 
that was the issue. I'm able to use the reader to select the file and it sees 
the names of the variables in it properly, but when I hit Apply it throws:


ERROR: In 
/data4/PVBoxLibTest/paraview/VTK/Common/DataModel/vtkAMRInformation.cxx, line 
573
vtkAMRInformation (0x44210f0): Invalid grid description for a vtkUniformGrid


I have a feeling this might get beyond my paraview knowledge to fix.


One potential source of the problem -- what version of Visit are the other 
readers pulled from? I have the Boxlib files from the latest version, but 
looking at some of the other readers, they are from older versions.

The latest date I see in the copyright for existing readers is 2013 and looking 
through the Visit Release notes, the last release in 2013 says it was upgraded 
to use VTK-6.0.


Is it possible the bridge is based on Visit before that major VTK upgrade and I 
need to pull the reader code from a version earlier than that?


Thanks for your help. If I can't find something I know how to fix soon, I can 
create a merge request and see if anybody else can get it the rest of the way.


Tim


From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Monday, August 29, 2016 12:17 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

It doesn't know what the class is. Multiple things could have gone wrong:
1. is there call to ADD_VISIT_READER() for the new reader?
2. does the case match between the XML's class="" and the name specified in 1?

If it makes it easier, create a MR on the 
https://gitlab.kitware.com/paraview/visitbridge repo with your changes, and I 
can do the necessary fixes.
[https://gitlab.kitware.com/uploads/project/avatar/12/VisitBridge_Icon__3_.png]<https://gitlab.kitware.com/paraview/visitbridge>

ParaView / VisItBridge<https://gitlab.kitware.com/paraview/visitbridge>
gitlab.kitware.com
Bridge between VisIt and ParaView to use VisIt readers in ParaView.


Utkarsh

On Mon, Aug 29, 2016 at 12:06 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Utkarash,


Thanks, I had added it to the xml file, but I didn't reconfigure (just rebuilt) 
so it didn't get added to the list.


I'm making some progress it seems, it is picking the right reader now. But it 
is crashing with a rather unhelpful message:


ERROR: In 
/data4/PVBoxLibTest/paraview/ParaViewCore/ServerImplementation/Core/vtkSIProxy.cxx,
 line 310
vtkSISourceProxy (0x3e87420): Failed to create vtkVisItBoxlib2DReader. Aborting 
for debugging purposes.


I thought compiling with a Debug build type would give more verbose messages, 
but it's the same.


Is there documentation or suggestions on debugging paraview? Is there a way to 
get more verbose output on why it isn't able to create the reader?


Thanks again,


Tim


From: Utkarsh Ayachit 
<utkarsh.ayac...@kitware.com<mailto:utkarsh.ayac...@kitware.com>>
Sent: Monday, August 29, 2016 8:46 AM

To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

Did you also add it to visit_readers.xml [1]? The proxy definition should also 
have a   section like so [2].

Utkarsh

[1] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml
[2] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml#L2562-2565



On Fri, Aug 26, 2016 at 6:26 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@g

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

Utkarash,


Thanks, I had added it to the xml file, but I didn't reconfigure (just rebuilt) 
so it didn't get added to the list.


I'm making some progress it seems, it is picking the right reader now. But it 
is crashing with a rather unhelpful message:


ERROR: In 
/data4/PVBoxLibTest/paraview/ParaViewCore/ServerImplementation/Core/vtkSIProxy.cxx,
 line 310
vtkSISourceProxy (0x3e87420): Failed to create vtkVisItBoxlib2DReader. Aborting 
for debugging purposes.


I thought compiling with a Debug build type would give more verbose messages, 
but it's the same.


Is there documentation or suggestions on debugging paraview? Is there a way to 
get more verbose output on why it isn't able to create the reader?


Thanks again,


Tim


From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Monday, August 29, 2016 8:46 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

Did you also add it to visit_readers.xml [1]? The proxy definition should also 
have a   section like so [2].

Utkarsh

[1] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml
[2] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml#L2562-2565



On Fri, Aug 26, 2016 at 6:26 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

I took a stab at adding the Boxlib reader from the visit source to the 
VisitBridge internal readers. I managed to get everything to compile and link, 
Paraview built fine, but I can't seem to figure out how to make Paraview aware 
the reader exists.


There isn't an option for Boxlib in the dropdown for the file type when I try 
to open a file, and it doesn't appear as an available reader when I try to 
select the file -- although all the others from the VisitBridge appear. I 
missed a configuration file somewhere to make the file loading aware of the 
reader.


Any suggestions on what I missed? I added a section in the 
Utilities/VisItBridge/databases/visit_readers.xml file, but that wasn't enough 
I guess.


Thanks,


Tim



From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>>
Sent: Friday, August 26, 2016 11:53 AM
To: Utkarsh Ayachit

Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader


Hi Utkarsh,


I just checked with the latest head of the git repo and when I compile with the 
VisitBridge, there are no readers for BoxLib built.


This page lists it as supported: 
http://www.paraview.org/ParaView/index.php/VisIt_avt_Integration


But then this later one doesn't include it: 
http://www.paraview.org/Wiki/VisIt_Database_Bridge


I have a dataset for you, I will send it off-list.


Thanks,


Tim



From: Utkarsh Ayachit 
<utkarsh.ayac...@kitware.com<mailto:utkarsh.ayac...@kitware.com>>
Sent: Friday, August 26, 2016 8:35 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

I am not exactly sure what's the status of the reader, but I can
certainly look it up. Do you have a sample dataset also to test that
it's working (or not)?

Utkarsh

On Thu, Aug 25, 2016 at 2:22 PM, Gallagher, Timothy P
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:
> Hi,
>
>
> Our code is moving away from traditional structured grids towards an AMR
> capability using BoxLib. That means, unfortunately, that all of the
> development we have done to make our code Paraview and CoProcessing friendly
> is not usable with the BoxLib file format.
>
>
> I have seen some information on various websites about using the VisitBridge
> to add the readers from Visit into Paraview, but when I build with it, the
> BoxLib reader was not included in the list of formats I could use for files
> -- even though it is listed online.
>
>
> Does anybody know what the status is of the reader in PV and if it is
> usable? Or is there a different format we can try to write out from our code
> that would be usable? I really don't want to lose the work we've done with
> PV and I would rather spend time writing code to get things working again
> for PV than learn to use new software!
>
>
> Thanks,
>
>
> Tim
>
>
> ___
> Powered by www.kitware.com<http://www.kitware.com>
[http://www.kitware.com/img/Areas_Index_Home.jpg]<http://www.kitware.com/>

Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/>
www.kitware.com<http://www.kitware.com>
Kitware's mission is to create

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

Thanks for the quick response, the case didn't match between the two files and 
that was the issue. I'm able to use the reader to select the file and it sees 
the names of the variables in it properly, but when I hit Apply it throws:


ERROR: In 
/data4/PVBoxLibTest/paraview/VTK/Common/DataModel/vtkAMRInformation.cxx, line 
573
vtkAMRInformation (0x44210f0): Invalid grid description for a vtkUniformGrid


I have a feeling this might get beyond my paraview knowledge to fix.


One potential source of the problem -- what version of Visit are the other 
readers pulled from? I have the Boxlib files from the latest version, but 
looking at some of the other readers, they are from older versions.

The latest date I see in the copyright for existing readers is 2013 and looking 
through the Visit Release notes, the last release in 2013 says it was upgraded 
to use VTK-6.0.


Is it possible the bridge is based on Visit before that major VTK upgrade and I 
need to pull the reader code from a version earlier than that?


Thanks for your help. If I can't find something I know how to fix soon, I can 
create a merge request and see if anybody else can get it the rest of the way.


Tim


From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Monday, August 29, 2016 12:17 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

It doesn't know what the class is. Multiple things could have gone wrong:
1. is there call to ADD_VISIT_READER() for the new reader?
2. does the case match between the XML's class="" and the name specified in 1?

If it makes it easier, create a MR on the 
https://gitlab.kitware.com/paraview/visitbridge repo with your changes, and I 
can do the necessary fixes.
[https://gitlab.kitware.com/uploads/project/avatar/12/VisitBridge_Icon__3_.png]<https://gitlab.kitware.com/paraview/visitbridge>

ParaView / VisItBridge<https://gitlab.kitware.com/paraview/visitbridge>
gitlab.kitware.com
Bridge between VisIt and ParaView to use VisIt readers in ParaView.


Utkarsh

On Mon, Aug 29, 2016 at 12:06 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Utkarash,


Thanks, I had added it to the xml file, but I didn't reconfigure (just rebuilt) 
so it didn't get added to the list.


I'm making some progress it seems, it is picking the right reader now. But it 
is crashing with a rather unhelpful message:


ERROR: In 
/data4/PVBoxLibTest/paraview/ParaViewCore/ServerImplementation/Core/vtkSIProxy.cxx,
 line 310
vtkSISourceProxy (0x3e87420): Failed to create vtkVisItBoxlib2DReader. Aborting 
for debugging purposes.


I thought compiling with a Debug build type would give more verbose messages, 
but it's the same.


Is there documentation or suggestions on debugging paraview? Is there a way to 
get more verbose output on why it isn't able to create the reader?


Thanks again,


Tim


From: Utkarsh Ayachit 
<utkarsh.ayac...@kitware.com<mailto:utkarsh.ayac...@kitware.com>>
Sent: Monday, August 29, 2016 8:46 AM

To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

Did you also add it to visit_readers.xml [1]? The proxy definition should also 
have a   section like so [2].

Utkarsh

[1] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml
[2] 
https://gitlab.kitware.com/paraview/visitbridge/blob/master/databases/visit_readers.xml#L2562-2565



On Fri, Aug 26, 2016 at 6:26 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

I took a stab at adding the Boxlib reader from the visit source to the 
VisitBridge internal readers. I managed to get everything to compile and link, 
Paraview built fine, but I can't seem to figure out how to make Paraview aware 
the reader exists.


There isn't an option for Boxlib in the dropdown for the file type when I try 
to open a file, and it doesn't appear as an available reader when I try to 
select the file -- although all the others from the VisitBridge appear. I 
missed a configuration file somewhere to make the file loading aware of the 
reader.


Any suggestions on what I missed? I added a section in the 
Utilities/VisItBridge/databases/visit_readers.xml file, but that wasn't enough 
I guess.


Thanks,


Tim



From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>>
Sent: Friday, August 26, 2016 11:53 AM
To: Utkarsh Ayachit

Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Status of BoxLib AMR reader


Hi Utkarsh,


I just checked with the latest head of the git repo and when I com

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

I took a stab at adding the Boxlib reader from the visit source to the 
VisitBridge internal readers. I managed to get everything to compile and link, 
Paraview built fine, but I can't seem to figure out how to make Paraview aware 
the reader exists.


There isn't an option for Boxlib in the dropdown for the file type when I try 
to open a file, and it doesn't appear as an available reader when I try to 
select the file -- although all the others from the VisitBridge appear. I 
missed a configuration file somewhere to make the file loading aware of the 
reader.


Any suggestions on what I missed? I added a section in the 
Utilities/VisItBridge/databases/visit_readers.xml file, but that wasn't enough 
I guess.


Thanks,


Tim



From: ParaView <paraview-boun...@paraview.org> on behalf of Gallagher, Timothy 
P <tim.gallag...@gatech.edu>
Sent: Friday, August 26, 2016 11:53 AM
To: Utkarsh Ayachit
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader


Hi Utkarsh,


I just checked with the latest head of the git repo and when I compile with the 
VisitBridge, there are no readers for BoxLib built.


This page lists it as supported: 
http://www.paraview.org/ParaView/index.php/VisIt_avt_Integration


But then this later one doesn't include it: 
http://www.paraview.org/Wiki/VisIt_Database_Bridge


I have a dataset for you, I will send it off-list.


Thanks,


Tim



From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Friday, August 26, 2016 8:35 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

I am not exactly sure what's the status of the reader, but I can
certainly look it up. Do you have a sample dataset also to test that
it's working (or not)?

Utkarsh

On Thu, Aug 25, 2016 at 2:22 PM, Gallagher, Timothy P
<tim.gallag...@gatech.edu> wrote:
> Hi,
>
>
> Our code is moving away from traditional structured grids towards an AMR
> capability using BoxLib. That means, unfortunately, that all of the
> development we have done to make our code Paraview and CoProcessing friendly
> is not usable with the BoxLib file format.
>
>
> I have seen some information on various websites about using the VisitBridge
> to add the readers from Visit into Paraview, but when I build with it, the
> BoxLib reader was not included in the list of formats I could use for files
> -- even though it is listed online.
>
>
> Does anybody know what the status is of the reader in PV and if it is
> usable? Or is there a different format we can try to write out from our code
> that would be usable? I really don't want to lose the work we've done with
> PV and I would rather spend time writing code to get things working again
> for PV than learn to use new software!
>
>
> Thanks,
>
>
> Tim
>
>
> ___
> Powered by www.kitware.com<http://www.kitware.com>
[http://www.kitware.com/img/Areas_Index_Home.jpg]<http://www.kitware.com/>

Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/>
www.kitware.com
Kitware's mission is to create state-of-the-art software products and services 
in visualization and data processing using advanced quality software methods 
and ...


>
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

Hi Utkarsh,


I just checked with the latest head of the git repo and when I compile with the 
VisitBridge, there are no readers for BoxLib built.


This page lists it as supported: 
http://www.paraview.org/ParaView/index.php/VisIt_avt_Integration


But then this later one doesn't include it: 
http://www.paraview.org/Wiki/VisIt_Database_Bridge


I have a dataset for you, I will send it off-list.


Thanks,


Tim



From: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Sent: Friday, August 26, 2016 8:35 AM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Status of BoxLib AMR reader

Tim,

I am not exactly sure what's the status of the reader, but I can
certainly look it up. Do you have a sample dataset also to test that
it's working (or not)?

Utkarsh

On Thu, Aug 25, 2016 at 2:22 PM, Gallagher, Timothy P
<tim.gallag...@gatech.edu> wrote:
> Hi,
>
>
> Our code is moving away from traditional structured grids towards an AMR
> capability using BoxLib. That means, unfortunately, that all of the
> development we have done to make our code Paraview and CoProcessing friendly
> is not usable with the BoxLib file format.
>
>
> I have seen some information on various websites about using the VisitBridge
> to add the readers from Visit into Paraview, but when I build with it, the
> BoxLib reader was not included in the list of formats I could use for files
> -- even though it is listed online.
>
>
> Does anybody know what the status is of the reader in PV and if it is
> usable? Or is there a different format we can try to write out from our code
> that would be usable? I really don't want to lose the work we've done with
> PV and I would rather spend time writing code to get things working again
> for PV than learn to use new software!
>
>
> Thanks,
>
>
> Tim
>
>
> ___
> Powered by www.kitware.com<http://www.kitware.com>
[http://www.kitware.com/img/Areas_Index_Home.jpg]<http://www.kitware.com/>

Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/>
www.kitware.com
Kitware's mission is to create state-of-the-art software products and services 
in visualization and data processing using advanced quality software methods 
and ...


>
> 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
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Status of BoxLib AMR reader

[Gallagher, Timothy P]

Hi,


Our code is moving away from traditional structured grids towards an AMR 
capability using BoxLib. That means, unfortunately, that all of the development 
we have done to make our code Paraview and CoProcessing friendly is not usable 
with the BoxLib file format.


I have seen some information on various websites about using the VisitBridge to 
add the readers from Visit into Paraview, but when I build with it, the BoxLib 
reader was not included in the list of formats I could use for files -- even 
though it is listed online.


Does anybody know what the status is of the reader in PV and if it is usable? 
Or is there a different format we can try to write out from our code that would 
be usable? I really don't want to lose the work we've done with PV and I would 
rather spend time writing code to get things working again for PV than learn to 
use new software!


Thanks,


Tim
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

I am using the multiblock format, so I am definitely interested in the 
solution. Hopefully Utkarsh sees this and can chime in.


Thanks!


Tim



From: Burlen Loring <burlen.lor...@gmail.com>
Sent: Monday, May 23, 2016 3:30 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


I think there is an api in the multi-block writer to disable writing metadata. 
Utkarsh knows, he's the one that figured it out. not sure how it applies to 
your use case. you may not even be using multi-block format...

On 05/23/2016 06:57 AM, Gallagher, Timothy P wrote:

Interesting -- I'd be willing to try it out if you have more details (commit 
hashtag, ticket, etc.), even if I have to figure out how to backport it from a 
newer version.


Thanks,


Tim



From: Burlen Loring <burlen.lor...@gmail.com><mailto:burlen.lor...@gmail.com>
Sent: Sunday, May 22, 2016 10:30 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst

btw, we just had similar problem that was entirely explained by vtk writer 
attempting to gather a bunch of arrays to the root node. Utkarsh found a way to 
disable that behavior. I wonder if you are hitting the same.

On 5/20/2016 4:36 PM, Gallagher, Timothy P wrote:

Well... not going so well.


If I run a small simulation with massif and the Release build of paraview, I 
don't see any growing memory in time. I also get my VTK files and images.


If I run the same simulation linked against a Debug build with VTK_DEBUG_LEAKS 
on, there is a segfault inside one of the libvtkRendering libraries (it says 
libvtkRenderingOp but the rest of the name is cut off). If I take the image 
rendering out of my pipeline (comment out the RegisterView call) and leave the 
VTK file writing, it runs fine and doesn't report any leaks. I tried to get the 
segfault to drop a core file, but it won't do it.


I'm thinking that there is an issue in the rendering part causing the leak. I 
have no idea what it could be though -- this is the 4.4.0 version, is anybody 
aware of any bug fixes between 4.4.0 and current versions that might be 
relevant?


Thanks for the help,


Tim





From: ParaView 
<paraview-boun...@paraview.org><mailto:paraview-boun...@paraview.org> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu><mailto:tim.gallag...@gatech.edu>
Sent: Friday, May 20, 2016 4:17 PM
To: Burlen Loring; Andy Bauer
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst


Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring <burlen.lor...@gmail.com><mailto:burlen.lor...@gmail.com>
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com><mailto:andy.ba...@kitware.com>
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: <mailto:paraview@paraview.org> 
paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Cat

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Interesting -- I'd be willing to try it out if you have more details (commit 
hashtag, ticket, etc.), even if I have to figure out how to backport it from a 
newer version.


Thanks,


Tim



From: Burlen Loring <burlen.lor...@gmail.com>
Sent: Sunday, May 22, 2016 10:30 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst

btw, we just had similar problem that was entirely explained by vtk writer 
attempting to gather a bunch of arrays to the root node. Utkarsh found a way to 
disable that behavior. I wonder if you are hitting the same.

On 5/20/2016 4:36 PM, Gallagher, Timothy P wrote:

Well... not going so well.


If I run a small simulation with massif and the Release build of paraview, I 
don't see any growing memory in time. I also get my VTK files and images.


If I run the same simulation linked against a Debug build with VTK_DEBUG_LEAKS 
on, there is a segfault inside one of the libvtkRendering libraries (it says 
libvtkRenderingOp but the rest of the name is cut off). If I take the image 
rendering out of my pipeline (comment out the RegisterView call) and leave the 
VTK file writing, it runs fine and doesn't report any leaks. I tried to get the 
segfault to drop a core file, but it won't do it.


I'm thinking that there is an issue in the rendering part causing the leak. I 
have no idea what it could be though -- this is the 4.4.0 version, is anybody 
aware of any bug fixes between 4.4.0 and current versions that might be 
relevant?


Thanks for the help,


Tim





From: ParaView 
<paraview-boun...@paraview.org><mailto:paraview-boun...@paraview.org> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu><mailto:tim.gallag...@gatech.edu>
Sent: Friday, May 20, 2016 4:17 PM
To: Burlen Loring; Andy Bauer
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst


Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring <burlen.lor...@gmail.com><mailto:burlen.lor...@gmail.com>
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com><mailto:andy.ba...@kitware.com>
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak

Re: [Paraview] capability of ParaView, Catalyst in distributed computing environment ...

[Gallagher, Timothy P]

If you can control which communicator Paraview uses, you might want to look at 
using MPI_INTERCOMM_MERGE, which will take the union of the two disjoint sets 
described by an intercommunicator. So with that, you would create a new 
communicator that has all of your processors as members.

Paraview should be able to use that merged communicator seamlessly because it 
is a single communicator with all of the processor members attached. Meanwhile, 
your individual codes still use their own MPI_COMM_WORLD and the 
intercommunicator when they need to share information. 

That way, the codes do not need to change. Your adapter does the work of 
dealing with the merge process and the managing the merged communicator. 

I haven't tested anything like this of course. Just putting the idea out there.

Tim


From: u.utku.turunco...@be.itu.edu.tr <u.utku.turunco...@be.itu.edu.tr>
Sent: Sunday, May 22, 2016 7:59 AM
To: Andy Bauer
Cc: Ufuk Utku Turuncoglu; Gallagher, Timothy P; paraview@paraview.org
Subject: Re: [Paraview] capability of ParaView,  Catalyst in distributed 
computing environment ...

Thanks for the information. Currently, i am working on two component case
and the initial results show that grid and data information belong to each
model component must be accessible by all the MPI processes (defined in
global MPI_COMM_WORLD) in adaptor side. This makes the implementation very
complex when the 2d decomposition configuration of both model components
(which run in a specific subset of processors) are considered. In this
case, it seems that the easiest way is to interpolate/ redistribute the
data of both components into common grid or creating new 2d decomposition
in adaptor. Another possibility might be to implement MPI sections
specific for each model component (basically having two distinct
MPI_COMM_WORLD inside of global one) to access grid and fields in the
adaptor side but in this case i am not sure ParaView could handle these
kind of information or not. Anyway, it seems that it is a challanging
problem and probably it would be good to have this feature. I'll keep to
continue to try different implementations to test different ideas and keep
you posted about it. In the mean time, if you have any other idea, let me
know.

Regards,

--ufuk

> It may be possible to do this with Catalyst. I would guess that nearly all
> of the complex work would need to be done in the adaptor to integrate this
> properly though.
>
> On Wed, May 18, 2016 at 11:17 AM, <u.utku.turunco...@be.itu.edu.tr> wrote:
>
>> Yes, you are right. In this case, there will be two separate
>> MPI_COMM_WORLD. Plus, one that covers all the resources (let's say that
>> global MPI_COMM_WORLD). Actually, this kind of setup is very common for
>> multi-physics applications such as fluid-structure interaction. So, is
>> it
>> possible to tight this kind of environment with Catalyst? I am not
>> expert
>> about Catalyst but it seems that there might be a problem in the
>> rendering
>> stage even underlying grids and fields are defined without any problem.
>>
>> Regards,
>>
>> --ufuk
>>
>> > I'm not sure if this is exactly what the original user is referring
>> to,
>> > but it is possible to have two separate codes communicate using MPI
>> > through the dynamic processes in MPI-2. Essentially, one program
>> starts
>> up
>> > on N processors and begins running and gets an MPI_COMM_WORLD. It then
>> > spawns another executable on M different processors and that new
>> > executable will call MPI_INIT and also get its own MPI_COMM_WORLD. So
>> you
>> > have two, disjoint MPI_COMM_WORLD's that get linked together through a
>> > newly created intercommunicator.
>> >
>> >
>> > I've used this to couple a structural mechanics code to our fluid
>> dynamics
>> > solver for example. It sounds like that is similar to what is being
>> done
>> > here.
>> >
>> >
>> > How that would interact with coprocessing is beyond my knowledge
>> though.
>> > It does sound like an interesting problem and one I would be very
>> curious
>> > to find out the details.
>> >
>> >
>> > Tim
>> >
>> >
>> > 
>> > From: ParaView <paraview-boun...@paraview.org> on behalf of Andy Bauer
>> > <andy.ba...@kitware.com>
>> > Sent: Wednesday, May 18, 2016 10:52 AM
>> > To: Ufuk Utku Turuncoglu (BE)
>> > Cc: paraview@paraview.org
>> > Subject: Re: [Paraview] capability of ParaView, Catalyst in
>> distributed
>> > computing environment ...
>> >
&g

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Well... not going so well.


If I run a small simulation with massif and the Release build of paraview, I 
don't see any growing memory in time. I also get my VTK files and images.


If I run the same simulation linked against a Debug build with VTK_DEBUG_LEAKS 
on, there is a segfault inside one of the libvtkRendering libraries (it says 
libvtkRenderingOp but the rest of the name is cut off). If I take the image 
rendering out of my pipeline (comment out the RegisterView call) and leave the 
VTK file writing, it runs fine and doesn't report any leaks. I tried to get the 
segfault to drop a core file, but it won't do it.


I'm thinking that there is an issue in the rendering part causing the leak. I 
have no idea what it could be though -- this is the 4.4.0 version, is anybody 
aware of any bug fixes between 4.4.0 and current versions that might be 
relevant?


Thanks for the help,


Tim





From: ParaView <paraview-boun...@paraview.org> on behalf of Gallagher, Timothy 
P <tim.gallag...@gatech.edu>
Sent: Friday, May 20, 2016 4:17 PM
To: Burlen Loring; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring <burlen.lor...@gmail.com>
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com><mailto:andy.ba...@kitware.com>
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to 

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Thanks for the advice Burlen -- I haven't used Massif before, so this is a good 
opportunity to give it a try.


The initialize/finalize each time approach doesn't work either. I am calling 
the Finalize() routine on the vtkCPProcessor class but then when it tries to 
initialize again, it throws:


Warning: In /data4/ParaView/VTK/Parallel/Core/vtkSocketController.cxx, line 50
vtkSocketController (0xa4342f0): Already initialized.


and then crashes. So, hopefully I can sort out the memory leak rather than 
trying to debug why a hacked fix doesn't work!


Tim



From: Burlen Loring <burlen.lor...@gmail.com>
Sent: Friday, May 20, 2016 3:46 PM
To: Gallagher, Timothy P; Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst


VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch all 
kinds of leaks. For example you can have leaks where data erroneously 
accumulates with each time step, but is deleted at program termination. 
VTK_DEBUG_LEAKS will not catch that kind of error. It's probably better to use 
massif to profile your code on a small one node run. There's an excellent tool 
called massif visualizer to aid in exploring the data generated.


$0.02

On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com><mailto:andy.ba...@kitware.com>
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim

___
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at 
<http://www.kitware.com/opensource/opensource.html> 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: <http://markmail.org/search/?q=ParaView> 
http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscrib

Re: [Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Hi Andy,


Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and see what 
it turns up.


The initialize/finalize every time is definitely a hack and not for long-term 
use. But, sponsors want a report on Monday and we need to be able to visualize 
things for that -- the simulation is too big to write data files and 
post-process later. So I modified the code to do that for now until I can find 
a proper fix.


I'll let you know if I get stuck with the log file.


Thanks again,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Friday, May 20, 2016 2:39 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Memory leak with Catalyst

Hi Tim,

If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good at finding 
VTK objects that aren't deleted properly. You should be able to run this with a 
small amount of calls to Catalyst as well. If you try this and want help 
understanding the output (if an object like a vtkUnstructuredGrid is leaked it 
will often give a whole bunch of false leaks that the unstructured grid is just 
holding the references to), just share your output file and I can take a look 
at it to try and narrow down the culprit. That may be slightly easier to use 
than Valgrind.

Beyond this, you could maybe try the same run but without doing any Catalyst 
work to see what happens then. That may be a lot of compute cycles but I'm not 
sure how else to try and bisect where the memory leak is occurring.

Initializing and finalizing Catalyst every time you want output would probably 
work but I'd think there may be significant overhead doing it like this. Plus, 
it's not really solving the problem -- just avoiding it.

Best,
Andy


On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim

___
Powered by www.kitware.com<http://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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Memory leak with Catalyst

[Gallagher, Timothy P]

Hi,


One of our users is running a very big simulation and writing out images of two 
slices (two different views) every 1000 iterations and writing out the data for 
the two slices (two different data writers) as VTK files every 5000 iterations. 
It is using Paraview 4.4.


After 21000 iterations, the simulation is killed because the memory on the 
compute nodes fills up. I usually know how to track down memory problems in our 
code using valgrind and related tools, but is that the right way to go to try 
and find this problem?


Are there any tips on how to isolate where the problem may be? I don't know if 
it is in the adapter, or in paraview itself. Has anybody encountered problems 
with runaway memory using Catalyst in 4.4 when writing images or VTK files?


I know when we use pvpython to generate images and loop over many files, 
sometimes the memory also blows up and so we usually move the loop over the 
files outside the pvpython script and into a driver script that executes a new 
pvpython for each file. Is there a way to shut down/start up Catalyst each time 
it needs to write something? Is that advisable?


Thanks,


Tim
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Spanwise averaging onto a slice

[Gallagher, Timothy P]

I'm fairly sure this has been discussed somewhere before, but my search engine 
skills are failing me right now.


I would like to take the spanwise average of a 3D dataset to create a 2D plane 
of the averaged data. In my case, things are (relatively) friendly -- it's a 
channel with a uniform, structured mesh in the Z direction and I would like to 
average the data in Z to create an X-Y plane of the averaged data. What 
complicates it for me is that it is a multiblock dataset with multiple blocks 
in that spanwise direction.


Is there a filter or set of filters that would compute the spanwise average and 
return a slice as a result?


Thanks,


Tim

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] capability of ParaView, Catalyst in distributed computing environment ...

[Gallagher, Timothy P]

I'm not sure if this is exactly what the original user is referring to, but it 
is possible to have two separate codes communicate using MPI through the 
dynamic processes in MPI-2. Essentially, one program starts up on N processors 
and begins running and gets an MPI_COMM_WORLD. It then spawns another 
executable on M different processors and that new executable will call MPI_INIT 
and also get its own MPI_COMM_WORLD. So you have two, disjoint MPI_COMM_WORLD's 
that get linked together through a newly created intercommunicator.


I've used this to couple a structural mechanics code to our fluid dynamics 
solver for example. It sounds like that is similar to what is being done here.


How that would interact with coprocessing is beyond my knowledge though. It 
does sound like an interesting problem and one I would be very curious to find 
out the details.


Tim



From: ParaView  on behalf of Andy Bauer 

Sent: Wednesday, May 18, 2016 10:52 AM
To: Ufuk Utku Turuncoglu (BE)
Cc: paraview@paraview.org
Subject: Re: [Paraview] capability of ParaView, Catalyst in distributed 
computing environment ...

Hi,

I'm a bit confused. MPI_COMM_WORLD is the global communicator and as far as I'm 
aware, can't be modified which means there can't be two different communicators.

Catalyst can be set to use a specific MPI communicator and that's been done by 
at least one code (Code_Saturne). I think they have a multiphysics simulation 
as well.

Cheers,
Andy

On Wed, May 18, 2016 at 5:22 AM, Ufuk Utku Turuncoglu (BE) 
> wrote:
Hi All,

I just wonder about the capability of ParaView, Catalyst in distributed 
computing environment. I have little bit experience in in-situ visualization 
but it is hard for me to see the big picture at this point. So, i decided to 
ask to the user list to get some suggestion from the experts. Hypothetically, 
lets assume that we have two simulation code that are coupled together (i.e. 
fluid-structure interaction) and both of them have their own MPI_COMM_WORLD and 
run on different processors (model1 runs on MPI rank 0,1,2,3 and model2 runs on 
4,5,6,7). What is the correct design to create integrated in-situ visualization 
analysis (both model contributes to same visualization pipeline) in this case? 
Do you know any implementation that is similar to this design? At least, is it 
possible?

In this case, the adaptor code will need to access to two different 
MPI_COMM_WORLD and it could run on all processor (from 0 to 7) or its own 
MPI_COMM_WORLD (i.e. MPI ranks 8,9,10,11). Also, the both simulation code have 
its own grid and field definitions (might be handled via defining different 
input ports). Does it create a problem in Paraview, Catalyst side, if the 
multiblock dataset is used to define the grids of the components in adaptor. I 
am asking because some MPI processes (belongs to adaptor code) will not have 
data for specific model component due to the domain decomposition 
implementation of the individual models. For example, MPI rank 4,5,6,7 will not 
have data for model1 (that runs on MPI rank 0,1,2,3) and 0,1,2,3 will not have 
data for model2 (that runs on MPI rank 4,5,6,7). To that end, do i need to 
collect all the data from the components? If this is the case, how can i handle 
2d decomposition problem? Because, the adaptor code has no any common grid 
structure that fits for all the model components.

Regards,

Ufuk Turuncoglu
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Linking to Catalyst

[Gallagher, Timothy P]

Ah hah, the errors were being sent somewhere else and not caught properly by my 
submission script.


I found the error and now it works, I get my images and my VTK files. The only 
warnings now are:


24vtkCPTensorArrayTemplateIdE (0x23b4320): GetVoidPointer called. This is very 
expensive for vtkMappedDataArray subclasses, since the scalar array must be 
generated for each call. Consider using a vtkTypedDataArrayIterator instead.


which is something I can deal with later. I have to figure out what the 
vtkCPTensorArrayTemplate does exactly -- I believe that was something you had 
added when you took a look at our code awhile back. But it doesn't seem to 
matter for what we're doing now.


It feels good to close the ticket in our tracker about getting coprocessing on 
Crays -- it's been open since 2012.


Thanks again for all your help.


Tim


From: Andy Bauer <andy.ba...@kitware.com>
Sent: Monday, May 9, 2016 10:41 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Linking to Catalyst

Hi Tim,

I assume that writing out a data set works on other machines, correct? Can you 
try the gridwriter.py script at 
https://gitlab.kitware.com/paraview/paraview/blob/master/Examples/Catalyst/SampleScripts/gridwriter.py
 to output the full data set? It should work with PV 4.4. Note that outputs a 
full data set every time step. I'm not sure about Python warnings or errors but 
the C++ warnings and errors will be sent to std::cerr instead of std::cout.
[https://gitlab.kitware.com/uploads/project/avatar/14/pvIcon-512x512.png]<https://gitlab.kitware.com/paraview/paraview/blob/master/Examples/Catalyst/SampleScripts/gridwriter.py>

Examples/Catalyst/SampleScripts/gridwriter.py · master · ParaView / 
ParaView<https://gitlab.kitware.com/paraview/paraview/blob/master/Examples/Catalyst/SampleScripts/gridwriter.py>
gitlab.kitware.com
Parallel Data Analysis and Visualization Application based on VTK.



Did you make the script with PV 4.4? The PV Python API has some changes 
(especially for rendering) between revisions. I think the best option is to 
just comment out the parts that are causing trouble.

If you're still having issues, maybe send your full script along with std::cout 
and std::cerr outputs so I can get a little deeper into the issues.

Good luck,
Andy

On Mon, May 9, 2016 at 6:14 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Okay, really close to finally crossing this off my list -- it's been on it for 
years.


I can get the code to generate images but it won't save data files. I don't get 
any errors and I get my images, just no VTK files. I have tried the default 
that the catalyst generator creates:


parallelMultiBlockDataSetWriter1 = 
servermanager.writers.XMLMultiBlockDataWriter(Input=slice1)

coprocessor.RegisterWriter(parallelMultiBlockDataSetWriter1, 
filename='slices_%t.vtm', freq=freq_file)


and I tried another form that the grid writer you've send me in the past used:


writer = coprocessor.CreateWriter(XMLMultiBlockDataWriter, 
filename='slices_%t.vtm', freq=freq_file)


in all cases, freq_file = 1000.


Neither one will output any vtk files.


Any thoughts?


Also, minor note but it is kind of annoying -- both the catalyst generator and 
the trace generator seem to do this, but they add commands that set attributes 
that are not part of the classes when run through the python script. For 
example, I had to comment out:


#  slice1Display.SelectInputVectors = ['CELLS', 'Velocity [m/s]']
#  slice1Display.WriteLog = ''


Any ideas why it does that? Or is there a way (and downfall) to just let it add 
attributes without manually calling add_attribute() each time?


Tim



From: ParaView 
<paraview-boun...@paraview.org<mailto:paraview-boun...@paraview.org>> on behalf 
of Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>>
Sent: Monday, May 9, 2016 5:13 PM
To: Andy Bauer

Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Linking to Catalyst


Yeah -- okay, pointing it to the build directory instead of the install made 
sure everything was found.


One step closer to getting this working on Cray.


Thanks,


Tim



From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Monday, May 9, 2016 4:54 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Linking to Catalyst

Hmm, that could be a bug in the superbuild. The superbuild arguments aren't all 
passed to the ParaView build itself and it could be that this option was 
missing for the PV specific build part. Instead of doing the whole build from 
scratch, I'd suggest you just search for the ParaViewConfig.cmake file to find 
where PV was actually built and just poi

Re: [Paraview] Linking to Catalyst

[Gallagher, Timothy P]

Okay, really close to finally crossing this off my list -- it's been on it for 
years.


I can get the code to generate images but it won't save data files. I don't get 
any errors and I get my images, just no VTK files. I have tried the default 
that the catalyst generator creates:


parallelMultiBlockDataSetWriter1 = 
servermanager.writers.XMLMultiBlockDataWriter(Input=slice1)

coprocessor.RegisterWriter(parallelMultiBlockDataSetWriter1, 
filename='slices_%t.vtm', freq=freq_file)


and I tried another form that the grid writer you've send me in the past used:


writer = coprocessor.CreateWriter(XMLMultiBlockDataWriter, 
filename='slices_%t.vtm', freq=freq_file)


in all cases, freq_file = 1000.


Neither one will output any vtk files.


Any thoughts?


Also, minor note but it is kind of annoying -- both the catalyst generator and 
the trace generator seem to do this, but they add commands that set attributes 
that are not part of the classes when run through the python script. For 
example, I had to comment out:


#  slice1Display.SelectInputVectors = ['CELLS', 'Velocity [m/s]']
#  slice1Display.WriteLog = ''


Any ideas why it does that? Or is there a way (and downfall) to just let it add 
attributes without manually calling add_attribute() each time?


Tim



From: ParaView <paraview-boun...@paraview.org> on behalf of Gallagher, Timothy 
P <tim.gallag...@gatech.edu>
Sent: Monday, May 9, 2016 5:13 PM
To: Andy Bauer
Cc: paraview@paraview.org
Subject: Re: [Paraview] Linking to Catalyst


Yeah -- okay, pointing it to the build directory instead of the install made 
sure everything was found.


One step closer to getting this working on Cray.


Thanks,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Monday, May 9, 2016 4:54 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Linking to Catalyst

Hmm, that could be a bug in the superbuild. The superbuild arguments aren't all 
passed to the ParaView build itself and it could be that this option was 
missing for the PV specific build part. Instead of doing the whole build from 
scratch, I'd suggest you just search for the ParaViewConfig.cmake file to find 
where PV was actually built and just point to that.

On Mon, May 9, 2016 at 4:50 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Well shoot, it looks like I didn't build with the install development files on, 
even though I set it when I configured the superbuild. I must have done that 
part wrong


My configure line is:


cmake \
-DCMAKE_INSTALL_PREFIX:PATH=${HOME}/pv-test/${version}_osmesa \
-DCMAKE_BUILD_TYPE=Release \
...

-DPARAVIEW_ENABLE_CATALYST=ON \
-DPARAVIEW_ENABLE_PYTHON=ON \
-DPARAVIEW_INSTALL_DEVELOPMENT_FILES=ON \
-DPARAVIEW_BUILD_QT_GUI=OFF \
-DBUILD_TESTING=OFF \
-DVTK_USE_X=OFF \
...

-DVTK_OPENGL_HAS_OSMESA=ON \
-DOSMESA_INCLUDE_DIR:STRING="${INSTALLPATH}/osmesa/include" \
-DOSMESA_LIBRARY:STRING="${INSTALLPATH}/osmesa/lib/libOSMesa.so" \
./ParaViewSuperbuild


and all of the other PARAVIEW* options seemed to pass through properly when the 
superbuild made paraview. Any ideas why that option didn't pass through?


Thanks -- I knew it had to be something really obvious!


Tim




From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Monday, May 9, 2016 4:43 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Linking to Catalyst

Hi Tim,

Is the PV directory you're pointing to a build directory or an install 
directory? If it's an install directory you'll need to enable 
PARAVIEW_INSTALL_DEVELOPMENT_FILES. Other than that, my suggestion would be to 
try linking one of the Catalyst examples from 
https://github.com/Kitware/ParaViewCatalystExampleCode and see how that works 
for you. Another thing you could try is using a newer version of CMake from 
https://cmake.org/download/. For the Linux x86_64 tarball, you can just untar 
the executables from that and use directly.
[https://avatars3.githubusercontent.com/u/87549?v=3=400]<https://github.com/Kitware/ParaViewCatalystExampleCode>

GitHub - Kitware/ParaViewCatalystExampleCode: Example 
...<https://github.com/Kitware/ParaViewCatalystExampleCode>
github.com<http://github.com>
ParaViewCatalystExampleCode - Example problems and snippets of code to 
demonstrate ParaView's Catalyst.



Let us know if none of those ideas don't work for you.

Best,
Andy

On Mon, May 9, 2016 at 3:58 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hello again,


I'm (finally) trying to get Catalyst to successfully link to our application 
code on Excalibur (Cray, ARL HPC). I was able to build paraview and all of the 
dependencies thanks to help I've gotten on th

Re: [Paraview] Linking to Catalyst

[Gallagher, Timothy P]

Yeah -- okay, pointing it to the build directory instead of the install made 
sure everything was found.


One step closer to getting this working on Cray.


Thanks,


Tim



From: Andy Bauer <andy.ba...@kitware.com>
Sent: Monday, May 9, 2016 4:54 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Linking to Catalyst

Hmm, that could be a bug in the superbuild. The superbuild arguments aren't all 
passed to the ParaView build itself and it could be that this option was 
missing for the PV specific build part. Instead of doing the whole build from 
scratch, I'd suggest you just search for the ParaViewConfig.cmake file to find 
where PV was actually built and just point to that.

On Mon, May 9, 2016 at 4:50 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Well shoot, it looks like I didn't build with the install development files on, 
even though I set it when I configured the superbuild. I must have done that 
part wrong


My configure line is:


cmake \
-DCMAKE_INSTALL_PREFIX:PATH=${HOME}/pv-test/${version}_osmesa \
-DCMAKE_BUILD_TYPE=Release \
...

-DPARAVIEW_ENABLE_CATALYST=ON \
-DPARAVIEW_ENABLE_PYTHON=ON \
-DPARAVIEW_INSTALL_DEVELOPMENT_FILES=ON \
-DPARAVIEW_BUILD_QT_GUI=OFF \
-DBUILD_TESTING=OFF \
-DVTK_USE_X=OFF \
...

-DVTK_OPENGL_HAS_OSMESA=ON \
-DOSMESA_INCLUDE_DIR:STRING="${INSTALLPATH}/osmesa/include" \
-DOSMESA_LIBRARY:STRING="${INSTALLPATH}/osmesa/lib/libOSMesa.so" \
./ParaViewSuperbuild


and all of the other PARAVIEW* options seemed to pass through properly when the 
superbuild made paraview. Any ideas why that option didn't pass through?


Thanks -- I knew it had to be something really obvious!


Tim




From: Andy Bauer <andy.ba...@kitware.com<mailto:andy.ba...@kitware.com>>
Sent: Monday, May 9, 2016 4:43 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org<mailto:paraview@paraview.org>
Subject: Re: [Paraview] Linking to Catalyst

Hi Tim,

Is the PV directory you're pointing to a build directory or an install 
directory? If it's an install directory you'll need to enable 
PARAVIEW_INSTALL_DEVELOPMENT_FILES. Other than that, my suggestion would be to 
try linking one of the Catalyst examples from 
https://github.com/Kitware/ParaViewCatalystExampleCode and see how that works 
for you. Another thing you could try is using a newer version of CMake from 
https://cmake.org/download/. For the Linux x86_64 tarball, you can just untar 
the executables from that and use directly.
[https://avatars3.githubusercontent.com/u/87549?v=3=400]<https://github.com/Kitware/ParaViewCatalystExampleCode>

GitHub - Kitware/ParaViewCatalystExampleCode: Example 
...<https://github.com/Kitware/ParaViewCatalystExampleCode>
github.com<http://github.com>
ParaViewCatalystExampleCode - Example problems and snippets of code to 
demonstrate ParaView's Catalyst.



Let us know if none of those ideas don't work for you.

Best,
Andy

On Mon, May 9, 2016 at 3:58 PM, Gallagher, Timothy P 
<tim.gallag...@gatech.edu<mailto:tim.gallag...@gatech.edu>> wrote:

Hello again,


I'm (finally) trying to get Catalyst to successfully link to our application 
code on Excalibur (Cray, ARL HPC). I was able to build paraview and all of the 
dependencies thanks to help I've gotten on the list here in the past. However, 
when I try to link my code to it (and this is a code that works fine with 
Catalyst on other platforms), I get:


 CMake Error at 
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/vtkModuleAPI.cmake:120
 (message):
   Requested modules not available:

 vtkPVPythonCatalyst
 Call Stack (most recent call first):
   
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/VTKConfig.cmake:80 
(vtk_module_config)
   
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/ParaViewConfig.cmake:49
 (include)
   CMakeLists.txt:218 (find_package)

The section in my CMakeLists that looks for paraview is:

option(LESLIE_USE_COPROCESSING "Turn on CoProcessing with Paraview" OFF)
if(LESLIE_USE_COPROCESSING)
  find_package(ParaView REQUIRED vtkPVPythonCatalyst
   HINTS $ENV{PARAVIEW_CP_ROOT})
  include(${PARAVIEW_USE_FILE})
  include_directories(${PROJECT_SOURCE_DIR}/utils)
  add_definitions(-DPARAVIEW_COPROCESSING)
endif()
mark_as_advanced(LESLIE_USE_COPROCESSING)

and it doesn't seem to work. On other machines, I never needed to set the 
PARAVIEW_CP_ROOT variable, it always just found it. When I build my code, I 
point the paraview directory (where it finds the paraviewConfig.cmake file) to:


/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4


and it seems to find it okay.


Lastly, the vtkPVPythonCatalyst.so library is in the 
lib/paraview-4.4/site-packages/vtk directory and there is 
libvtkPVPythonCatalyst-pv4.4.so<http://libvtkPVPythonCatalyst-pv4.4

[Paraview] Linking to Catalyst

[Gallagher, Timothy P]

Hello again,


I'm (finally) trying to get Catalyst to successfully link to our application 
code on Excalibur (Cray, ARL HPC). I was able to build paraview and all of the 
dependencies thanks to help I've gotten on the list here in the past. However, 
when I try to link my code to it (and this is a code that works fine with 
Catalyst on other platforms), I get:


 CMake Error at 
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/vtkModuleAPI.cmake:120
 (message):
   Requested modules not available:

 vtkPVPythonCatalyst
 Call Stack (most recent call first):
   
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/VTKConfig.cmake:80 
(vtk_module_config)
   
/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4/ParaViewConfig.cmake:49
 (include)
   CMakeLists.txt:218 (find_package)

The section in my CMakeLists that looks for paraview is:

option(LESLIE_USE_COPROCESSING "Turn on CoProcessing with Paraview" OFF)
if(LESLIE_USE_COPROCESSING)
  find_package(ParaView REQUIRED vtkPVPythonCatalyst
   HINTS $ENV{PARAVIEW_CP_ROOT})
  include(${PARAVIEW_USE_FILE})
  include_directories(${PROJECT_SOURCE_DIR}/utils)
  add_definitions(-DPARAVIEW_COPROCESSING)
endif()
mark_as_advanced(LESLIE_USE_COPROCESSING)

and it doesn't seem to work. On other machines, I never needed to set the 
PARAVIEW_CP_ROOT variable, it always just found it. When I build my code, I 
point the paraview directory (where it finds the paraviewConfig.cmake file) to:


/p/home/tgallagh/pv-test/4.4.0_osmesa/lib/cmake/paraview-4.4


and it seems to find it okay.


Lastly, the vtkPVPythonCatalyst.so library is in the 
lib/paraview-4.4/site-packages/vtk directory and there is 
libvtkPVPythonCatalyst-pv4.4.so* and libvtkPVPythonCatalystPython27D-pv4.4.so* 
in lib/paraview-4.4/


I'm at a loss to understand why it is reporting the module is missing -- did I 
miss something somewhere?


Thanks as always,


Tim
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Surface LIC plugin

[Gallagher, Timothy P]

Alan,


If you are working on your own data, the LIC plugin expects velocity to be 
point centered rather than cell centered. If you do it on cell centered data, 
you'll get just uniform streaks without anything interesting happening.


Tim



From: ParaView  on behalf of Moreland, Kenneth 

Sent: Monday, April 4, 2016 2:16 PM
To: Scott, W Alan; paraview@paraview.org
Subject: Re: [Paraview] Surface LIC plugin


1. Load disk_out_ref. All variables on. Apply.

2. Add clip plane. Apply.

3. Change representation to "Surface LIC"



The default options for Surface LIC should pick up the velocity vectors in 
disk_out_ref. For some reason the surface LIC is not working on the external 
surface of disk_out_ref. I don't know why.



-Ken





From: ParaView  on behalf of Walter Scott 

Date: Monday, April 4, 2016 at 11:38 AM
To: "paraview@paraview.org" 
Subject: [EXTERNAL] [Paraview] Surface LIC plugin



I just tried the Surface LIC plugin, and got totally confused.  Does anyone 
have any directions on how to make pretty pictures using one of the Sources, or 
disk_out_ref.exo or the can.exo?



Thanks,



Alan




___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview