Known issues

IPM Not Reporting the FLOPS You Think It Should

If you use the NERSC IPM tool to examine either Floating-Point Operation (FLOP) count or rate you will probably observe a value that is different from what you might expect.  This is not an IPM issue; it is a PAPI issue.   PAPI is the underlying capability used to access the operation counters in the hardware.  So it is really an issue with the Sandybridge processor itself and the very complex way its hardware counters work (in comparison with older processors). You can view this link for more information on this issue.  Note that CrayPat is likeley to be affected, also.  You should not use IPM to assess the floating-point performance of your code on Edison, especially in comparison with Hopper.

Lustre File Positioning Bug

A critical bug has been reported to Cray regarding file positioning in $SCRATCH.  The bug does not affect $HOME or project.  A file's position being reported by lseek may not be what is expected.  The bug may appear using the C++ std library function tellp() or the C "lseek" library or system functions.   

Intel libraries are missing

PETSc and some other libraries, such as Trilinos, are not yet available with the Intel programming environment on Edison. (They are available for Cray and GNU programming environments.)  Cray is planning to make these available, although no timeframe yet.

Error message: undefined reference to __pgas_register_dv

When using Cray compilers you may see the error message: undefined reference to '__pgas_register_dv' . This issue is expected to be fixed in future operating system releases. Until then, use the following work-arounds.  We are indebted to the NCSA Blue Waters Project for identifying this problem and providing the fix.

• Using C++ compiler:  include the flag "-hnopgas_runtime"
• For other compilers:  add the link flags: "-lpgas-dmapp"

GPFS issues with the shared file read

Shared file reads against the global file systems, e.g., global scratch and global project directories,  may perform poorly or hang on Edison, and it may cause the whole Edison system to be unresponsive. The problem may also spread to other NERSC computing platforms that share these file systems. We are working with vendors to resolve this issue. Until this problem is fixed, users are not recommended to run any jobs that do shared-file reads against the global file systems on Edison.