[Paraview] [Non-DoD Source] Building on Cray systems

Fri Feb 26 16:09:31 EST 2016

Hi Andy, 

I finally buckled down and got everything updated in our code to handle dynamic linking on Crays. It was actually pretty easy to write the platform file for it. 

I was able to build and run with coprocessing on Copper. I will be trying on Excalibur, Gordon, Conrad, Shepard and Lightning next. For all of those, I will try the superbuild provided script first to see if it works. Hopefully it does. 

Tim 

----- Original Message -----

From: "Andy Bauer" <andy.bauer at kitware.com> 
To: "tim gallagher" <tim.gallagher at gatech.edu> 
Cc: "paraview" <paraview at paraview.org>, "Chuck Atkins" <chuck.atkins at kitware.com> 
Sent: Thursday, February 25, 2016 11:44:28 AM 
Subject: Re: [Paraview] [Non-DoD Source] Building on Cray systems 

Hi Tim, 

Yep, you did update the list a while ago. I just wanted to make sure you weren't stuck on something that I could potentially help with. 

Good luck! 
Andy 

On Thu, Feb 25, 2016 at 11:28 AM, Tim Gallagher < tim.gallagher at gatech.edu > wrote: 

Hi Andy, 

Sorry, I thought I updated the list awhile ago! 

Using the scripts that Richard provided, I was able to build on Copper and could run the FEM coprocessing demo. But I got stuck trying to get our code to link against it. Our code is set up using the Catamount toolchain file and so things like dynamic linking don't work with the way we have been doing our build. So, I need to try and figure out how to change our build system setup to get everything to work properly. It doesn't work if we just stop using the toolchain. 

I haven't figured that bit out yet; it's on my todo list. But I was able to get PV to build with Richard's script. 

I also could not get the script that comes with the superbuild to work either, but did not dig into it because I had something that did work. 

Tim 

From: "Andy Bauer" < andy.bauer at kitware.com > 
To: "Chuck Atkins" < chuck.atkins at kitware.com > 
Cc: "tim gallagher" < tim.gallagher at gatech.edu >, "paraview" < paraview at paraview.org > 
Sent: Thursday, February 25, 2016 11:21:27 AM 
Subject: Re: [Paraview] [Non-DoD Source] Building on Cray systems 

Hi Tim, 

Were you able to get Catalyst built on any of those machines? I briefly tried on Copper and Garnet with the superbuild but hit some failure that I didn't investigate further. 

Best, 
Andy 

On Mon, Feb 8, 2016 at 2:51 PM, Chuck Atkins < chuck.atkins at kitware.com > wrote: 

<blockquote>

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 --parallel=8 
make -j8 install 

The resulting CMake binary can then run on either the login nodes or compute nodes and target anything that CMake supports. I would also suggest building CMake from either the latest git master branch or the current 3.5 release candidate. I've added a new platform file for the Cray Linux Environment that knows how to introspect the compiler wrappers, correctly deal with static / shared, etc, not currently available in the 3.4 release. You can use it by loading your appropriate PrgEnv module setting CMAKE_SYSTEM_NAME=CrayLinuxEnvironment or using a toolchain file like this: 

# The name of the target operating system 
set(CMAKE_SYSTEM_NAME CrayLinuxEnvironment) # This handles all the oddball Cray stuff 

if(DEFINED ENV{ASYNCPE_DIR}) # Older Cray programming environment 
set(COMP_DIR $ENV{ASYNCPE_DIR}) 
elseif(DEFINED ENV{CRAYPE_DIR}) # Newer Cray programming environment 
set(COMP_DIR $ENV{CRAYPE_DIR}) 
else() 
message(FATAL_ERROR "Unable to determine compiler dir") 
endif() 

# Set the compilers 
set(CMAKE_C_COMPILER ${COMP_DIR}/bin/cc) 
set(CMAKE_CXX_COMPILER ${COMP_DIR}/bin/CC) 
set(CMAKE_Fortran_COMPILER ${COMP_DIR}/bin/ftn) 

- Chuck 

On Fri, Feb 5, 2016 at 5:36 AM, Tim Gallagher < tim.gallagher at gatech.edu > wrote: 

<blockquote>

Sorry if you get this multiple times -- the original was blocked from the PV list because the output log was too big. I can send the log I referred to off-list to anybody who is interested. 

-------------------------------------------------- 

Good morning! 

Thanks Andy and Richard for the advice. 

After banging my head on my keyboard for most of the day yesterday , neither approach worked on Copper. 

For Andy's suggestion of building pv5.0 with the Cray cross compiling script, I got a bunch of errors towards the end. It looks like many things did build, but then those errors about an unknown system kicked in and it seemed to all fall apart. I attached the output log as cray_build_pv5.0.txt 

Richard, I tried your setup as well. I initially was trying to avoid the building CMake step but eventually something in the ParaviewSuperbuild failed because it said it needed CMake 2.8.11 and Copper only has 2.8.10. So, I took a step back and tried to build CMake. When I just do what is in your script -- configure and then make -- the build fails quickly because it says it cannot statically link shared libraries. So I tried to build CMake using the Catamount.cmake toolchain that we use for our application code as well. The initial configuration took over an hour, it sits at 95% for a long time going through the portion where it looks for various headers/features. But eventually it finishes and I tried to build but that failed. I get: 

tgallagh at copper01:~/cmake/build> make 
[ 3%] Built target cmsys 
[ 4%] Built target cmsys_c 
[ 6%] Built target cmzlib 
[ 6%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/strerror.c.o 
/u/tgallagh/cmake/cmake/Utilities/cmcurl/lib/strerror.c:32:6: error: #error "strerror_r MUST be either POSIX, glibc or vxworks-style" 
# error "strerror_r MUST be either POSIX, glibc or vxworks-style" 
^ 
make[2]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/strerror.c.o] Error 1 
make[1]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/all] Error 2 

So taking a big step backwards here to look at the big picture -- am I (and our lab) just using Cray systems in a fundamentally incorrect way? We've always struggled to get things to build when we never have had issues with SGI/Intel, BlueGene, or IBM machines (even when they were using PowerPC). We used to have all these same issues with our CFD code on Cray as well and the only solution we found was to build all of our codes' libraries statically and drop support for shared libraries. 

I appreciate the help with the scripts. If there's any follow-up advice on what I'm doing wrong in both/either approach, that would be great. 

Thanks, 

Tim 
_______________________________________________ 
Powered by www.kitware.com 

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html 

Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView 

Search the list archives at: http://markmail.org/search/?q=ParaView 

Follow this link to subscribe/unsubscribe: 
http://public.kitware.com/mailman/listinfo/paraview 

_______________________________________________ 
Powered by www.kitware.com 

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html 

Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView 

Search the list archives at: http://markmail.org/search/?q=ParaView 

Follow this link to subscribe/unsubscribe: 
http://public.kitware.com/mailman/listinfo/paraview 

</blockquote>

</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160226/0e5e5ca5/attachment.html>