[Swift-commit] r3884 - text/parco10submission
noreply at svn.ci.uchicago.edu
noreply at svn.ci.uchicago.edu
Thu Jan 6 23:05:50 CST 2011
Author: wilde
Date: 2011-01-06 23:05:50 -0600 (Thu, 06 Jan 2011)
New Revision: 3884
Modified:
text/parco10submission/paper.tex
Log:
Extended acknowlegements.
Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex 2011-01-07 03:11:06 UTC (rev 3883)
+++ text/parco10submission/paper.tex 2011-01-07 05:05:50 UTC (rev 3884)
@@ -2,9 +2,17 @@
\documentclass[preprint,12pt]{elsarticle}
\usepackage{graphicx}
+\usepackage{fancyvrb}
\usepackage{xcolor}
\usepackage{framed}
+
+\usepackage{float}
+
+\floatstyle{ruled}
+\newfloat{script}{thp}{lop}
+\floatname{script}{Example script}
+
\newcommand{\katznote}[1]{ {\textcolor{cyan} { ***Dan: #1 }}}
\newcommand{\mikenote}[1]{ {\textcolor{red} { ***Mike: #1 }}}
\newcommand{\mihaelnote}[1]{ {\textcolor{green} { ***Mihael: #1 }}}
@@ -1162,367 +1170,13 @@
executable. Swift's existing input file management then
stages-in the application files once per site per run.
+\pagebreak
\section{Applications}
\label{Applications}
-% TODO: two or three applications in brief. discuss both the application
-% behaviour in relation to Swift, but underlying grid behaviour in
-% relation to Swift
-
-% One app: CNARI + TeraGrid - small jobs (3s), many of them.
-
-% Another app: Rosetta on OSG? OSG was designed with a focus on
-% heterogeneity between sites. Large number of sites; automatic site file
-% selection; and automatic app deployment there.
-
This section describes a few representative Swift applications
from various diverse disciplines.
-% \subsection{BLAST Application Example}
-
-% % The following is notes from the Wiki by Allan: needs much refinement, adding here as a placeholder.
-
-% \begin{verbatim}
-% type database;
-% type query;
-% type output;
-% type error;
-
-% app (output out, error err) blastall(query i, database db) {
-% blastall "-p" "blastp" "-F" "F"
-% "-d" @filename(db) "-i" @filename(i)
-% "-v" "300" "-b" "300" "-m8"
-% "-o" @filename(out) stderr=@filename(err);
-% }
-
-% database pir <simple_mapper;prefix="/ci/pir/UNIPROT.14.0.seq">;
-
-% query i <"test.in">;
-% output out <"test.out">;
-% error err <"test.err">;
-
-% (out,err) = blastall(i, pir);
-% \end{verbatim}
-
-% The application {\tt \small blastall} expects the prefix of the database files that it will read (.phr, .seq and .pin files).
-% This example employs a dummy file called {\tt \small
-% UNIPROT.14.0.seq} to satisfy the data dependency. When executed,
-% the Swift script processes the following input directory {\tt\small /ci/pir}:
-
-% \begin{verbatim}
-% -rw-r--r-- 1 ben ci 0 Nov 15 13:49 UNIPROT.14.0.seq
-% -rw-r--r-- 1 ben ci 204106872 Oct 20 16:50 UNIPROT.14.0.seq.00.phr
-% -rw-r--r-- 1 ben ci 23001752 Oct 20 16:50 UNIPROT.14.0.seq.00.pin
-% -rw-r--r-- 1 ben ci 999999669 Oct 20 16:51 UNIPROT.14.0.seq.00.psq
-% -rw-r--r-- 1 ben ci 233680738 Oct 20 16:51 UNIPROT.14.0.seq.01.phr
-% -rw-r--r-- 1 ben ci 26330312 Oct 20 16:51 UNIPROT.14.0.seq.01.pin
-% -rw-r--r-- 1 ben ci 999999864 Oct 20 16:52 UNIPROT.14.0.seq.01.psq
-% -rw-r--r-- 1 ben ci 21034886 Oct 20 16:52 UNIPROT.14.0.seq.02.phr
-% -rw-r--r-- 1 ben ci 2370216 Oct 20 16:52 UNIPROT.14.0.seq.02.pin
-% -rw-r--r-- 1 ben ci 103755125 Oct 20 16:52 UNIPROT.14.0.seq.02.psq
-% -rw-r--r-- 1 ben ci 208 Oct 20 16:52 UNIPROT.14.0.seq.pal
-% \end{verbatim}
-
-% % I looked at the dock6 documentation for OSG. It looks that it recommends to transfer the datafiles to OSG sites manually via globus-url-copy. By my understanding of how swift works, it should be able to transfer my local files to the selected sites. I have yet to try this and will look more on examples in the data management side of Swift.
-
-% % Do you know other users who went in this approach? The documentation has only a few examples in managing data. I'll check the swift Wiki later and see what material we have and also post this email/ notes.
-
-\subsection{fMRI Application Example}
-
-\begin{figure}[htbp]
- \begin{center}
- \includegraphics[scale=1]{img/IMG_fmridataset}
- \caption{fMRI application data structure\label{FMRI_app_image}}
- \end{center}
-\end{figure}
-
-\begin{figure}[htbp]
-\begin{verbatim}
-type Study { Group g[]; }
-type Run { Volume v[]; }
-type Volume {
- Image img;
- Header hdr;
-}
-type Group { Subject s[]; }
-type AirVector { Air a[]; }
-type Subject {
- Volume anat;
- Run run[];
-}
-
-(Run resliced) reslice_wf ( Run r) {
- Run yR = reorientRun( r , "y", "n" );
- Run roR = reorientRun( yR , "x", "n" );
- Volume std = roR.v[1];
- AirVector roAirVec = alignlinearRun(std, roR,
- 12, 1000, 1000, "81 3 3");
- resliced = resliceRun( roR, roAirVec, "-o",
- "-k");
-}
-
-app (Volume ov) reorient (Volume iv,
- string direction, string overwrite) {
-
- reorient @filename(iv.hdr) @filename(ov.hdr)
- direction overwrite;
-
-}
-
-(Run or) reorientRun (Run ir, string direction,
- string overwrite) {
- foreach Volume iv, i in ir.v {
- or.v[i] = reorient (iv, direction, overwrite);
- }
-}
-
-\end{verbatim}
- \caption{fMRI application in Swift\label{FMRI_app_script}}
-\end{figure}
-
-In this example, the logical structure of the fMRI dataset shown in
-Figure~\ref{FMRI_app_image} can be represented by the Swift type declarations in
-lines 1-6 in Figure~\ref{FMRI_app_script}. Here, Study is declared as containing an array
-of Group, which in turn contains an array of Subject, etc. Similarly,
-an fMRI Run is a series of brain scans called volumes, with a Volume
-containing a 3D image of a volumetric slice of a brain image,
-represented by an Image (voxels) and a Header (scanner metadata). An
-Air is a parameter file for spatial adjustment, and an AirVector is a
-set of such parameter files. Datasets are operated on by functions,
-which take typed data described by a mapper, perform computations
-on those data, and produce data to be stored in locations specified
-by a mapper. The
-function {\tt reslice\_wf} defines a compound function, which comprises
-a series of function calls, using variables to establish
-data dependencies.
-
-In the example, {\tt reslice\_wf} defines a four-step pipeline computation,
-using variables to establish data dependencies. It applies reorientRun
-to a run first in the x axis and then in the y axis, and then aligns
-each image in the resulting run with the first image. The program
-{\tt alignlinear} \katznote{should this be alignlinearRun?} determines how to spatially adjust an image to match a
-reference image, and produces an air parameter file. The actual
-alignment is done by the program {\tt reslice}.
-\katznote{or resliceRun?} Note that variable {\tt yR} is
-the output of the first step and the input of the second step, and as such, defines
-the data dependencies between the two steps. %The pipeline is
-%illustrated in the center of % Figure~\ref{FMRIFigure2},
-%while in figure % \ref{FMRIgraph}
-%we show the expanded graph for a 20-volume run. Each
-%volume comprises an image file and a header file, so there are a total
-%of 40 input files and 40 output files. We can also apply the same
-%function to a run containing hundreds or thousands of volumes.
-
-%In this example we show the details of
-The function reorientRun
-is also a compound function.
-The foreach statement defines an iteration over the input run
-{\tt ir} and applies the function {\tt reorient} (which rotates a brain image
-along a certain axis) to each volume in the run to produces a
-reoriented run or. Because the multiple calls to reorient operate on
-independent data elements, they can proceed in parallel.
-
-The function reorient in this example is an atomic function.
-This function has typed input parameters ({\tt iv}, {\tt direction}, and {\tt overwrite}) and
-one output ({\tt ov}). The body specifies that it
-invokes a program (also called reorient) that will be
-dynamically mapped to a binary executable, which will
-execute at an execution site chosen by the Swift runtime system. The
-body also specifies how input parameters map to command line
-arguments. The notation {\tt @filename} is a built-in mapping function that
-maps a logical data structure to a physical file name. In this case,
-it extracts the file name of input header and output header, which are
-then put in the command line to invoke the reorient program.
-
-\subsection{Structural Equation Modeling using OpenMx}
-
-% \cite{OpenMx}
-
-OpenMx is an R library designed for structural equation modeling (SEM),
-a technique currently used in the neuroimaging field to examine
-connectivity between brain areas.
-
-Structural Equation Modeling is greatly enhanced when coupled with
-grid resources and a workflow management system. Traditionally,
-structural equation models have been derived from anatomical models
-based on primate brains out of necessity. It was infeasible to test
-models outside of the hypothetical anatomical model space due to
-restrictions in resources. In contrast, Swift can be used implement a
-scriptable, high-level means for not only testing but generating
-exploratory models in parallel on large clusters, making the testing of
-models outside the (anatomical) hypothesis space a more reasonable goal.
-In light of this, we have developed a ``model generator'' to allow a
-researcher to test all models within a space of potential connections
-without a predefined anatomical model. In the absence of a large-scale
-infrastructure, this would not be doable. For example, within the CNARI
-submit cluster at Chicago, \katznote{is this where jobs are run? Or just submitted from? If the latter, where are they run?} we have a relatively simple Swift script for
-calling OpenMx to generate and process models in parallel.
-
-\begin{figure}[htbp]
- \begin{center}
- \includegraphics{img/omxFigure}
- \caption{Schematic of a single OpenMx model containing 4
- regions of interest (I through L) with 5 regression starting
- values (asymmetric connections) of weight 0.75 and 4
- residual variances (symmetric connections) of weight 1.0
- \label{omxFigure}}
- \end{center}
-\end{figure}
-
-Using OpenMx's model generator---a set of functions that create
-self-contained, structural equation models---we generated 65,535 R
-objects representing all models with 1 to 16 connections
-of varying weights between 4 pre-selected regions of interest.
-A 4~x~4 matrix represents connections between the four regions,
-with 16 possible connections (connections between the same two
-regions but in different directions are tested separately).
-\katznote{should refer to figure~\ref{omxFigure} here? If so, the residual variances
-part doesn't seem to match this text}
-We queried
-our experiment database for activation values based on the selected
-regions of interest, and the covariance of those regions over 8 time
-points during the emblem \katznote{huh?} experiment was calculated. The covariance of
-each generated model was then compared to the covariance matrix of the
-observed data to determine the best-fitting model. In other words, the
-connection weights (or strength of the relationships between anatomical
-regions) can be explored based on the fit of each model.
-
-%modgenproc.swift
-A Swift script is used to submit each of the necessary computation
-components to TeraGrid's Ranger cluster: a) the model object b) the
-covariance matrix derived from the database and c) the R script which
-makes the call to OpenMx. Once the job is assigned to a node, OpenMx
-estimates weight parameters for each connection within the given model
-that results in a model covariance closest to the observed covariance of
-the data. Each of these compute jobs returns its solution model object
-as well as a file containing the minimum value achieved from that model.
-The processing of these models on Ranger was achieved in less than
-45 minutes.
-
-A model generator was developed for the OpenMx package and is designed
-explicitly to enable parallel execution of exhaustive or partially
-pruned sets of model objects. Given an $n$~x~$n$ covariance matrix it can
-generate the entire set of possible models with anywhere from 0 to $n^2$
-connections; however, it can also take as input a single index from
-that set and it will generate and run a single model. What this means
-in the context of workflow design is that the generator can be
-controlled (and parallelized) easily by a Swift script, using the few lines of
-code in Figure~\ref{omxScript1}.
-
-\begin{figure}
-\begin{verbatim}
-
-1. app (mxModel min) mxModelProcessor(file covMatrix,
- Rscript mxModProc, int modnum, float initweight,
- string cond){
-2. {
-3. RInvoke @filename(mxModProc) @filename(covMatrix) modnum
- initweight cond;
-4. }
-5. file covMatrix<single_file_mapper;file="speech.cov">;
-6. Rscript mxScript<single_file_mapper;file="singlemodels.R">;
-7. int totalperms[] = [1:65536];
-8. float initweight = .5;
-9. foreach perm in totalperms{
-10. mxModel modmin<single_file_mapper;
- file=@strcat(perm,".rdata")>;
-11. modmin = mxModelProcessor(covMatrix, mxScript, perm,
- initweight, speech);
-12. }
-\end{verbatim}
-\caption{Swift script for 4-region exhaustive SEM for a single experimental condition\label{omxScript1}}
-\end{figure}
-
-First, a covariance matrix containing activation data for 4 brain regions,
-over 8 time points, averaged over a group of subjects in the speech
-condition was drawn from the experiment database and its location
-(in this example, on the local file system, though the file could be located
-anywhere) is mapped in line 5. Line 6 maps the R processing script and
-lines 1 through 4 define the atomic function for invoking R. The script
-includes a foreach loop, each iteration
-of which maps its optimized model output file and calls
-mxModelProcessor() with the necessary parameters to generate and
-run a model. Each of these invocations of mxModelProcessor() is
-independent and is submitted for processing in parallel. Swift passes
-5 variables for each invocation: (1) the covariance matrix; (2) the R
-script containing the call to OpenMx; (3) the permutation number,
-i.e., the index of the model; (4) the initialization weight for the free
-parameters of the given model; and (5) the experimental condition.
-Clearly, in this workflow all free parameters of the given model will
-have the same initialization weight as Swift is passing only one weight
-variable. When the job reaches a worker node (for example, on the
-TeraGrid Ranger system at TACC), an R process is initialized, the
-generator creates the desired model by calculating where in the array
-that permutation of the model matrix falls. OpenMx then estimates the
-model parameters using a non-linear optimization algorithm called
-NPSOL~\cite{NPSOL}
-and the optimized model is returned and written out by Swift to the
-location specified in its mapping on line 10.
-
-This script completed in approximately 40 minutes. The script can
-then be altered to run over multiple experimental conditions by adding
-another outer loop, as shown in Figure~\ref{omxScript2}.
-With the outer loop, the new workflow consists of 131,072
-jobs, since we are now running the entire set for two conditions.
-This workflow completed in approximately 2 hours
-
-\begin{figure}
-\begin{verbatim}
-1. string conditions[] = ["emblem", "speech"];
-2. int totalperms[] = [1:65536];
-3. float initweight = .5;
-4. foreach cond in conditions{
-5. foreach perm in totalperms{
-6. file covMatrix<single_file_mapper;
- file=@strcat(cond,".cov")>;
-7. mxModel modmin<single_file_mapper;
- file=@strcat(cond,perm,".rdata")>;
-8. modmin= mxModelProcessor(covMatrix, mxScript, perm,
- initweight, cond);
-9. }
-\end{verbatim}
-\caption{Swift script for 4-region exhaustive SEM for 2 experimental conditions\label{omxScript2}}
-\end{figure}
-
-
-\subsection{Molecular Dynamics with DOCK}
-
-\begin{figure}
-\begin{verbatim}
-
-app (file t,DockOut tarout) dock (DockIn infile, string targetlist) {
- dock6 @infile targetlist stdout=@filename(t) @tarout;
-}
-
-type params {
- string ligands;
- string targets;
-}
-
-params pset[] <csv_mapper;file="params.txt">;
-
-runDocks(params pset[])
-{
- foreach params,i in pset {
- DockIn infile < single_file_mapper;
- file=@strcat("/ci/dock/db/KEGGDrugs/",pset[i].ligands)>;
- file sout <single_file_mapper;
- file=@strcat("/ci/dock/results/",pset[i].targes,".",i)>;
- DockOut docking <single_file_mapper;
- file=@strcat(pset[i].ligands,".result.tar.gz")>;
- (sout,docking) = dock(infile,pset[i].targetlist);
- }
-}
-
-params p[];
-p = readdata("paramslist.txt");
-runDocks(p);
-\end{verbatim}
-\caption{Swift script for running Dock\label{DockScript}}
-\end{figure}
-
-\katznote{no text in this subsection -- no reference to Figure~\ref{DockScript}}
-
\subsection{Satellite image data processing.}
The last example (which come from a class project) processes
@@ -1546,62 +1200,214 @@
\katznote{``above'' isn't above, it's in the script below, which isn't at all
described.}
-\begin{verbatim}
-type file;
-type imagefile;
-type landuse;
+\pagebreak
+Swift example 1: MODIS satellite image processing script
+\begin{Verbatim}[fontsize=\scriptsize,frame=single,framesep=2mm,gobble=7, numbers=left]
+ 1 type file;
+ 2 type imagefile;
+ 3 type landuse;
+ 4
+ 5 # Define application program interfaces
+ 6
+ 7 app (landuse output) getLandUse (imagefile input, int sortfield)
+ 8 {
+ 9 getlanduse @input sortfield stdout=@output ;
+ 10 }
+ 11
+ 12 app (file output, file tilelist) analyzeLandUse
+ 13 (landuse input[], string usetype, int maxnum)
+ 14 {
+ 15 analyzelanduse @output @tilelist usetype maxnum @filenames(input);
+ 16 }
+ 17
+ 18 app (imagefile output) colorMODIS (imagefile input)
+ 19 {
+ 20 colormodis @input @output;
+ 21 }
+ 22
+ 23 app (imagefile output) assemble
+ 24 (file selected, imagefile image[], string webdir)
+ 25 {
+ 26 assemble @output @selected @filename(image[0]) webdir;
+ 27 }
+ 28
+ 29 app (imagefile grid) markMap (file tilelist)
+ 30 {
+ 31 markmap @tilelist @grid;
+ 32 }
+ 33
+ 34 # Constants and command line arguments
+ 35
+ 36 int nFiles = @toint(@arg("nfiles","1000"));
+ 37 int nSelect = @toint(@arg("nselect","12"));
+ 38 string landType = @arg("landtype","urban");
+ 39 string runID = @arg("runid","modis-run");
+ 40 string MODISdir= @arg("modisdir","/home/wilde/bigdata/data/modis/2002");
+ 41 string webDir = @arg("webdir","/home/wilde/public_html/geo/");
+ 42
+ 43 string suffix=".tif";
+ 44
+ 45 # Input Dataset
+ 46
+ 47 imagefile geos[] <ext; exec="modis.mapper",
+ 48 location=MODISdir, suffix=".tif", n=nFiles >; # site=site
+ 49
+ 50 # Compute the land use summary of each MODIS tile
+ 51
+ 52 landuse land[] <structured_regexp_mapper; source=geos, match="(h..v..)",
+ 53 transform=@strcat(runID,"/\\1.landuse.byfreq")>;
+ 54
+ 55 foreach g,i in geos {
+ 56 land[i] = getLandUse(g,1);
+ 57 }
+ 58
+ 59 # Find the top N tiles (by total area of selected landuse types)
+ 60
+ 61 file topSelected<"topselected.txt">;
+ 62 file selectedTiles<"selectedtiles.txt">;
+ 63 (topSelected, selectedTiles) = analyzeLandUse(land, landType, nSelect);
+ 64
+ 65 # Mark the top N tiles on a sinusoidal gridded map
+ 66
+ 67 imagefile gridMap<"markedGrid.gif">;
+ 68 gridMap = markMap(topSelected);
+ 69
+ 70 # Create multi-color images for all tiles
+ 71
+ 72 imagefile colorImage[] <structured_regexp_mapper;
+ 73 source=geos, match="(h..v..)",
+ 74 transform="landuse/\\1.color.png">;
+ 75
+ 76 foreach g, i in geos {
+ 77 colorImage[i] = colorMODIS(g);
+ 78 }
+ 79
+ 80 # Assemble a montage of the top selected areas
+ 81
+ 82 imagefile montage <single_file_mapper; file=@strcat(runID,"/","map.png") >; # @arg
+ 83 montage = assemble(selectedTiles,colorImage,webDir);
-app (landuse output) getLandUse (imagefile input, int sortfield)
-{
- getlanduse @input sortfield stdout=@output ;
-}
+\end{Verbatim}
+%\end{verbatim}
-app (file output, file tilelist) analyzeLandUse (landuse input[], int usetype, int maxnum)
-{
- analyzelanduse @output @tilelist usetype maxnum @filenames(input);
-}
+\pagebreak
+\subsection{Simulation of glassy dynamics and thermodynamics.}
-app (imagefile output) colormodis (imagefile input)
-{
- colormodis @input @output;
-}
+Recent study of the glass transition in model systems has focused on calculating from theory or simulation what is known as the "Mosaic length". Glen Hocky of the Reichman Lab at Columbia applied a new cavity method for measuring this length scale, where particles are simulated by molecular dynamics or Monte Carlo methods within cavities having amorphous boundary conditions. Various correlation functions are calculated at the interior of cavities of varying sizes and averaged over many independent simulations to determine a thermodynamic length. Hocky's simulations this method to investigate the differences between three different systems which all have the same "structure" but differ in other subtle ways to see if it is in fact this thermodynamic length that is there difference between the models.
-imagefile geos[]<filesys_mapper; location="/home/wilde/bigdata/data/modis", suffix=".tif">;
-landuse land[]<structured_regexp_mapper; source=geos,match="(h..v..)", transform="\\1.landuse.byfreq">;
+Rather than run ~500K-1.5M steps per jobs (which a priori i didn't know how many i would run anyway) i ran 100K at a time. hence the repetitions of runs. But i would say the campaign started more like in october. if all the jobs are on pads then it'll be more obvious.
-# Find the land use of each modis tile
+As this simulation was a lengthy campaign (from about October through December 2010) Hocky chose to leverage Swift ``external'' mappers to determine what work remained during various restarts. His mappers assumed an application run was complete if all the returned ".final" files existed. In the case of script restarts, results that already existed were not computed. The swift restart mechanism was also tested and worked fine, but required tracking which workflow was being restarted. Occasionally missing files caused the restart to fail; Hocky's ad-hoc restart via mappers worked exceedingly well (and perhaps suggests a new approach for the integrated restart mechanism).
-foreach g,i in geos {
- land[i] = getLandUse(g,1);
-}
+A high-level description of the glass simulation campaign is as follows:
-# Find the top 10 most urban tiles (by area)
+loops are: 7 radii x 27 centers x 10 models x 1 job = 1690 jobs per run
-int UsageTypeURBAN=13;
-file bigurban<"topurban.txt">;
-file urbantiles<"urbantiles.txt">;
-(bigurban, urbantiles) = analyzeLandUse(land, UsageTypeURBAN, 10);
+3 methods: kalj (16) kawka(37) pedersenipl (37) for total of 90 runs
-# Map the files to an array
+roughly 152,000 jobs defined by all the run*.sh scripts
-string urbanfilenames[] = readData(urbantiles);
+about 1-2 hours per job
-imagefile urbanfiles[] <array_mapper;files=urbanfilenames>;
+Approximate OSG usage over 100K cpus hours with about 100K tasks of 1-2 hours completed. App has been successfully run on about 18 OG (with the majority of runs have been completed on about 6 primary sites).
-# Create a set of recolored images for just the urban tiles
+This project would be completely unwieldy and much harder to organize without using Swift.
-foreach uf, i in urbanfiles {
- imagefile recoloredImage <single_file_mapper;
- file=@strcat(@strcut(urbanfilenames[i],"(h..v..)"),
- ".recolored.tif")>;
- recoloredImage = colormodis(uf);
-}
+Some runs were done on other resources including UChicago TeraGrid and the only change/addition necessary to run on OSG was configuring the OSG sites to run the science application.
-imagefile geos[]<filesys_mapper;
- location="/ci/modis/2008", suffix=".tif">;
+Is currently investigating whether slightly more advanced techniques will be necessary, in which case I may need to run approximately the same amount of simulations again.
-\end{verbatim}
+\pagebreak
+Swift example 2: Monte-Carlo simulation of quantum glass structures
+
+%\begin{verbatim}
+\begin{Verbatim}[fontsize=\scriptsize,frame=single,framesep=2mm,gobble=7, numbers=left]
+ 1 type Arc;
+ 2 type Restart;
+ 3 type Log;
+ 4
+ 5 type GlassIn{
+ 6 Restart startfile;
+ 7 }
+ 8
+ 9 type GlassOut{
+ 10 Arc arcfile;
+ 11 Restart restartfile;
+ 12 Restart startfile;
+ 13 Restart final;
+ 14 Log logfile;
+ 15 }
+ 16
+ 17 app (GlassOut o) glassCavityRun(
+ 18 GlassIn i, string rad, string temp, string steps,
+ 19 string volume, string fraca, string energyfunction,
+ 20 string centerstring, string arctimestring)
+ 21 {
+ 22 glassRun "-a" @filename(o.final) "--lf" @filename(i.startfile)
+ 23 "--temp" temp "--stepsperparticle" steps "--volume" volume
+ 24 "--fraca" fraca "--energy_function" energyfunction
+ 25 "--cradius" rad "--ccoord" centerstring arctimestring
+ 26 stdout=@filename(o.logfile);
+ 27 }
+ 28
+ 29 CreateGlassSystem()
+ 30 {
+ 31 string temp=@arg("temp","2.0");
+ 32 string steps=@arg("steps","10");
+ 33 string esteps=@arg("esteps","100");
+ 34 string ceqsteps=@arg("ceqsteps","100");
+ 35 string natoms=@arg("natoms","200");
+ 36 string volume=@arg("volume","200");
+ 37 string rlist=@arg("rlist","rlist");
+ 38 string clist=@arg("clist","clist");
+ 39 string fraca=@arg("fraca","0.5");
+ 40 string radii[] = readData(rlist);
+ 41 string centers[] = readData(clist);
+ 42 int nmodels=@toint( @arg("n","1") );
+ 43 int nsub=@toint( @arg("nsub","1") );
+ 44 string savearc=@arg("savearc","FALSE");
+ 45 string arctimestring;
+ 46 if(savearc=="FALSE") {
+ 47 arctimestring="--arc_time=10000000";
+ 48 }
+ 49 else{
+ 50 arctimestring="";
+ 51 }
+ 52 string energyfunction=@arg("energyfunction","softsphereratiosmooth");
+ 53
+ 54 GlassIn modelIn[][][] <ext;exec="GlassCavityOutArray.map",
+ 55 rlist=rlist, clist=clist, steps=ceqsteps, n=nmodels,
+ 56 esteps=esteps, temp=temp, volume=volume,
+ 57 e=energyfunction, natoms=natoms, i="true">;
+ 58 GlassOut modelOut[][][][] <ext; exec="GlassCavityContinueOutArray.map",
+ 59 n=nmodels, nsub=nsub, rlist=rlist, clist=clist,
+ 60 ceqsteps=ceqsteps, esteps=esteps, steps=steps, temp=temp, volume=volume,
+ 61 e=energyfunction, natoms=natoms>;
+ 62
+ 63 foreach rad,rindex in radii {
+ 64 foreach centerstring,cindex in centers {
+ 65 foreach model in [0:nmodels-1] {
+ 66 foreach job in [0:nsub-1] {
+ 67 string fname =
+ 68 @filename(modelOut[rindex][cindex][model][job].final)
+ 69 if (fname != "NULL") {
+ 70 modelOut[rindex][cindex][model][job] =
+ 71 glassCavityRun( modelIn[rindex][cindex][model],
+ 72 rad, temp, steps, volume, fraca, energyfunction,
+ 73 centerstring, arctimestring);
+ 74 }
+ 75 }
+ 76 }
+ 77 }
+ 78 }
+ 79 }
+ 80
+ 81
+ 82 CreateGlassSystem();
+\end{Verbatim}
+%\end{verbatim}
+
\section{Performance Characteristics}
\label{Performance}
@@ -1892,9 +1698,11 @@
This research is supported in part by NSF grants OCI-721939 and
OCI-0944332, and the U.S. Department of Energy under contract
DE-AC02-06CH11357. Computing resources were provided by the Argonne
-Leadership Computing Facility, TeraGrid, the Open Science Grid, the
-Petascale Active Data Store, and Amazon Web Services.
+Leadership Computing Facility, TeraGrid, the Open Science Grid, the UChicago Computation Institute
+Petascale Active Data Store, and the Amazon Web Services Education program.
+The quantum glass example in the article is the work of Glen Hocky of the Reichman Lab of the Columbia University Department of Chemistry. We thank Glen for many contributions and extremely valuable feedback to the Swift project. We gratefully acknowledge the contributions of current and former Swift team members and collaborators Sarah Kenny, Allan Espinosa, Zhao Zhang, David Kelly, Milena Nokolic, Jon Monette, Aashish Adhikari, Marc Parisien, Mats Rynge, Michael Kubal, and Tibi Stef-Praun, Xu Du, Zhengxiong Hou, and Xi Li. The initial implementation of Swift was the work of Yong Zhao and Mihael Hategan.
+
%% \section{TODO}
%% Reference Swift as a follow-on project to VDL in VDS; how does XDTM fit
@@ -1939,8 +1747,6 @@
%% ramble about separation of parallel execution concerns and dataflow spec
%% in the same way that gph has a separation of same concerns... compare contrast
-\mikenote{Ack or add: Sarah, David, Jon, Milena, Yong, Glen, Allan, Zhao, others???}
-
\bibliographystyle{elsarticle-num}
\bibliography{paper,Wozniak} % for ACM SIGS style
More information about the Swift-commit
mailing list