a python 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&D Engineer, Scientific Computing
Kitware, Inc.
What actually happens? What didn't
work? Were there any error messages? etc.
Thanks
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://w
e file 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.
, for instance.
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Wed, Jul 19, 2017 at 3:19 PM, Martin Cuma wrote:
> Hi Ben,
>
> I finally got all the dependencies in and built Paraview from the source
> with the debug options on our CentOS 7 ma
eased cray-python module instead of anaconda.
- Chuck
On Sun, Jul 9, 2017 at 6:56 PM, Cory Quammen
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
> tips to get yo
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 C
-D__STDC_LIMIT_MACROS
LLVM_LDFLAGS:-L/opt/clang/4.0.0/lib
PYTHON2: python2.7
Run 'make' to build Mesa
------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Fri, May 12, 2017 at 10:25 AM, Patrick Begou <
patrick.be...@legi.greno
7;re using
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&D Engineer, Scientific Computing
Kitwa
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 AM
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
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.
-DVTK_USE_X=
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 externa
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 l
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 A
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 s
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 you'
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&D Engineer, S
ored, you can use to
set the volume representation:
q = OpenDataFile("someFile.raw")
...
qDisplay = Show()
qDisplay.SetRepresentationType('Volume')
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
___
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&D Engineer, Scientific Computing
Kitware, Inc.
On Thu, Dec 29, 2016 a
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 p
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 fa
>
> In my case, the dataset consists only of random numbers and it's in a
>> single partition. I will try to generate a dataset in parallel in a few
>> days and render it as you told me.
>>
> 5M point's is actually a pretty small dataset that should be easy to
> handle from a rendering standpoint,
>
> Thank you Chuck and I appreciate your detailed reply very much!
>
You welcome :-)
I have to say that I'm a rookie in the field of parallel computing and
> visualization.
>
The only way to gain knowledge and experience is by doing. It will pass
and you'll get more comfortable with the various
>
> 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 or
keep around.
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Mon, Dec 19, 2016 at 6:19 PM, Christopher Neal
wrote:
> Thank you for the suggestions Chuck,
>
> I tried the configuration: EL7-OSMesa.cmake with the edit that you
> suggested.
>
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
ny different users tend to use it in many
different ways. I hope this helps give you a good place to start though.
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Mon, Dec 19, 2016 at 12:30 PM, Christopher Neal
wrote:
> Hi all,
>
> I just saw
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 c
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Fri, Oct 7, 2016 at 4:39 PM, Chuck Atkins
wrote:
> which are not copied into the archive when packing the binaries using:
>>> “ctest -V -R cpack-paraviewsdk-TGZ”
>>>
>>
>> This should have been
>
> 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 g
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
>
> > 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
> >
Yes. Off by a month, my mistake. The intent is to let the survey run for
a week.
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Mon, Sep 26, 2016 at 3:03 PM, Ben Boeckel
wrote:
> On Mon, Sep 26, 2016 at 14:01:38 -0400, Chuck Atkins wrote:
> &
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&D Engineer, Scientific Computing
Kitware, Inc.
On Fri, Sep 23, 2016 at 3:05 PM, Chuck Atkins
wrote:
> We're trying to identify where
f 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
St
> 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. If
er but you get the libGL
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
ccess the
repo from our public gitlab server by cloning
https://gitlab.kitware.com/xdmf/xdmf.git .
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183
On Thu, Jul 21, 2016 at 9:43 AM, Nabil Ghodbane
wrote:
> hi Tom,
> many thanks for your repl
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 visualis
12:12 PM, Dennis Conklin
> wrote:
> > Chuck,
> >
> >
> >
> > This is what I get – none of this means anything to me!
> >
> >
> >
> > Dennis
> >
> >
> >
> >
> >
> > Xlib: extension "NV-GLX" missing on di
ns 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 [mailto:chuck.atk...@kitware.
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 Apr
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)
pvser
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
wrote:
> I have: Server Type = Client/Server
>> Host=localhost
>&
>
> 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
EGL_opengl_LIBRARY:FILEPATH
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
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
66 >
>>>
>>> From: David E DeMarle >> mailto:dave.dema...@kitware.com > >
>>> Date: Monday, March 21, 2016 at 1:08 PM
>>> To: Rick Angelini >> mailto:richard.c.angelini@mail.mil
>>> > >
>>> Cc: ParaView >> m
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 \
-DMPI_C_COM
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 -
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
>
> 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, whe
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
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 fo
dParty/tiff/vtktiff/CMakeFiles/vtkmkg3states.dir/all] Error 2
> make: *** [all] Error 2
>
>
> ganesh
>
> On Thu, Jul 16, 2015 at 2:19 PM Chuck Atkins
> wrote:
>
>> If it's a problem with HDF5 library, I'm not sure where I need to point
>>>>&g
>
> 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 i
ry configuring ParaView starting from that environment.
Out of curiosity, 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
Visi
61 matches
Mail list logo
