SX Compilation Fails

[frae]

I only run a local compilation on the SX at the moment. configure goes through but make yields:

[frae@sx615:ropp_tools2] make
Warning: No suffix list.
Making all in arrays
Making all in build
        f90 -I../build  -dW -I/data/nwp/sa/frae/ropp/nec//include 
        -c -o cpusec.etime.o `test -f '../flib/cpusec.etime.f90' || 
        echo './'`../flib/cpusec.etime.f90
../flib/cpusec.etime.f90:
        f90 -I../build  -dW -I/data/nwp/sa/frae/ropp/nec//include 
        -c -o arrays.o `test -f '../arrays/arrays.f90' || 
        echo './'`../arrays/arrays.f90
../arrays/arrays.f90:

f90: error(453): arrays.f90, line 147: Name "onebyteint" in initialization
                                       expression is not named constant.

.. and more onebyteint trouble

One NEC expert mentioned that the onebyteint problem should be solved with the -dW compilation flag, but apparently it does not. So we might have to remove all onebyteint stuff from ropp.

I attach this to no major milestone, but at least it is on the radar now.

[marq]

Just to clarify - is this on the frontend machine, or on the real SX?

With respect to the OneByteInt: I remember one of the modification people had to make to netCDF to get it compile was to remove the OneByteInt from netCDF. Is this still the case? If we have to remove it, this probably only needs to be done in a few .m4 files in the ncdf subdirectory of ropp_io (mainly the master files generating the various Fortran 90 files - not those which hold the actual source code), and in the typesizes module.

On the other hand, if we could simply stick with the way it is now, I would very much prefer that. We need to be sure, though, that the netCDF library has support for the same data types.

[frae]

I run the compilation locally, meaning on the SX machine itself and not the frontend. The frontend has some trouble with the configure since it tries to run executables compiled for the sx6. I haven't looked into it any further, the current configure I use on the frontend is:

#! /bin/sh
#
# ropp shell script for a local configure at Met Office.
# compiler: sxf90 on frontend for NEC sx

LIBS=/data/nwp/sa/frae/ropp/nec/

# front end name
FRONTEND=`./config.guess`

CC=sxc++ CPPFLAGS=-I$LIBS/include CFLAGS=""        \
       F77=sxf90 FFLAGS="-dW -I$LIBS/include" \
       FC=sxf90 FCFLAGS="-dW -I$LIBS/include" \
       AR=sxar \
       LDFLAGS=-L$LIBS/lib \
       ./configure --prefix=$LIBS --build=$FRONTEND --host=sx6-nec-superux13.1

For the local configure I use:

#! /bin/sh


LIBS=/data/nwp/sa/frae/ropp/nec/

CC=c++ CPPFLAGS=-I$LIBS/include CFLAGS=""        \
       F77=f90 FFLAGS="-dW -I$LIBS/include" \
       FC=f90 FCFLAGS="-dW -I$LIBS/include" \
       LDFLAGS=-L$LIBS/lib \
       ./configure --prefix=$LIBS

According to the documentation coming along with this compiler it should actually be able to compile Fortran 95 code, although it is called f90.

The current netCDF library on the sx6 has no support for onebyteint, that was removed by a patch I got from the net. I did not manage to compile netcdf with the onebyteint, so I assume the compiler does not understand it. If we find a way to make it understand onebyteint, that would be great since no modifications would be necessary. I might asked some NEC people over here. Otherwise we might have to run a patch for ropp as well.

[Huw Lewis]

SX testing to be considered for v1.2 release.

[Huw Lewis]

Since we've never tested ROPP directly on the SX, and the ticket suggests a limitation in the compiler, I suggest we put this one down to the category of 'unsupported due to compiler issues', but leave the ticket in place for now - pushing the milestone out to v3. At some point we should see if onbyteint is now supported or remains as described. I've never logged on to the SX directly (Only the TX frontend), so I don't know how Axel originally found this out. Move to v3.

[Dave Offiler]

There is no requirement to run the complete package on the SX6 (maybe at some point only particular routines within OPS). Further, the SX6 will be replaced by a new supercomputer within the next 6 months, and whatever it is to be, this will have a completely different architecture and compiler set.

Hence this ticket is redundant and closed as a 'won't fix'.

[(none)]

Milestone 3.0 deleted