executable
`../../../../bin/vtkmkg3states-pv4.3'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/vtkmkg3states-pv4.3] Error 1
make[1]: ***
[VTK/ThirdParty/tiff/vtktiff/CMakeFiles/vtkmkg3states.dir/all] Error 2
make: *** [all] Error 2
ganesh
On Thu, Jul 16, 2015 at 2:19 PM Chuck
, where is the machine located? We maintain ParaView
installations at many different HPC sites on a range of Cray systems.
- Chuck Atkins
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource
If it's a problem with HDF5 library, I'm not sure where I need to point to
the system installation.
If you load the cray-hdf5 module, that will set the HDF5_DIR environment
variable to the correct location. Unfortunately, CMake uses the HDF5_ROOT
variable instead to look for it so you'll
Hi Frank,
The easiest way to build OpenSWR is probably to use the SCons build instead
of autotools. Here's a docker file we use to generate re-distributable
libGL and libOSMesa binaries:
https://github.com/chuckatkins/mesa-builds/blob/master/Dockerfile . In
short though, you'll want to do the
Hi Tim,
When building CMake on a Cray, you'll want to build using the host system
compilers, i.e. /usr/bin/gcc and /usr/bin/g++, not with the cray compiler
wrappers. Usually I just do:
module purge
CC=/usr/bin/gcc CXX=/usr/bin/g++ /path/to/cmake_source/bootstrap
--prefix=/path/to/cmake/install
Hi Giovanni,
It seems there's still some compatibility issues with upstream and the
Intel compiler. Really it's sloppy logic in how the C headers and their
linkage are specified. I've addressed this in a fork on github:
https://github.com/chuckatkins/qhull.git . Basically I've made the headers
>
> This will mean that Paraview will have very little memory available to it
> (confirmed using Memory inspector) and it will be very slow!
>
The Memory inspector can't really be relied on right now because it
includes cached memory in the "used" total. Basically it's reporting Total
- Free,
Ben, Giovanni,
My changes to qhull to fix the Intel compiler were merged upstream so we
don't need to use private forks anymore. I'll change the superbuild repo
to point to upstream. In the meantime, you can use the current upstream
master at https://github.com/qhull/qhull.git . I tested it the
Hi Gena,
Sometime oddities like this show up when different compiler wrappers are
being used. In this case, your using the Intel MPI wrappers for all
compilations. Try bypassing them for the main compilation and only using
them for MPI detection:
CC=icc CXX=icpc FC=ifort \
cmake \
>
> I have: Server Type = Client/Server
> Host=localhost
> Port=11772
> Command: ssh -L 11772:remote-box:11772 user@remote-box pvserver
> --server-port=11772
>
When remotely launching a pvserver in this sort of configuration (i.e. egl
+ directly via an ssh command), a few things make this easier
>
> I have: Server Type = Client/Server
> Host=localhost
> Port=11772
> Command: ssh -L 11772:remote-box:11772 user@remote-box pvserver
> --server-port=11772
>
When remotely launching a pvserver in this sort of configuration (i.e. egl
+ directly via an ssh command), a few things make this easier
What do the EGL settings in your CMakeCache look like? You can find them
from the build directory:
$ grep '^EGL[^-]*=' CMakeCache.txt
EGL_INCLUDE_DIR:PATH=/usr/include
EGL_LIBRARY:FILEPATH=/usr/lib64/libEGL.so
EGL_gldispatch_LIBRARY:FILEPATH=/usr/lib64/libGLdispatch.so
I've had similar issues with VirtulGL and VTK in the past. The "Shader
object was not initialized, cannot attach it." error is often the result of
some sort of required OpenGL version support for a specific call is
lacking. A few questions:
- Are you able to run on the actual machine without
Unfortunately I suspect this is an issue with NVIDIA driver. Their EGL
support is still brand new and currently seems to be fairly brittle between
driver releases so perhaps best to wait until it settles a bit and just
stick with X for now :-(. Are you able to use the X+OpenGL2 (i.e. no egl)
Let's drop this thread and resume further discussion on the original thread
for consistency. I'll copy and repost this message on the original thread.
- Chuck
On Tue, Apr 12, 2016 at 2:08 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:
> I have: Server Type = Client/Server
>>
Sorry, forgot to cc the list.
Hi Dennis, a few questions:
Are you using the binaries from paraview.org or did you build it yourself?
Does the machine with the vnc server have a GPU you're trying use?
You said previous versions of paraview worked. Does that include 5.0 and
4.x or just 4.x?
On
Hi Harald,
I don't have an answer to your VGL problem yet, but in the mean time, are
you tied to having to use it that way? If not, you also have the option of
running ParaView in client / server mode which may actually be more ideal
for your situation: i.e. with pvserver running on the headless
.angelini@mail.mil>
>>> > >
>>> Cc: ParaView <paraview@paraview.org < Caution-
>>> mailto:paraview@paraview.org <paraview@paraview.org> > >
>>> Subject: [Non-DoD Source] Re: [Paraview] Measure graphics performance?
>>>
>
gt; FYI, the workstations have Nvidia K4000 cards and we are running realVNC
> – any chance this is part of your test suite?
>
>
>
> Thanks again, sorry for the confusion, but I am NOT a Linux or VNC guru!!
>
>
>
> Dennis
>
>
>
> *From:* Chuck Atkins [m
issing on display "alnx031:15.0".
> >
> > OpenGL vendor string: Mesa project: www.mesa3d.org
> >
> > OpenGL renderer string: Mesa GLX Indirect
> >
> > OpenGL version string: 1.2 (1.5 Mesa 6.4.1)
> >
> > OpenGL extensions:
> >
> >
>
Hi Vincent,
"ERROR CODE 134" is a generic abort code and doesn't really convey anything
specific. It's essentially the operating system saying "the program
crashed" with no further detail. To try to diagnose it further, you said
"My problem appeared on a CentOS 6.7 used through a remote
the
repo from our public gitlab server by cloning
https://gitlab.kitware.com/xdmf/xdmf.git .
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183
On Thu, Jul 21, 2016 at 9:43 AM, Nabil Ghodbane <nabil.ghodb...@gmail.com>
wrote:
> hi Tom,
>
Hi Michel,
> Indeed, I built PVSB 5.2 with the intel 2016.2.181 and intelmpi 5.1.3.181
> compilers, then ran the resulting pvserver on Haswell CPU nodes (Intel
> E5-2680v3) which supports AVX2 instructions. So this fits exactly the
> known issue you mentioned in your email.
>
Yep, that'll do it.
Hi Michel,
However, it starts to become tricky when I use pvserver with OSMesa support.
> It appears the resulting pvserver with OSMesa support compiled in Release
> mode always crashes when I try to load data,
>
Which compiler are you building with and type of CPUs are available on the
node
Hi Bishwajit,
I believe the curses interface will get built by default if it can find
ncurses so you're probably missing the ncurses development libraries. Try
installing the libncurses-dev package and then re-configuring and building
CMake.
- Chuck
On Wed, Feb 8, 2017 at 8:51 AM, Ben Boeckel
Hi Michel,
Setting KNOB_MAX_WORKER_THREADS to 1 fixed the oversubscription of threads
and the memory consumption issue when the number of mpi processes is equal
to the number of cores requested.
Great!
If I do not allow threading of swr by setting KNOB_MAX_WORKER_THREADS to 1
(basically serial
Nabil,
Can you use gcc 4.4? It should be available on EL5 as a technology preview
by installing the gcc44{,-c++,-gfortran} packages. You'll then need to set
your CC and CXX env vars to /usr/bin/gcc44 and /usr/bin/g++44 respectively.
--
Chuck Atkins
Staff R Engineer, Scientific
Hi Yvan,
What are the resulting libraries in
/home/D43345/opt/Mesa-13.0/arch/calibre9/lib
after the Mesa install? It looks like something has gone a bit awry with
the Mesa build. Also, what does the summary look like that's printed out
at the end of ./configure for Mesa?
--
Chuck Atkins
Hi Faiz,
Quick question - if both compiled from source, what all needs to be same
> for a client and server to connect and render successfully?
>
They both need to be the same version of paraview and use the same
rendering backend, i.e. OpenGL vs OpenGL2. ParaView now defaults to
OpenGL2 so as
GL
benefit of GPU accelerated rendering with the libOSMesa benefit of not
dealing with an X server.
Either way, all three configurations for ParaView will work with Catalyst:
libGL (gpu w/ X, default), libOSMesa (cpu w/o X), and EGL (gpu w/o X).
------
Chuck Atkins
Staff R Engineer, Scientific
> So if someone is running a Catalyst
> instrumented code that is compiled on
> a supercomputer with thousands of
> back-end nodes, can they link to a
> ParaView build or a Catalyst Edition
> and expect the code to work?
Yes
> Do back-end nodes have X servers
> available to them?
It depends.
Hi Rick,
> When PVSB configures Paraview, it is setting the cmake flag
> VTK_USE_SYSTEM_PNG=ON and it should be OFF.
>
When using the superbuild, ParaView should always be using a "system"
PNG. The diggerence is whether that will be provided by the OS or the
superbuild. Either way, it's
Hi Bishwajit,
> However in both below cases I am able to see CPU power getting consumed
> when the script is run.
>
It looks like your GPU build isn't actually building against the GPU. In
order to use the GPU with the NVidia driver, you either need to use an X
server or use EGL.
Just as a follow-up, I will be leaving this survey open all week and stop
accepting responses on Friday, October 30.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Sep 23, 2016 at 3:05 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:
> We'
Hi Frank,
> 2. There are still libraries built into /path/to/build/install/lib64.
>
> · projects/apple-unix/szip.cmake
>
> · projects/unix/mesa.common.cmake
>
> · projects/apple-unix/freetye.cmake
>
These should not need to be part of the resulting install and can be
>
> which are not copied into the archive when packing the binaries using:
>> “ctest -V -R cpack-paraviewsdk-TGZ”
>>
>
> This should have been fixed a while ago. I'll try to reproduce it and
> make sure the packaging is correct.
>
I see the same problem. I have a fix for the packaging and will
and should only take a minute
or two.
Note: If you are a current support customer with specific critical
requirements, please feel free to email me off-list.
https://docs.google.com/forms/d/e/1FAIpQLSczYSEWMr90ywhTg1jLg2u6JWVNRh6zUzCLeFPRnc_Qyc13dg/viewform
Thank you.
--
Chuck Atkins
Staff R
Yes. Off by a month, my mistake. The intent is to let the survey run for
a week.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Mon, Sep 26, 2016 at 3:03 PM, Ben Boeckel <ben.boec...@kitware.com>
wrote:
> On Mon, Sep 26, 2016 at 14:01:38 -0400, Chu
>
> > My intention is to compile paraview without GUI to run it in batch on
> > our cluster. This is the main reason why I am using a specific test
> > suite to check the performance of mesa-llvm vs. mesa-swr vs. GPU. At
> > the moment, on CPUs supporting AVX2 instruction set, mesa-swr shows a
> >
Hi Chris,
import clr
> clr.AddReference("DHI.Generic.MikeZero.DFS")
> from DHI.Generic.MikeZero.DFS import *
>
> This works well in "stand alone" python scripts. I tried using the same
> approach in ParaView/Programmable Source, but it can't find the CLR module.
>
If you're using the ParaView
Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Oct 7, 2016 at 4:39 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:
> which are not copied into the archive when packing the binaries using:
>>> “ctest -V -R cpack-paraviewsdk-TGZ”
>>>
>>
>>
Hi Rick,
Is it tied to a particular compiler / os combination? Better yet, is there
a machine I can reproduce it on? I've got an active account on most of the
HPCMP systems.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Thu, Dec 29, 2016 at 9:12 AM, Angelini
ored, you can use to
set the volume representation:
q = OpenDataFile("someFile.raw")
...
qDisplay = Show()
qDisplay.SetRepresentationType('Volume')
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
___
Powered by www
Hi Andy,
I realized after posting that my comparison is not exactly apples to apples
> - my build of 5.2.0 required updates to mesa (13.0.0) compared with the
> version I used for 4.4.0 (11.2.0).
> I will recompile 4.4.0 with the same mesa version I used with 5.2.0 and
> report back.
>
...
> Has
o use it in many
different ways. I hope this helps give you a good place to start though.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Mon, Dec 19, 2016 at 12:30 PM, Christopher Neal <chrisn...@snumerics.com>
wrote:
> Hi all,
>
> I just saw th
Hi Zhang,
> X Error of failed request: GLXBadContext
>
> Major opcode of failed request: 135 (GLX)
>
> Minor opcode of failed request: 5 (X_GLXMakeCurrent)
>
> Serial number of failed request: 28
>
> Current serial number in output stream: 28
>
This is an indication that
Hi Zhang,
> It is true that previously in my case the I/O operation took most of the
> time. My files are txt files. After received your reply, I generated a
> series of binary dataset files and had a try rendering them. I did'n record
> the exact rendering time but I can feel it was far more
>
> The dataset is polydata, so I use D3 filter to redistribute it among the 8
> processes.
>
D3 is an expensive operation but when the data starts of as a single
partition, there's not a whole lot of other options for re-distributing
it. When the data is genereated, is it in a single partition
ParaView now requires C++11 support and uses some newer CMake features to
detect this properly. While this worked for gcc and clang for some time
with CMake, the Intel compiler did not have language feature support with
CMake until at least 3.6.
--
- Chuck
On Fri, Mar 17, 2017 at 9:37
does. Disabling SWR isn't really a great option since it's performance is
dramatically better than the llvmpipe alternative. Placing a newer
binutils in your path should let SWR build successfully.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Wed, Apr 19, 2017
Hi Bishwajit,
I hate to be the bearer of bad news, but the K20c was a specific model of
Tesla that is restricted to compute functionality only and is not capable
of performing OpenGL functions via EGL. As such, it won't be usable by
ParaView for rendering. Almost all other Teslas, including the
-python module instead of anaconda.
- Chuck
On Sun, Jul 9, 2017 at 6:56 PM, Cory Quammen <cory.quam...@kitware.com>
wrote:
> Mathi,
>
> Chuck Atkins is the guru when it comes to compiling ParaView on Cray
> systems (along with many other systems). He may have some more helpful
, for instance.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Wed, Jul 19, 2017 at 3:19 PM, Martin Cuma <martin.c...@utah.edu> wrote:
> Hi Ben,
>
> I finally got all the dependencies in and built Paraview from the source
> with the debug options on ou
e with multiple partitions adn timesteps per
file. Your bottlenext in IO will likely be the write time anyways and as
long as the file format your using supports parallel reads then how that's
laid out, whether in a single file or multiple files, will probably not
have a significant impact.
----
work? Were there any error messages? etc.
Thanks
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.htm
Hi Patrick,
On a RedHat 6 server, with AMD firepro W7000 GPU
...
> I'm launching paraview via vncviewer on this node.
If you're running via VNC then unfortunately you won't be using the GPU
(unless you get more creative with something like VirtualGL). You're only
going to be able to use the
thon script with [Tools] ->
"Start trace", doing the things you want, and then [Tools] -> "Stop
trace". The resulting python file can be run directly with either pvpython
or pvbatch.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Thu
57 matches
Mail list logo
