Right off the bat, we need to find out which compilers are currently installed, and where they are located.  This is relatively straightforward using the “which” command. First the Intel Fortran and C compilers:

[me@machine ~]$ which ifort
/opt/intel/composerxe-2011.3.174/bin/intel64/ifort
[me@machine ~]$ which icc
/opt/intel/composerxe-2011.3.174/bin/intel64/icc

as well as the GNU Fortran and c:

[me@machine ~]$ which gfortran
/usr/bin/gfortran
[me@machine ~]$ which gcc
/usr/bin/gcc

This doesn’t REALLY tell you if these compilers are installed or not, only whether or not the paths to them are in your $PATH variable.  Whenever you type a command, Linux checks to see if that command is in any of the paths in your $PATH.  If it is not, then you will receive an error.  To see what paths are currently in your $PATH variable, a simple echo command will suffice:

[me@machine ~]$ echo $PATH

If you suspect that the desired compilers are indeed installed, but not in your path, start looking in the  /opt/<vendor> directories for the correct paths.  It’s highly unlikely that gcc and gfortran will not be installed (and furthermore, not be in your path), but just in case, they usually live in /usr/bin

Another method for finding the paths to compilers is to use the “locate” command:

[me@machine ~]$ locate ifort

This will bring up a list of paths that contain the phrase “ifort”. This can be very useful, especially in conjunction with the “grep” command.

Once you have located the paths to the compilers, you can add them to your $PATH variable with the following command in BASH  (for other shells, see Google):

[me@machine ~]$ export PATH=$PATH:/home/kyle/tau-2.21/x86_64/bin

Echo-ing your $PATH variable should now reveal that the path has been added.  A good idea is to add that line to one of your login files (.bashrc), so that it executes automatically each and every time you log into the machine.

Of course, one of the primary reasons for running codes on a cluster, is to take advantage of parallelism, and this means compiling parallel programs. We want to make sure that our “MPI Compilers” are accessible as well:

[me@machine geo_benchmark]$ which mpif77
/usr/local/openmpi/bin/mpif77
[me@machine geo_benchmark]$ which mpif90
/usr/local/openmpi/bin/mpif90
[me@machine geo_benchmark]$ which mpicc
/usr/local/openmpi/bin/mpicc
[me@machine geo_benchmark]$ which mpiCC
/usr/local/openmpi/bin/mpiCC

So far, so good. Notice that these are the “openmpi” versions of these compilers. It’s entirely possible that other versions exist as well (MPICH, MPICH2, MPICH-GM, MVAPICH, MVAPICH2).  If you require (or want to switch to) one of these versions, start looking in the /usr/local/ directories to see if they are available.  The “locate” command is helpful here as well.

We may also need Intel’s Math Kernel Library (MKL). It is usually installed in paths similar to Intel’s compilers.  The following are example include and library directories, respectively, for MKL:

/opt/intel/composerxe-2011.3.174/mkl/include
/opt/intel/composerxe-2011.3.174/mkl/lib/intel64

Once you have all of the paths sorted out, figuring out the actual compile line, especially with MKL, can be a nightmare.  Luckily there is a web app to help, the Intel® Math Kernel Library Link Line Advisor.  Check it out.

Finally, with all of this information, you can create a Makefile.  Here’s a stripped down example to help get you started:

FCC = mpif90
CC  = icc
INCDIR = /opt/intel/composerxe-2011.3.174/mkl/include
LIBDIR = /opt/intel/composerxe-2011.3.174/mkl/lib/intel64
LLAPACK = -L${LIBDIR}  -lmkl_intel_lp64 -lmkl_sequential -lmkl_core
LFLAGS =  -lm $(LLAPACK) -I${INCDIR}
OBJ = program.o
program.e: $(OBJ)
        $(FCC)  $(OBJ) -o program.e  $(LFLAGS)
 
program.o: program.f
        $(FCC)   -c program.f
clean:
        rm -f *.o program.e

If all has gone well,  you now have a Makefile with all of the appropriate paths.  If you cannot find all of the correct paths, or straight up suspect that certain software has not been installed, you may want to contact your system administrator.  Good luck.

