I have a python programmable source which mimics an already working C++
Reader. The Reader works in parallel and correctly gets the Update
Extent assigning to each proc, a different sub-region of the whole. The
Python prog. source works fine in serial mode.
When run in parallel, *all* procs
Martin
I don't really know what to say. I tried myself using our installed
version of ParaView 3.4 (linux) to
1) load a time dependent dataset
2) Add a temporal cache
3) Create a line source
4) Instantiate the ParticleTracer (don't use the Pathline filter - that
is used to generate trails
Hi,
This is weird. I followed the same post as you, and it works for me,
in the stable 3.4 and in the CVS 3.5 (nightly). As the
vtkDICOMImageReader does not make use of DICOMDIR, but only dcm type
files, are you this is not a problem in your dcm files? I think that
they have to contains the
This is a feature rather than a bug. The programmable source sets
the extent translator to be a vtkOnePieceExtentTranslator. To override
this behavior, add the following to your RequestInformations script:
from paraview import util
Berk Geveci wrote:
This is a feature rather than a bug. The programmable source sets
the extent translator to be a vtkOnePieceExtentTranslator. To override
this behavior, add the following to your RequestInformations script:
The thought never crossed my mind this could be a bug, but it sure
John,
Here's my understanding of what may be happening:
* pvclient has done a gather data information and is waiting to
receive that data
* pvserver0 has received this gather data request is asking all
satellites to gather data
* pvserver1 also received that gather data request but before is
Hi,
I use 3 files for the vtkDICOMImageReader plugin :
- One CMakeList.txt where you can find those lines:
# READERS PLUGIN --
# Use the ADD_PARAVIEW_PLUGIN macro to build a plugin
ADD_PARAVIEW_PLUGIN(
DICOMImageReader #--Name for
Sweet. I've committed the patch to CVS.
On Tue, Feb 10, 2009 at 10:45 AM, John Biddiscombe biddi...@cscs.ch wrote:
Utkarsh
Looks good. 10 out of 10 successes with the patch applied (using 5 to 10
pvserver nodes) - I'll try with more later when the rest of the machine is
free.
Thanks yet
As per the motivation of the ParaView developpers to do that, besides
providing an exercise for the more adventurous folks?
This was left from the days when charts expected rectilinear grid
input. Consider the case where you are applying a programmable filter
to an unstructured grid which
Is there anyway to build paraview using an existing VTK installation
instead of having to have another copy of VTK inside paraview?
--
Thanks,
David
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
David
Is there anyway to build paraview using an existing VTK installation
instead of having to have another copy of VTK inside paraview?
Possible to do, but your life is too short to make it worthwhile.
Instead, Build paraview as per usual, and stop using vtk on its own!
Simply point
John,
Thanks a lot for your help. I have re-used part of your code to create a
Multi-block to table filter. (Basically exactly the same as your
probeIntegration but without the integration step).
The problem I have now is in creating a histogram which has the Block Id
(String - first column of
The new charts in vtk/guisupport/qt/chart have support for strings and numbers
on the axes. The old charts only support numbers. We're currently integrating
the new charts into paraview. Then, you'll be able to view the vtkTable.
The chart views in vtk/guisupport/qt can be displayed using
Thanks very much, Jerome.
The vtkDICOMReader works right now. The problem was in my xml file for
server manager.
Again, thanks very much. I am really appreciate your help!
Aaron
On Tue, Feb 10, 2009 at 7:49 AM, Jérôme jerome.ve...@gmail.com wrote:
Hi,
I use 3 files for the
Eric,
I think we dealt with this problem since 3.4. I can't reproduce the
problem with your first set of instructions on cvs head. Do you mind
trying the cvs version?
-berk
On Fri, Feb 6, 2009 at 2:57 PM, Eric E. Monson emon...@cs.duke.edu wrote:
Hey Alan,
Are you seeing both the point and
Can you tell us exactly (detailed, step-by-step) what you are doing?
That dialog works fine for me (running OS X 10.5).
-berk
On Tue, Feb 10, 2009 at 4:10 AM, Martin Uppman f0...@student.lth.se wrote:
Hi again,
thank you for fast answer John! I'm aware of the problem that my particle
tracer
Nope -- I have no idea how to do that. Could you give me some guidance?
I really appreciate it,
-Eric
On Feb 10, 2009, at 12:50 PM, Berk Geveci wrote:
Did you set the whole extent in the RequestInformation script?
-berk
On Fri, Feb 6, 2009 at 11:28 AM, Eric E. Monson
emon...@cs.duke.edu
It should be something like:
from paraview import util
util.SetOutputWholeExtent(self, [0, 10, 0, 10, 0, 10])
Make sure that you are putting this in the RequestInformation script.
I think in the future, we should have a widget with six entry boxes...
-berk
On Tue, Feb 10, 2009 at 2:31 PM, Eric
That works great -- thanks!
Now that you pointed me in the right direction, I can see how both
WholeExtent and UpdateExtent were [0, -1, 0, -1, 0, -1] in the output
with my original script. Maybe it should have been obvious, but I
didn't know enough to look for that.
It also seems to
Thanks a lot, Alan. This was driving me nuts that nobody could
reproduce it! :)
For now I wish I could predict which variable was going to be lost so
I could at least create a sacrificial array that could disappear and
leave my real data intact.
I also wish I knew the difference in
Thanks to this mailing list, I know how to make Paraview read the DICOM
files right now.
However, the volume rendering speed is not satisfactory. I am wondering if I
want to use vtkOpenGLVolumeTextureMapper3d for the volume rendering, how
should I change paraview's code? Moreover, if I want to use
21 matches
Mail list logo
