%ALLHP error encountered: out of INTEGER range

Dear all,

I have a problem compiling the NMR and Christallography Software CNS on an AMD Opteron with 16GB RAM and 4 CPUs. After compilation (compiler version 5.2-4) and program execution I get the following message :
#############

linux_opteron_pgcompiler/bin/cns
%ALLHP error encountered: out of INTEGER range
(CNS is in mode: SET ABORT=NORMal END)
WARNING: program encountered a fatal error.
However, in interactive mode, program execution
will continue. Proceed at your own risk.
Program will stop immediately.
============================================================
Maximum dynamic memory allocation: 480000 bytes
Maximum dynamic memory overhead: 12 bytes
Program started at: on
Program stopped at: 21:52:33 on 11-Apr-05
CPU time used: 0.0000 seconds
============================================================
FORTRAN STOP


#############
These, I guess, are non program error message parts:
%ALLHP error encountered: out of INTEGER range

FORTRAN STOP

I played around with the -i8 option but as the program is linked with C objects it doen’t work and I get segmentation faults then. Might there be a way to tell pgcc to use INTEGER*8 somehow?

The problem persists independently of the options chosen, even no options produce these resuls. Defining NO_STOP_MESSAGE doesn’t help as the program still stops on it’s own.

I would really like to know how to avoid this and appreciate any help on this topic.

Kind regards,
Marcel Reese

Hi Marcel,

I’ve put in a request to get a copy of the source but since their license is restricted to academic use, I’m not sure it will be approved. If they allow me to download the source, I’ll see what I can determine.

I’ve looked around the internet and the “CNS software package” Yahoo group (See: Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos). If you search the Yahoo group for “opteron” you’ll see a few others who have had problems getting things working. Although he didn’t post his configuration, at least one user (see message 793) has posted some benchmark results using an AMD64. This suggests that you should be able to get things to work, if configured correctly.

I’d try a couple of things. First, compile in 32-bits (add “-tp k8-32” to the compialtion flags) to see if the problem is a 64-bit porting issue. Second, if available, look at the DEC Alpha configuration and see if there is about the sizes of integers and pointer. Comparing the DEC Alpha configuration might give some clues on how to configure CNS for 64-bits. Finally, I’d either post a message in the CNS group or email some of the people who have gotten it to work.

Let us know what you find out.

Thanks,
Mat

Dear Mat, dear Others,

Actually I had succesfully compiled CNS before on an Opteron (2GHz)but used gcc 3.3.3 compiler, which was pretty slow in comparision to Xeon 3,06Ghz: 9min/5min for 100ps MD with my molecular system. I also used very optimized code from the Xeon Compilation directly which was even slower: 10min. With my present Opteron Portland Group compilation I reach 5min like in the Xeon case. ( I don’t have seconds or such)

Here I will give you the neccessary modifications to files. I was only interesed to make things fast. Might be someone tries to make it nice, too?

  1. Step:

modify cns_solve_1.1//bin/getarch, make a copy first. This script will identify your machine for cns before compilation, or not. For the opteron I just added the line with my favorite architecture name:

echo “linux_opteron_pgcompiler”

before the exit and commented out the line:

#echo “unknown-${MACHINE}-${SYSTEM}”

Now the opteron is “detected” when no other architecture is detected. This is DIRTY

  1. Step
    Add a approprotate “supported” machine type subdirectory with the same architecture name as used above:
    cd cns_solve_1.1
    cp -r instlib/machine/supported/linux instlib/machine/supported/linux_opteron_pgcompiler

  2. Step
    Modify the compilation options in instlib/machine/supported/linux_opteron_pgcompiler/Makefile.header

Here the Portlandgroup Compiler setup:
###############################################################################

Machine dependent Makefile header for CNSsolve

Paul Adams 20-10-98

copyright Yale University

###############################################################################

fortran options

F77 = pgf77
F77STD = -w -i8 -O3 -Mcache_align -Mdalign -Munixlogical -fastsse -Mipa=fast
F77OPT = -i8 -O3 -Mcache_align -Mdalign -Munixlogical -fastsse -Mipa=fast
F77FLAGS = $(F77STD) $(F77OPT) $(EXT_F77FLAGS) $(F77BUG)

C options

CC = pgcc
CCFLAGS = -c -DCNS_ARCH_TYPE_$(CNS_ARCH_TYPE) $(EXT_CCFLAGS) -O3 -Mcache_align -Mdalign -fastsse -Mipa=fast

link options

LD = pgf77
LDFLAGS = $(EXT_LDFLAGS) -i8 -O3 -Mcache_align -Mdalign -Munixlogical -fastsse -Mipa=fast

utility programs

compile-utils:
@ cd $(CNS_INST)/utils;
make utils F77=“$(F77)” CC=“$(CC)”
F77FLAGS=“-O” CCFLAGS=“-O”
F77LINK=“” CCLINK=“-lm” LEXLIB=“fl”

#==============================================================================


Here the gnu compiler setup for people who really need it, at least it works:
###############################################################################

Machine dependent Makefile header for CNSsolve

Paul Adams 20-10-98

copyright Yale University

###############################################################################

fortran options