Lately, there has been all manner of news about some draconian legislation on the verge of being passed in Washington pertaining to Internet regulation.  It’s ironic that a governing body, which in theory should be elected by the people, only manages to pass, in a timely manner, legislation that benefits corporations.  The passing of bills that actually benefit humans, well that of course, has to be debated unto a standstill that ultimately accomplishes nothing.  Makes you wonder who REALLY determines who our “elected” officials shall be.

Anyways, with the Internet constantly under attack, people have been looking for alternatives for sharing information.  One such method is the use of USB Dead Drops, which is an anonymous, offline, peer-to-peer file sharing network.  It was initially conceptualized by  Aram Bartholl, a Germany based artist, who implemented the idea in New York City in October 2011.  The idea is to permanently attach a USB drive to an urban fixture, most commonly using concrete.  The following pictures show some finished products:

This way, people can exchange their favorite files completely anonymously.  Pretty interesting idea, and it got me thinking…

Back in my rave days finding the venue would often involve going to some shady location, called the “map point” in order to get the directions to the party.  This was an attempt to stay one step ahead of the authorities, and decrease the risk of the event getting shut down.  Today, everyone carries computers around with them, and therefore USB Dead Drops could potentially be the new “map points”.

While the initial concept calls for offline Dead Drops, some cool stuff could certainly be done with wired versions.  For example, suppose a hypothetical musician in Sweden has a handful of devout followers in Los Angeles.  One of these fans could set up an internet connected dead drop on to which the artist puts new music (from Sweden, across the Internet).  No, it may not be as convenient as downloading a track from a webpage, but it has an esoteric, cloak-and-dagger, feel to it and I think the right crowd would be receptive to the idea.

I think there are even commercial applications as well.  Imagine a restaurant that has a dead drop out front, containing a “digital business card” with menu/hours/review information available for download.  An apartment complex could share information about available units to potential customers.

More information, including a database and world map of preexisting USB dead drops can be found at deadrops.com.

People often laugh when I tell them I’m a Fortran programmer, mostly because they think it a dead language.  A few friends of mine are/were Computer Science majors and I always ask them if Fortran is offered in the curriculum.  The answer is either a resounding ‘NO’ or something along the lines of ‘yes’ in the form of a backwater elective on super-computing that might touch on the subject.  Regardless, the conversation always ends with me explaining that the language is indeed alive and well, especially in the fields of computational science.

C and Fortran certainly represent the lion’s share when it comes to languages used to write code for super-computing.  Right now I’ve been tasked with creating an identical benchmark in both Fortran and C to see how the languages perform on our cluster.  I suspect they will perform about evenly, with my personal bias rooting for the former.  Since, it’s currently my strongest language, I wrote the benchmark first in Fortran.  Now completed, I’ve moved onto the C version, which is proving to be a nice refresher of a language that I was once much more proficient in.

… and of course, for about the fifth time in my life, I find myself trying to wrap my brain around the concept of pointers.  I often struggled with them when I was younger, and did not understand why anyone would want to use them.  Now, three degrees later, and with a ton of code under my belt, it finally makes sense — and now I wonder why I was so caught up on them back in the day.

Anyways, enough history.  Here’s my (very) brief pointer summary, in just a few lines of code:

To declare a pointer variable which stores not a value, but the address of a value:

int *ptr;

To store the address of a variable into a pointer variable:

ptr = &var;

To store a value in an address pointed to by a pointer variable:

*ptr = 10;

… and remember: by definition, the name of any array is a pointer!

The program itself is a test I wrote to familiarize myself with writing binary files in FORTRAN.

     program BinaryWriter
 
      implicit none
 
      integer sizeofint
      integer :: ii, jj, num
      integer :: mat(5,5)
      parameter (sizeofint=4)
 
      num = 5
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
C
C     Currently set up for direct (random) access.
C     Divides dest. file into records of size recl.
C     For direct access must specify which record
C      for each write statement.
C
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
      open(unit=10,
     +     file='bin_mat.bin',
     +     access='direct',
     +     form='UNFORMATTED',
     +     recl=num*num*sizeofint)
 
      do ii = 1, num
       do jj = 1, num
         mat(ii,jj) = ii+jj
       enddo
      enddo
 
      write(10,rec=1) mat
 
      close(10)
      end program BinaryWriter