This README provides instructions for running the test sets for the
SC'14 SCC MATLAB Seismic Data Analysis Scientific Application.
OVERVIEW
========
For a description of the problem, see
html/SeismicAnalysisCompetition.html. The driver routine is
imageModelData.m. There are also helper functions, diffStacked.p and
displayFigure.m, which are explained below in more detail.
There are two test sets: Summer Fault and Summer Salt Tooth (previously
known as fault and salt tooth).
GETTING STARTED
===============
There will be two folders: seismicCompetition and SEGY-files. The
seismicCompetition folder contains all required MATLAB files to run
along with where the results will be stored. At the conference, once
done, the results folder will need to be submitted. The SEGY-files
contain the velocity model and shot record SEG-Y files.
MATHWORKS: How do teams decide which to run?
To run a model, start MATLAB and change directories to the
seismicCompetition folder. The driver routine is imageModelData. Type
>> help imageModelData
for details on how to call it. There is no installation; when
imageModelData is called, it will add the required folders to the
MATLAB path.
NOTE: It is not required that a team call imageModelData with each run
mode (serial, parallel, parallel-gpu). These are the options to
choose from and it will be up to the teams to determine the best mode
to run.
NOTE: parallel-gpu is stubbed and not implemented. It is not a
requirement to implement nor use a GPU. However, if a team chooses to
use a GPU, then presumably some portion of processShotRecords.m would
be written making use of GPUs. AGAIN: IT IS NOT REQUIRED TO WRITE A
GPU VERSION OF THE CODE, BUT IF YOU CHOOSE TO DO SO, IT WILL NEED TO
BE IMPLEMENTED.
It is strongly recommended to run at least the Summer Fault prior to
the conference and preferable the Summer Salt Tooth as well.
NOTE: The test data sets are NOT indicative of the memory requirements
for running the conference data sets.
EXAMPLE
=======
Call imageModelData as such
imageModelData(MODEL,LOCATION-OF-SEG-Y-FILES,RUNMODE)
To run the Summer Fault test model in serial mode, call it as such:
>> imageModelData('SummerFault','/data/SCC/SEGY-files',{'serial'})
As a reference, when tested, 100 iterations took approx. 8.5 minutes
to run serially.
To run the Summer Fault test model in parallel mode, call it as such
(10 workers is only an example and not neccessarily the recommended
pool size for this example or for any conference model).
>> % Start a pool of 10 workers
>> p = parpool(10);
>> imageModelData('SummerFault','/data/SCC/SEGY-files',{'parallel'})
>> % Close the pool
>> p.delete
NOTE: By default parpool will open a pool of workers using the default
profile. A local profile is shipped automatically, running the pool
of workers on the local machine. If the pool of workers should be run
across a collection of compute nodes, a new profile will need to be
created. The profile should instruct MATLAB to either submit to the
MATLAB job scheduler (MJS) or a 3rd party scheduler (e.g. TORQUE,
SLURM, etc.). For more help, type
>> docsearch 'Cluster Configuration'
to see how to either configure for MJS or configure for another
scheduler.
In the SEG-files directory, it would be expected to see the
<MODEL>ModelData folders, for instance
.
..
SummerFaultModelData SummerSaltToothModelData
At the conference, additional ModelData folders will be added. In
each ModelData folder will exist at least the following files
.
..
<MODEL>ShotRecords.segy <MODEL>VelocityModel.segy
NOTE: When testing the SummerSaltTooth model, as a reference, 301
iterations took approx. 22 hours to run serially.
RESULTS
=======
Three result files are generated in the 'results' folder
* <MODEL>_<RunDate>.txt : A time stamp for each iteration
* <MODEL>_<RunDate>_<RunMode>.fig : Where RunMode is defined in
imageModel.m as serial, parallel,
or parallel-gpu.
* <MODEL>_<RunDate>_<RunMode>.mat : A stacked set of images for the
serial/parallel/gpu run
If the run is complete, the scoring will be based on the
<MODEL>_<RunDate>_<RunMode>.mat, by using the diffStacked routine to
compare to the baseline. If the run is not complete, the timings file
will be viewed to see how much was completed in what period of time.
To compare a run with a sample run, run diffStacked
>> diffStacked(MODEL,RUN-1,RUN-2)
Such that one of the runs is the benchmark. It doesn't matter which
run is listed first. In theory, the parallel and serial run should
return the same results, so comparing the two files yields the
following:
>> score = diffStacked('SummerFault','results/SummerFault_SampleRun_serial','results/SummerFault_SampleRun_parallel')
score =
100
The score tells, to a certain tolerance, the absolute difference
between the two images. 100 is the best score, 0 is the worst. To
compare the run with yours, replace one of the files with your result
file. For instance:
>> score = diffStacked('SummerFault','results/SummerFault_SampleRun_serial','results/SummerFault_01-Jan-2014_01-01-01_parallel');
Again, it doesn't matter which file a test result is compared against
to (serial or parallel) nor does it matter the order you list them
when calling diffStacked.
To redisplay a run, call displayFigure
>> displayFigure('results/SummerFault_SampleRun_serial')
For comparisons, the Fault and Salt Tooth models were solved in serial
mode and parallel mode. The resulting stacked images (.mat) and
figures (.fig) have been placed in the results folder.
#