Difference between revisions of "GULP"
| Line 8: | Line 8: | ||
==Compilation on 64-bit Systems with Intel compiler== | ==Compilation on 64-bit Systems with Intel compiler== | ||
When I tried to compile the GULP software on the cluster, the | When I tried to compile the GULP software on the cluster, the | ||
| − | + | compilation went quite smoothly (with the exception of a couple of extra | |
| − | + | characters in format specifications in a couple of files... they are | |
| − | + | ignored by the fortran compiler, but it would be nice if those were | |
| − | + | cleaned up sometime so that the compile is truly clean... I have diffs | |
| − | + | of the four files that have this problem if you want). | |
| − | + | The problem came about with execution of the software, which failed | |
| − | + | miserably with the following error: | |
<pre> | <pre> | ||
| − | + | forrtl: error (69): process interrupted (SIGINT) | |
</pre> | </pre> | ||
| − | + | I then proceeded to compile the software with debug enabled (by the way, | |
| − | + | doing a make gulp_debug appears to be broken) and ran it through the | |
| − | + | debugger. The line it was breaking on each time seemed very innocent: | |
<pre> | <pre> | ||
| − | + | (channels.F:L103) | |
| − | + | if (nunit.lt.0) nunit = - nunit | |
</pre> | </pre> | ||
| − | + | In a comment above this you mention that taking abs(nunit) crashes on a | |
| − | + | DEC. Well, this appears to crash on x86_64. I never tried using | |
| − | + | abs(nunit) as I figured the code you had should just work, so I thought | |
| − | + | that something else must be wrong. | |
| − | + | That was when I started messing with optimization levels of the code. I | |
| − | + | first turned optimization off completely, and the code worked fine with | |
| − | + | test input. I then started ramping up the optimizations only to find | |
| − | + | that optimization of any level on the standard files would break the | |
| − | + | program at this point. | |
| − | + | As it stands now, the optimizations I currently have in the file | |
| − | + | getmachine are as follow: | |
<pre> | <pre> | ||
# Intel compiler | # Intel compiler | ||
| − | + | echo 'OPT=-O0 -mp1 ' > makefile | |
| − | + | echo 'OPT1=-O1 ' >> makefile | |
</pre> | </pre> | ||
| − | + | I then thought to myself that there must be a way to get better | |
| − | + | optimization than this, so I specifically singled out channels.F and | |
| − | + | reduced the optimization on that particular file to nothing, while | |
| − | + | leaving the rest at -O3. This just propagated the fault to a new file. | |
| − | + | It was at this point I gave up as I don't have the time to chase this | |
| − | + | down through all of the different files, so leaving a good portion of | |
| − | + | the code un-optimized is my current option. | |
Revision as of 17:41, 12 April 2007
GULP is a program for performing a variety of types of simulation on materials using boundary conditions of 0-D (molecules and clusters), 1-D (polymers), 2-D (surfaces, slabs and grain boundaries), or 3-D (periodic solids).
Software Location
The software is located on the system in the following location:
/apps/gulp
Compilation on 64-bit Systems with Intel compiler
When I tried to compile the GULP software on the cluster, the compilation went quite smoothly (with the exception of a couple of extra characters in format specifications in a couple of files... they are ignored by the fortran compiler, but it would be nice if those were cleaned up sometime so that the compile is truly clean... I have diffs of the four files that have this problem if you want).
The problem came about with execution of the software, which failed miserably with the following error:
forrtl: error (69): process interrupted (SIGINT)
I then proceeded to compile the software with debug enabled (by the way, doing a make gulp_debug appears to be broken) and ran it through the debugger. The line it was breaking on each time seemed very innocent:
(channels.F:L103)
if (nunit.lt.0) nunit = - nunit
In a comment above this you mention that taking abs(nunit) crashes on a DEC. Well, this appears to crash on x86_64. I never tried using abs(nunit) as I figured the code you had should just work, so I thought that something else must be wrong.
That was when I started messing with optimization levels of the code. I first turned optimization off completely, and the code worked fine with test input. I then started ramping up the optimizations only to find that optimization of any level on the standard files would break the program at this point.
As it stands now, the optimizations I currently have in the file getmachine are as follow:
# Intel compiler
echo 'OPT=-O0 -mp1 ' > makefile
echo 'OPT1=-O1 ' >> makefile
I then thought to myself that there must be a way to get better optimization than this, so I specifically singled out channels.F and reduced the optimization on that particular file to nothing, while leaving the rest at -O3. This just propagated the fault to a new file. It was at this point I gave up as I don't have the time to chase this down through all of the different files, so leaving a good portion of the code un-optimized is my current option.