Difference between revisions of "GULP"

From UFRC
Jump to navigation Jump to search
(Blanked the page)
Line 1: Line 1:
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:
 
<pre>
 
/apps/gulp
 
</pre>
 
The most recent executable is located here:
 
/apps/gulp/3.1/intel/ompi-1.2.2/bin/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:
 
<pre>
 
forrtl: error (69): process interrupted (SIGINT)
 
</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>
 
(channels.F:L103)
 
      if (nunit.lt.0) nunit = - nunit
 
</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>
 
# Intel compiler
 
                echo 'OPT=-O0 -mp1 ' > makefile
 
                echo 'OPT1=-O1 ' >> makefile
 
 
</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 00:42, 6 May 2013