build error in vtkm_renderer

[pnav]

Howdy all,

Building with vtk-m 1.0, I get the following error in strawman_vtkm_renderer.cpp:

[ 5%] Building CXX object strawman/CMakeFiles/strawman_vtkm_renderer.dir/pipelines/strawman_vtkm_renderer_serial.cpp.o /work/00401/pnav/dev/strawman/src/strawman/pipelines/strawman_vtkm_renderer.cpp(909): error: class "vtkm::rendering::MapperVolume" has no member "SetSampleDistance" volume_renderer->SetSampleDistance(sample_distance);

SetSampleDistance is a member method of vtkm::rendering::raytracing::volumeRendererStructured, but not of vtkm::rendering::MapperVolume. Is this just miscast here?

Thanks!

[mclarsen]

Hi Paul,

VTK-m 1.0 needs a patch to fix two issues with the rendering code. The patch is located in:

https://github.com/LLNL/strawman/tree/develop/scripts/uberenv/packages/vtkm

or just in the strawman_root_dir/scripts/uberenv/packages/vtkm/

Let me know if it does not work.

-Matt

[pnav]

Thanks, will try that. I didn't see mention of the patch in the build instructions (I might have missed it but just looked again and didn't see it). Dunno if spack auto-applies it, as getting spack happy on TACC machines was a rathole deeper than I cared to venture into ;-)

[mclarsen]

Spack should auto-apply the patch and configure it correctly, without any user intervention.

I also failed to mention that there are other configure options that must be set to correctly build with VTK-m. In that directory, there are two files:

vtkm_patch.patch : the patch

and

package.py : contains the cmake options to correctly configure vtk-m for Strawman.

The most important ones are: -DVTKm_ENABLE_TESTING=OFF -DVTKm_BUILD_RENDERING=ON -DVTKm_USE_64BIT_IDS=OFF -DVTKm_USE_DOUBLE_PRECISION=ON

[pnav]

yep, spack really doesn't want to run on our systems, and the instruction page gave the impression that hand-building the components was possible. I might suggest that on the building page

https://llnl.github.io/strawman/BuildingStrawman.html

put something in bold at the top that you really recommend using spack, and if not, one should mine the spack config for the tweaks that are buried there. I understand that spack is convenient (or only) way to build stuff at LLNL, but for places that do not use it, it presents a pretty high bar to adopt strawman if the build depends so much on it. I have already spent longer than I care to admit massaging the dependencies for the various components (EAVL, vtk-m, OSMesa, LLVM, etc etc) due to the particular setup of TACC machines, and to have to try to recreate that within spack, particularly when I'm already not familiar with spack, is tremendously inconvenient.

[mclarsen]

Fair points. There is mention in the documentation of some of the items above, but clearly they are not prominent enough. I will create a new section in the documentation that describes how to build the dependencies from scratch.

[pnav]

Sounds good. Thanks Matt.

[mclarsen]

Please keep me up to date on any further issues so I can make sure I add the relevant information to the documentation. This includes your "massaging" of any other dependencies.

[pnav]

Will do. The chief complications are (1) TACC's module system, which is similar to spack in that it packages installs to known but non-standard locations, and (2) for the Stampede-KNL system, the login nodes are Haswell and the computes are KNL, so additional compiler flags are required throughout to DoTheRightThing for both architectures. I am documenting what is available via module and what the user must build themselves in the host-config file that I will commit.

[pnav]

hit a snag on the BVH tree in EAVL. It looks like the spack package does an install_tree() to pull these... I packaged EAVL with the package.sh in the EAVL dir, but it looks like uberenv pulls its own stuff over (I did manage to get onto the rayTracing branch before all this ;-) )

Copying the src/raytracing/bvh dir by hand to the EAVL install include dir fixed the issue.

[cyrush]

Note: we are locked into an older version of spack for stability, but spack has much better support for modules, etc in newer versions. They just released a new ver of spack in late jan, the hope is to update soon. I know folks at NERSC are hammering out issues for cray systems for spack, hopefully some of the KNL stuff is transferable.