文件列表:

eigenray\angles.m (544, 2002-06-09)
eigenray\c_ann.ssp (54944, 2002-06-09)
eigenray\doc\Tech_Report.pdf (463346, 2002-06-09)
eigenray\doc\colosi_notes.pdf (188325, 2002-06-09)
eigenray\doc\chap8.ps (959150, 2002-06-09)
eigenray\doc\vble.ps (193742, 2002-06-09)
eigenray\doc\RungeKutta2.pdf (41658, 2002-06-09)
eigenray\doc (0, 2006-05-09)
eigenray\go (53, 2002-06-09)
eigenray\include\table.h (368, 2003-07-06)
eigenray\include\path.h (379, 2002-06-09)
eigenray\include\bathy.h (167, 2002-06-09)
eigenray\include\constants.h (318, 2002-06-09)
eigenray\include (0, 2006-05-09)
eigenray\in.ray (1297, 2003-06-30)
eigenray\Makefile (2861, 2003-10-04)
eigenray\Makefile.cusper (2612, 2002-06-09)
eigenray\Makefile.eigenray (2584, 2002-06-09)
eigenray\Makefile.mpieigenray (2609, 2002-06-09)
eigenray\matray.m (3345, 2002-06-09)
eigenray\obj (0, 2006-05-09)
eigenray\plotC.m (139, 2002-06-09)
eigenray\plotray.m (456, 2002-06-09)
eigenray\plot_ssp.m (502, 2002-06-09)
eigenray\plotTF.m (442, 2002-06-09)
eigenray\Save_Ann (590, 2002-06-09)
eigenray\test.bth (117, 2002-06-09)
eigenray\src\derivs.f (2128, 2002-11-24)
eigenray\src\dodeint.f (11286, 2003-10-04)
eigenray\src\getc.f (2092, 2002-06-09)
eigenray\src\dspline.f (990, 2002-06-09)
eigenray\src\ray.f (18840, 2002-06-12)
eigenray\src\dsplint_both.f (1602, 2002-06-09)
eigenray\src\speed.f (9924, 2003-07-06)
eigenray\src\IDrays.f (3599, 2003-10-04)
eigenray\src\drk4.f (8366, 2003-10-04)
eigenray\src\dsort.f (1670, 2002-06-09)
eigenray\src\ray_MPI.f (30609, 2002-06-12)
... ...

