Co-processing might or might not be what I was looking for!?
However, I do not fully understand the functionality. Some questions that
someone might be able to answer:
1. Do I need to link with the VTK libraries? This seems a bit heavy since
I just want to send some data and commands to
Hello,
I’m running paraview 3.8.1 under linux using 8 cpus loading a
reconstructed openfoam case with about 13GB per timestep (we have just
two time steps, start 0 and result 1). The machine on which pvserver
runs has 16 cpus and 70GB RAM, but pvserver uses just a small fraction
of the ram.
On Mon, 28 Feb 2011 23:06:45 +0900
=?iso-2022-jp?B?KBskQkVsNX4bKEIgKBskQkk4PWA7fhsoQikp?=, Takuya OSHIMA
osh...@eng.niigata-u.ac.jp wrote:
Hello,
Is there any reason you prefer to load such a big case with
reconstructed? The OpenFOAM reader (and subsequent filters) runs in
parallel only for
On Mon, Feb 28, 2011 at 3:04 AM, alexander.siem...@skf.com wrote:
Co-processing might or might not be what I was looking for!?
However, I do not fully understand the functionality. Some questions that
someone might be able to answer:
1. Do I need to link with the VTK libraries? This seems a
What exactly are you trying to do? vtkSMMultiViewRenderModuleProxy is
deprecated, but it was never meant to be used directly anyways -- one
simply created a view proxy and used it. Which is still true. Simply
create multiple RenderView proxies and set ViewPosition and
ViewSize properties on them
Florian,
Is there any reason you prefer to load such a big case with
reconstructed? The OpenFOAM reader (and subsequent filters) runs in
parallel only for decomposed cases. For reconstructed cases the reader
loads everything in process 0.
Also, are you sure you built ParaView with compiler
I am helping a colleague build ParaView on their Mac running OS X 10.5.8 and
running into an error with the libIOKit. At first I thought it might have
something to do with PV; later I thought perhaps not as it happened with
both ParaView 3.8 and 3.10.
ParaView 3.10.0 RC1 (with XCode + system
MPI implementation is SGI MPI. I have also tried to compile openmpi
1.4.3 and pvserver from source, yet it’s still very slow. The client
used is the x64 build from the paraview homepage.
I would expect SGI MPT to out perform others if run on an SGI system...
MPI setup is for local use only.
Recently while working on fixing a bug for some of the VisIt readers I
learned of H5_USE_16_API which apparently you can define before including
hdf5.h in order to use 1.6 API. At least that's my understanding. Give it a
try! please feel free to let me know if I am wrong ;-)
On Thu, Feb 17, 2011
Hi, Ken and Utkarsh.
I'm not 100% sure I understand the padding. If something special is
needed to get nice pictures out of some misbehaving graphics cards, that
makes sense. However, here's my $0.02 from a user's perspective.
The image produced via padding should match, pixel for pixel,
I just found that a short while ago. I think there may be clashes with
xdmf if you enable this define. Just something to be aware of.
Thanks
Mike Jackson
On Monday, February 28, 2011, David Partyka david.part...@kitware.com wrote:
Recently while working on fixing a bug for some of the VisIt
11 matches
Mail list logo
