ACT: Matlab front-end for the Acoustic Toolbox written by Alec Duncan from the Centre for Marine Science and Technology at Curtin University.
atWinPII_f95. Version for a Windows, Pentium II machine. The Makefiles are in a sort of Unix style. If you download cygwin (publicly available on the web) you get a sort of pseudo-Unix window in which you can just type 'make all' and 'make install' to recompile and install.
atLinuxPII_f95. Same as above but with binaries compiled under Linux.
BELLHOP: A beam/ray trace code
KRAKEN: A normal mode code
Fortran compilers differ in whether record lengths should be declared as bytes or words. To ensure the programs run, I declare lengths in bytes. If your compiler uses words as the default, look for a compiler switch to override that so that your files are not unnecessarily large.
Some of the programs in this package use direct
access I/O
and need to know a record length. Many systems do not maintain this
information
as part of the file info so the code writes that information directly
into the
file. Then the file is opened twice. First it is opened with a dummy
record
length to read the actual record length from the file. Then it is
re-opened
with the correct record length. On machines that do
know the correct record length, that first open may generate an
error message and will have to be removed. The RECL specifier
should then also be removed from the second open.
The Twersky-scatter option is problematic because it calls mathieu.f and slbessel.f which don't adhere to a rigorous Fortran standard. To avoid this problem, the current distribution has this option disabled.
If you want to put it back in, you will need to link to twersk.f instead of twerskfuse.f. These routines call mathieu.f which needs to be compiled with a switch to initialize all variables to zero. Most compilers have some such switch.
Plot packages come and go. However, the output
formats of
the various models are all fairly simple to work with. The distribution
includes Matlab scripts
which
I currently use for plotting. If you don’t have Matlab,
then
these
will
at
least
provide an example of how to read the file
formats.
To run the Acoustics Toolbox, the executables need
to be in your path. The process for
setting your path depends on your operating system. I can't stay
current with the options but here are some things that have worked in
the past:
DOS: add the following to your autoexec.bat to make the scripts executables in your default path:
SET PATH=%PATH%;C:\AT\SCRIPTS;C:\AT\BIN
Windows 2000 (and perhaps NT): right click on the “My Computer” icon and select “Properties”, “advanced”.
Windows XP: go to
control
panel/Performance and Maintenance/System/Advanced and look for the
pushbutton labled “Environment Variables”.
There you can edit the
system variable “Path”.
If you’re having problems, verify your path includes these by typing “path” from a DOS window. Typically you run KRAKEN by typing something like “kraken pekeris”. at the DOS command line, or kraken( 'pekeris') at the Matlab command line.
On Unix/Linux/MacOSX systems you can ensure that path info is set in Matlab at start up by editing .../bin/matlab to add something like:
source
~/.profile
where .profile is the shell start up script that
initializes your path.
Finally, if you use Matlab then you just need to
use the "Set Path" option under the "File" menu. If you include all of
the Acoustics Toolbox in your Matlab path, then the Matlab scripts find
the location of the binaries using the Matlab "which" command.
Once you have the basic code working,
you might want to run
some of the test batteries in at/tests to completely verify your
installation. The m-file, runtests.m runs
the complete suite of tests
using the Fortran binaries. The m-file runtestsM.m does the same thing,
using the Matlab versions of BELLHOP, SCOOTER, BOUNCE, and SPARC.
(Check also the individual subdirectories for updates on individual components of the Acoustics Toolbox.)
December 1997
Minor changes have been made to the package for improved f77 to f90 portability. Fortran 90 seems to treat parameters differently in terms of precision so some of those changes are important for the most accurate results.
July 1999
The whole package has been converted to f90/95 standard with free-format lines and taking advantage of dynamic allocation. The code is more concise and portable. Dynamic allocation means that you will not have to worry about dimensional limits--- the size of the problem you can solve is limited only by RAM on your system.
The change to dynamic allocation has forced a small change in the input structure. Previously an input format was often used with a number of items in a vector followed by the actual vector. For instance, the vector of receiver depths is read this way.
In the new version the number of items in the
vector must appear
on a separate line so that the code can read it, allocate the space,
and then
read the vector contents.
May 2009
The Matlab version of BELLHOP has been replaced by
a new version that traces one beam at a time. The ealier version traced
all the beams in parallel for efficiency; however, the logic is too
complicated to maintain.
December 2009
Converted most "char foo*5' references, which are
deprecated in the new Fortran, in favor of "char (len=5) :: foo".
January 2010
Updated the volume attenuation from the 1967 Thorp
formula to the more recent one in JKPS. Converted all the Fortran
models so that they would determine the file names from the command
line arguments. This eliminates the need for DOS, Unix, or Matlab
scripts to move files around.
July 2010
Made all type conversions, e.g. complex to real or
double to single, explicit. Expanded use of EXPLICIT NONE to ensure all
variable types are called out. Further expansion of the lengths of
variable names to take advantage of Fortran 2003. Expanded use of
strucutre-variables. Additional changes as
described in the read.me files for the various models. This is a fairly
significant revision in terms of the evoloution from Fortran 77 to
Fortran 2003. However, there are virtually no changes to the input and
output files.
Why do I get an
end-of-file in reading the very last line of the envfil?
You left off a carriage return/line feed after the last line, or other appropriate end-of-line marker for your system.
Why do I get a segmentation violation?
You ran a case that required an outrageous amount
of storage. The code is supposed to catch all such cases by detecting
an error in the allocation of dynamic variables (or limits for the few
arrays with fixed dimensions). However, we see cases where the compiler
simply does not handle huge arrays properly.