F77 = g77
F77STD = -c -D_REENTRANT -O3 -fno-globals -Wno-globals -O3 -malign-double -funroll-loops -frerun-loop-opt -ffast-math -m32 -msse2 -mfpmath=sse,387
#-w -Nn2000
F77OPT = -c -D_REENTRANT -O3 -fno-globals -Wno-globals -O3 -malign-double -funroll-loops -frerun-loop-opt-frerun-loop-opt-ffast-math -m32 -msse2 -mfpmath=sse,387
F77FLAGS = -c -D_REENTRANT -O3 -fno-globals -Wno-globals -O3 -malign-double -funroll-loops -frerun-loop-opt -ffast-math -m32 -msse2 -mfpmath=sse,387

C options

CC = gcc
CCFLAGS = -c -D_REENTRANT -O3 -fno-globals -Wno-globals -O3 -malign-double -funroll-loops -frerun-loop-opt -ffast-math -m32 -msse2 -mfpmath=sse,387

link options

LD = g77
LDFLAGS = $(EXT_LDFLAGS) -D_REENTRANT -O3 -fno-globals -Wno-globals -O3 -malign-double -funroll-loops -frerun-loop-opt -ffast-math -m32 -msse2 -mfpmath=sse,387

utility programs

compile-utils:
@ cd $(CNS_INST)/utils;
make utils F77=“$(F77)” CC=“$(CC)”
F77FLAGS=“-O” CCFLAGS=“-O”
F77LINK=“” CCLINK=“-lm” LEXLIB=“fl”

#==============================================================================

  1. Step:

If you compile with gcc skip this -m32 solves the problem I got with the portland compiler (so then this step can be skipted):
%ALLHP error encountered: out of INTEGER range
(see previous messages)

Edit cns_solve_1.1/source/dmemory.c and change line 7 from
#define INTEGER int
to
#define INTEGER long long int.

THIS IS DIRTY. I didn’t check yet if this big INT size is really needed but the program works. If you compile the same source later on a different architecture you might come into trubble. So better make a copy of the original file. It would be very nice to use some -Dx_64 precomilation flag for this, but sorry.

  1. Step
    cd …/cns_solve_1.1
    make install

Should work now. I wonder if an -i8 flag for the pgcc compiler would have solved the problem in Step 4. Might be PGI considers this for later versions?! Your compiler really is very fast it would be nice to compile code like this easily.

Kind regards,
Marcel Reese

Thanks Marcel. I hope this helps other users.

Just some comments:

The reason gcc works is the “-m32” flag which compiles a 32-bit executable. If you compile with “-tp k8-32” and create a 32-bit object, pgcc would most likely work as well with out the change to “solve_1.1/source/dmemory.c” and the addition of “-i8”.

In Fortran, the size of the data types, ie kind, do not change no matter what system your on (except pointers). “-i8” tells pgf90/pgf77 to set the default kind to 8 instead of 4. In C, I’m not sure “-i8” would fit since the size of the data types depends on the system. The only guarantee is that a long int is the same size or bigger than an int and a long long int is the same size of longer than a long int. It’s up to the system designers to determine what the best size is for a particular architecture. For x86, the size of an int and long int are generally 4 bytes, with a long long int being 8 bytes. With AMD64, a long int changes to 8 bytes. In both Fortran and C, pointers do change from 4 bytes on a 32-bit system to 8 bytes on a 64-bit system.

Chapter 10 of our user’s calling. Calling functions between languages in not just 64-bit porting issue, but can be expose porting problems if the programmer has taken the variable nature of data types sizes into account. I believe the programmers of CNS have taken this into account, but might have missed something, or some additional configuration change needs to taken. In general, you shouldn’t really have to use “-i8”, but if it works, Great!

As for your compilation flags, you can remove “-Mcache_align” since it’s part of the aggregate “-fastsse” flag. “-Mdalign” is not needed for your system and should be removed. Move “-O3” after “-fastsse” since “-fastsse” includes “-O2” and the “-O” flags are order dependant with the last one used taking precedence. “-O3” doesn’t always help, so try running your code with and without to see if it does. Also try IPA inlining, “-Mipa=fast,inline” since it can help some codes.

Note that none of your changes are “DIRTY”. Rather they are necessary in order to get your program to properly run on a 64-bit system. Although I don’t know if the Yale project is still active, the clean solution would be to ask the authors to incorporate your changes into a future release of the program, or provide a AMD64 configuration.

Thanks for your work, I’m sure others will benefit from your help!

  • Mat

Dear Mat,

thank you for your detailt explanations. I just used the pgi compiler for the first time and pluged some flags together to finish. I guessed some of them are redundand.

The problem with the C-programm is essentially due to its funtion, it allocates dynamic memory for the fortran parts by alloc… sizeof(INTEGER).

Cheers Marcel

###################

Dear all,

actually you can avoid changing the source code in the c-file because
CNS is already prepared to take a differently defined INTEGER type.
Just use -DINTEGER=“long long int” as an additional CCFLAG when using
-i8 in the Fortran parts.


Cheers,
Marcel

P.S.: I have the impression this topic involves CNS a lot, so I will post further messages likely in Yahoo | Mail, Weather, Search, Politics, News, Finance, Sports & Videos .