Notes March-April 2000 by Brian Dushaw Revised October 2000. Revised May 2001. First formal release of Version 1.0. Revised May 2002. Changed drk4.f to Runge-Kutta-Merson, several small bug fixes See AAA_README_EPSILON Release Version 1.1 The code uses material from Numerical Recipes and so it is subject to all of the copyright restrictions of that package - these are very strict, and you probably cannot redistribute this code. Too bad. make the executable by: make clean ; make The file Makefile may be edited for your own compiler. The code is meant to be generic FORTRAN that should work on any computer. There are three executables that may be made: 1) make -f Makefile.eigenray will make eigenray for a single processor machine. 2) make -f Makefile.mpieigenray will make mpieigenray, an MPI version for parallel processing. This requires that the MPI package be installed, i.e. mpif77, mpirun are available. 3) make -f Makefile.cusper will make cusper, a program that will find the travel times to the lower cusps of the timefront. This is used for calculating the raypaths and travel times of the shadowzone arrivals. The eigenray calculation is executed by: time eigenray < in.ray where in.ray is the file: 8. 12. starting and ending values for ray angle (deg) 100 1500. # rays to sketch out timefront, and depth below which to omit raytrace. 100 # rays in second raytrace 1000 1000 source and receiver depths (meters) 0.0 3000000 start and end ranges (in meters) 1000.0 a minimum range increment for output ray paths 10.0 150.0 z miss - receiver depth tolerance and the maximum acceptable miss 1 Save eigenray paths? 0=no, 1=yes 0 Eigenrays (=0) or Time Front (=1) 1 Enable ocean bottom? 0=no, 1=yes 0.0 Travel time offset (seconds) 0 Template for ray ID? 0=no, 1=yes (Why fill up your disk?) test.ssp Sound speed filename 1500. transistion depth for step size, linear to tanh 5. 125. 500. values of step size at surface, transition depth, and at depth 1e-7 epsilon, e.g. 1e0, 1e-7, 1e-8, or 1e-9, to set accuracy; set to 1e0 to disable; 1e-7 is good starting value Save_Ann A template that may be used for tracking - the same format as ray.info 15 maximum number of bounces before dropping ray 5.0 tolerance for missing ocean bottom test.bth Bathymetry filename c_ann.ssp has 33 depths, 101 profiles test.ssp has 92 depths, 23 profiles In general, the sound speed file has to be to full water depth (5500 m) - the code offers no help to people wanting to throw partial profiles or crudely sampled data at it. The user is expected to, one way or another, provide a sound speed section to this standard depth - in cases for propagation in depths shallower than this either make up some sound speed values (should not be hard) or modify the code to suit your tastes (more difficult). The profiles do not have to be evenly spaced horizontally, however, and the sound speed values can be at arbitrary depths. The user should be aware, however, that the program does no horizontal interpolation of the sound speeds so dramatic changes in adjacent profiles are bound to cause problems. The program interpolates vertically using cubic splines, so poor sampling vertically, or erroneous values, will cause no end of trouble. The user is advised to take the time and construct sensible sound speed sections before using this code. See the "doc" directory for details. Single profiles for range-independent calculations work fine. The matlab program matray.m can be used to load in the variables of the ray predictions - e.g., travel times, arrival depths, etc. HINTS: A) If the depths of the arrivals differ from the receiver depth by more than the tolerance, try a smaller step size or reduce the range increment for output of ray paths. The angle which gives an arrival within tolerance is used to recalculate the ray later. Rays that miss the receiver depth are those for which there is probably a gap in the time front. It is either this depth mismatch, or nothing at all. However, a depth miss of 100 m or so causes a travel time error of only 10-20 ms (perhaps) and the ray turning depths are nearly identical. Until an example to the contrary appears we won't worry too much about it. B) It may or may not be faster to use a fair number of rays for the time front calculation, rather than to try to get the program to do a large number of bisections to find the eigenray. The bisection code is fairly efficient. C) That said, you don't need that many rays to find the eigenrays - try reducing this number. In fact, if you use too many rays you will begin to pick up the same ray multiple times because of the non-linearity of receiver depth with launch angle (probably an artifact of the computation rather than real). Note that unless you manage to miss an entire branch of the timefront, you are always guaranteed to get an eigenray. D) The eigenrays are found by three steps in find_arr.f: Plan A: bisection until arrival is within specified criteria (zmiss) After MAX_BISEC bisections and no success it goes to Plan B. Plan B: brute force calculation of N_BRUTE rays if Plan A fails. After N_BRUTE rays and still no success it goes to Plan C. Plan C: during all the above calculations, the closest reception to the receiver is saved, and this is reported back if Plan A and Plan B fail. This usually means that a gap is in the timefront, so finding the ray within zmiss is impossible. In this case, the closest arrival may miss the receiver by O(100 m) and the travel time may be in error by 10-20 ms (?). Thus, you are guaranteed of finding something, no matter what (even if you don't like it). There are two criteria therefore in "in.ray" the requested tolerance for depth misfit (10 m, say) and the misfit you can live with (150 m, perhaps). If it misses by more than this second criteria the ray is not written out/saved. E) The depth for transition from linear to tanh should be a little bit below the sound channel axis. The integration is sensitive to the depth at which dc/dz is zero. F) To disable ocean bottom, set the flag equal to zero. The bathymetry adds computational overhead to the code. Setting maximum number of bounces equal to zero will calculate only those rays which do not interact with the bottom. G) All of the sound speed profiles must be to the same depth (5500 m), though the depths in each profile do not have to be the same. H) Sometimes a error message occurs during execution such as: too many steps in odeint_short: increase step size or MAXSTP or Miscellaneous problem with ray, or too many bottom bounces Terminating the calculation of this ray Most often this means that a ray somehow got trapped in a near surface duct where step sizes are very small, so that the number of steps was larger than allocated or the ray went haywire. Unless it looks like EVERY ray has such an error, such messages may be usually ignored, since these rays are probably not all that realistic (i.e. they are an artifact of the sound speed profiles given to the code), and they probably would not strike the receiver anyways. If every ray results in such a message, however, then the step size or variable MAXSTP will have to be changed, or the problem otherwise fixed. You might also try smaller step sizes.... Notes on Parallel Computation: The directory src contains ray_MPI.f which is a parallel version of the code. This can be compiled with the Makefile.mpieigenray, OR: copy ray_MPI.f to ray.f (this is why ray_single.f is there...) and edit Makefile to use "mpif77" as its compiler. This presumes that you have installed MPI on your machine. MPI may be obtained several places - one place is: http://www.mcs.anl.gov/mpi/mpich/ The executable has to be copied to each of the remote machines. N.B. Every time you recompile mpieigenray you have to copy the new executable to the remote machines. I recommend setting up a script called something like "mpiray" located in /usr/local/bin, say, that consists of a line like: mpirun -p4pg /usr/local/bin/pgfile mpieigenray and then the file "pgfile" that looks like: computer1 0 /usr/local/bin/mpieigenray computer2 1 /usr/local/bin/mpieigenray computer3 1 /usr/local/bin/mpieigenray computer4 1 /usr/local/bin/mpieigenray where computer1, computer2...are the hostnames of the computers to use and "/usr/local/bin/mpieigenray" gives the location of where to find the "mpieigenray" executable on each of the computers. Then parallel computation can be done by "mpiray < in.ray" Unless you are calculating lots and lots of rays or are at very long ranges it is probably not effective to use this code. In addition, 4-5 processors seem to saturate the efficiency gain - any more than this doesn't gain you a whole lot, it seems. The parallel code itself is just about as efficient as one can get with parallel code - the main time sinks appear to be during an eigenray search if the bisection doesn't work and the code goes to brute force. This occurs on a single processor, so this will hold everybody up. It seems better to pay the price, than to miss the ray (but you can modify find_arr.f to suit yourself).

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：