2007/2008 User Survey Results

Software

• Legend
• Software Satisfaction - by Score
• Software Satisfaction - by Platform
• Software Comments

Legend:

Software Satisfaction - by Score

7=Very satisfied, 6=Mostly satisfied, 5=Somewhat satisfied, 4=Neutral, 3=Somewhat dissatisfied, 2=Mostly dissatisfied, 1=Very dissatisfied

Software Satisfaction - by Platform

7=Very satisfied, 6=Mostly satisfied, 5=Somewhat satisfied, 4=Neutral, 3=Somewhat dissatisfied, 2=Mostly dissatisfied, 1=Very dissatisfied

Comments about Software:   27 responses

• 9 compiler comments
• 8 (non compiler) comments by Franklin users
• 7 general / cross platform software comments
• 4 comments by Seaborg users
• 2 comments by Bassi Users
• 2 comments by Jacquard Users
• 1 comment by an HPSS user
• 1 comments by a PDSF user
• 1 comment by a DaVinci users

Compiler Comments:   9 responses

I think pgi compiler is weak in error message and debug-mode compilation. ...

1. The PGI compilers do not seem nearly as "robust" as the other compilers I have used on x86_64 (gcc, pathscale). I have had several cases where code that works fine with these other compilers causes the PGI compilers to segfault. The OpenMP support is also buggy in my experience. ...

It's amazing how few PathScale compiler licenses are available on Franklin...absolutely astounding. A consultant tells me there's one more purchased, and waiting to be installed. One more...making 3! Yikes. How many users on that machine?

The pathscale compilers frankly aren't F95 compliant. I don't see why the Intel compilers can't be installed on Franklin and Jacquard.

The lack of Intel compilers on franklin is a problem because the Portland compilers cannot give a proper traceback with accompanying line numbers. Also, pgf90 tends to allow mistakes in coding to pass through compilation while ifort catches many of them, assuring more robust code.

My main software frustration at NERSC has been Fortran-compiler incompatibility. One code I use was extended to use parts of Fortran 2003 that PathScale and Portland Group compilers did not support (but Intel did).

A C++ compiler that is stable, standard-compliant, and fast to run would be a big help. specmark executable performance is not an issue really. The two or three percent faster that a binary executes does not matter if it takes all day to compile our applications, and then the compilation ends up breaking and requiring me to spend another two days working around an "internal compiler error". We don't do our compute kernels in C++ anyways, we do those in Fortran.

The ability to switch from the PG environment to the gfortran environment is helpful, because we have encountered several issues with the PG fortran compiler. A complete selection of math libraries for the gfortran environment would make it more useful, however.

(non compiler) Comments by Franklin Users:   8 responses

I think NERSC should add a Gaussian license to Franklin. My jobs on bassi wait for one month now.

I could never get CrayPat to work very well.

Some of the issues I have with software on franklin are related to the fact that "vendors" of some programming libraries don't support CRAY architecture --- in particular CFITSIO library had to be patched. Support for visualization on franklin seems to be pretty nonexistent --- I haven't asked for an xmgrace module but it would be nice...

The general environment is excellent. We appreciate efforts to improve analysis code (eg IDL) usability on Franklin, and need to continue these to optimize usefulness of the machine.

Franklin should have a newer gnuplot and nano/pico

Our code relies extensively on Python. Not having shared libraries on the compute nodes of Franklin is a big problem for us, and has been preventing us from porting our code to Franklin so far.

... 2. The fact that franklin has such a minimal OS, and does not support dynamic library loading, means that some complex analysis codes will simply not run on this machine without extensive patching. It would be nice to know more details about whether there are any plans to ever support dynamic loading.
For example, some of our collaborators use a ton of java software to do massive data analysis (yes, I laughed too when I first heard). In order to run this type of thing on franklin currently, I may be stuck having to compile a version of gcj, and then build a wrapper similar to cc/CC/ftn that statically links in all the CNL libraries. On the other hand, if franklin is going to get dynamic loading soon, I will just wait and run native jni code once it is supported.

... I have a weird hang up which happens only on franklin, but cannot figure out why this happens.

General / Cross Platform Software Comments:   7 responses

I am wondering about how well supported HDF5 stuff will be with H. Anand having departed....

I was surprised there was no 'xv' tool there.

The only significant software problem I encounter at NERSC is that the Totalview debugger is unstable. Totalview is great when it works, but it has a tendency to hang or die for me.
It would also be nice if more code editing and maintenance utilities could be supported. While I recognize that limited personnel resources mean that not all utilities can be supported, such utilities are valuable to code development.

The information on the website was very useful in getting me started.

I continue to be satisfied in general with the software resources I use at NERSC and with the responsiveness of the software maintainers.

The software applications I need have mostly already been available on the computer, but when I have requested new software installation, the staff has been really quick about doing that.

PETSc is a critical library for our application, so we need to have that library kept up to date as compilers are upgraded or a new release is made. The module system for managing the user software environment is very useful, but it needs to be kept up to date with all of the software and programming libraries that are available. I have noticed several instances where modules were out of date or broken or did not exist for a new library version.

Comments by Seaborg Users:   4 responses

I understand the reason why nersc has to remove imsl from seaborg. But, I am not happy about this action.

The OS of Seaborg seems a bit clunky. For example, users can't use the up arrow to get most recent commands, and doesn't do automatic completion.

As earlier, the scope of our project is served well by the current setup at NERSC.

On seaborg, compiling C++ with optimization is very slow.

Comments by Bassi Users:   2 responses

It would be nice if Bassi could be made to function like a Linux system in regards to grep and other simple commands.

Simple, light debugging tools like pdbx on seaborg and bassi (and as opposed to totalview) are crucial for those of us who use the NERSC resources over slow-ish connection (e.g. from Europe).

Comments by Jacquard Users:   2 responses

Software Jacquard could be updated quarterly to be relatively consistent with what is made up to date in our Linux workstations.

I periodically use support softwares such as Mathematica, or Matlab on Jacquard. I have been having consistent trouble with the font configuration of Mathematica when using load module commands.

Comments by HSS Users:   1 response

The HPSS interface options are shockingly bad. e.g. Kamland had to resort to writing hsi wrappers to achieve reasonable performance. The SNfactory wrote a perl module to have a standard interface within perl scripts rather than spawning and parsing hsi and htar calls one by one. Even the interactive interface of hsi doesn't have basic command line editing. htar failures sometimes don't return error codes and leave 0 sized files in the destination locations. NERSC should provide C, C++, perl, and python libraries for HPSS access in addition to htar, hsi, etc. The HPSS hardware seems great, but the ability to access it is terrible.

Comments by PDSF Users:   1 response

While GPFS file system performance has been adequate, it is not evident that GPFS is the most cost effective solution and, therefore, that it is best for computing at PDSF. Any future filesystem choice should thus include the unique PDSF requirements in its decision metrics.

Comments by DaVinci Users:   1 response

I would like to have tecplot on davinci.