[Swift-commit] r3924 - in text/parco10submission: . code
noreply at svn.ci.uchicago.edu
noreply at svn.ci.uchicago.edu
Sun Jan 9 16:48:58 CST 2011
Author: wilde
Date: 2011-01-09 16:48:58 -0600 (Sun, 09 Jan 2011)
New Revision: 3924
Modified:
text/parco10submission/code/glass.swift
text/parco10submission/code/glassRunCavities.swift.ORIG
text/parco10submission/paper.tex
Log:
Updated Glass app code with better code and adjusted the annotated tour to reflect the new lines numbers. This now uses a 2-file inpt structure.
Modified: text/parco10submission/code/glass.swift
===================================================================
--- text/parco10submission/code/glass.swift 2011-01-09 22:02:02 UTC (rev 3923)
+++ text/parco10submission/code/glass.swift 2011-01-09 22:48:58 UTC (rev 3924)
@@ -1,29 +1,31 @@
+type Text;
type Arc;
type Restart;
type Log;
+type Active;
type GlassIn{
- Restart startfile;
+ Restart startfile;
+ Active activefile;
}
type GlassOut{
- Arc arcfile;
- Restart restartfile;
- Restart startfile;
- Restart final;
- Log logfile;
+ Arc arcfile;
+ Active activefile;
+ Restart restartfile;
+ Restart startfile;
+ Restart final;
+ Log logfile;
}
-app (GlassOut o) glassCavityRun(
- GlassIn i, string rad, string temp, string steps,
- string volume, string fraca, string energyfunction,
- string centerstring, string arctimestring)
-{
- glassRun "-a" @filename(o.final) "--lf" @filename(i.startfile)
- "--temp" temp "--stepsperparticle" steps "--volume" volume
- "--fraca" fraca "--energy_function" energyfunction
- "--cradius" rad "--ccoord" centerstring arctimestring
- stdout=@filename(o.logfile);
+app (GlassOut o) glassCavityRun
+ (GlassIn i, string rad, string temp, string steps, string volume, string fraca,
+ string energyfunction, string centerstring, string arctimestring)
+{ glassRun
+ "-a" @filename(o.final) "--lf" @filename(i.startfile) stdout=@filename(o.logfile)
+ "--temp" temp "--stepsperparticle" steps "--energy_function" energyfunction
+ "--volume" volume "--fraca" fraca
+ "--cradius" rad "--ccoord" centerstring arctimestring;
}
CreateGlassSystem()
@@ -39,38 +41,35 @@
string fraca=@arg("fraca","0.5");
string radii[] = readData(rlist);
string centers[] = readData(clist);
- int nmodels=@toint( @arg("n","1") );
- int nsub=@toint( @arg("nsub","1") );
+ int nmodels=strtoi( @arg("n","1") );
+ int nsub=strtoi( @arg("nsub","1") );
string savearc=@arg("savearc","FALSE");
string arctimestring;
+ string energyfunction=@arg("energyfunction","softsphereratiosmooth");
+
if(savearc=="FALSE") {
arctimestring="--arc_time=10000000";
}
else{
arctimestring="";
}
- string energyfunction=@arg("energyfunction","softsphereratiosmooth");
- GlassIn modelIn[][][] <ext;exec="GlassCavityOutArray.map",
- rlist=rlist, clist=clist, steps=ceqsteps, n=nmodels,
- esteps=esteps, temp=temp, volume=volume,
- e=energyfunction, natoms=natoms, i="true">;
+ GlassIn modelIn[][][] <ext; exec="GlassCavityOutArray.map",
+ rlist=rlist, clist=clist, steps=ceqsteps, n=nmodels, esteps=esteps, temp=temp,
+ volume=volume, e=energyfunction, natoms=natoms, i="true">;
+
GlassOut modelOut[][][][] <ext; exec="GlassCavityContinueOutArray.map",
- n=nmodels, nsub=nsub, rlist=rlist, clist=clist,
- ceqsteps=ceqsteps, esteps=esteps, steps=steps, temp=temp, volume=volume,
- e=energyfunction, natoms=natoms>;
+ n=nmodels, nsub=nsub, rlist=rlist, clist=clist, ceqsteps=ceqsteps, esteps=esteps,
+ steps=steps, temp=temp, volume=volume, e=energyfunction, natoms=natoms>;
foreach rad,rindex in radii {
foreach centerstring,cindex in centers {
foreach model in [0:nmodels-1] {
foreach job in [0:nsub-1] {
- string fname =
- @filename(modelOut[rindex][cindex][model][job].final)
- if (fname != "NULL") {
- modelOut[rindex][cindex][model][job] =
- glassCavityRun( modelIn[rindex][cindex][model],
- rad, temp, steps, volume, fraca, energyfunction,
- centerstring, arctimestring);
+ if( !(@filename(modelOut[rindex][cindex][model][job].final)=="NULL") ) {
+ modelOut[rindex][cindex][model][job] = glassCavityRun(
+ modelIn[rindex][cindex][model], rad, temp, steps, volume, fraca,
+ energyfunction, centerstring, arctimestring);
}
}
}
@@ -78,5 +77,4 @@
}
}
-
-CreateGlassSystem();
+CreateGlassSystem();
\ No newline at end of file
Modified: text/parco10submission/code/glassRunCavities.swift.ORIG
===================================================================
--- text/parco10submission/code/glassRunCavities.swift.ORIG 2011-01-09 22:02:02 UTC (rev 3923)
+++ text/parco10submission/code/glassRunCavities.swift.ORIG 2011-01-09 22:48:58 UTC (rev 3924)
@@ -4,9 +4,11 @@
type Arc;
type Restart;
type Log;
+type Active;
type GlassOut{
Arc arcfile;
+ Active activefile;
Restart restartfile;
Restart startfile;
Restart final;
@@ -15,6 +17,7 @@
type GlassIn{
Restart startfile;
+ Active activefile;
}
// Lib functions (to be moved to imported file
Modified: text/parco10submission/paper.tex
===================================================================
--- text/parco10submission/paper.tex 2011-01-09 22:02:02 UTC (rev 3923)
+++ text/parco10submission/paper.tex 2011-01-09 22:48:58 UTC (rev 3924)
@@ -1308,23 +1308,24 @@
managing the large volume of file data.
Example 2 shows a slightly reformatted version of the glass simulation script that was in use in Dec. 2010. Its key aspects are as follows.
-Lines 1-3 define the mapped file types; these files are used to compose input and output structures at lines 5-15. (At the moment, the input structure is a degenerate single-file structure, but Hocky has experimented with various multi-file input structures in prior versions of this script). The output structure reflects the fact that the simulation is restartable in 1-2 hour increments, and works together with the Swift script to create a simple but powerful mechanism for managing checkpoint/restart across a long-running large-scale simulation campaign.
+Lines 1-5 define the mapped file types; these files are used to compose input and output structures at lines 7-19.
+These structure reflect the fact that the simulation is restartable in 1-2 hour increments, and that it works together with the Swift script to create a simple but powerful mechanism for managing checkpoint/restart across a long-running large-scale simulation campaign.
-The single application called by this script is the {\tt glassRun} program wrapped in the app function at lines 17-27. Note that rather than defining main program logic in ``open" (top-level) code, the script places all the program login in the function {\tt CreateGlassSystem}, invoked by the single statement at line 82. This enables the simulation script to be defined in a library that can be imported into other Swift scripts to perform entire campaigns or campaign subsets.
+The single application called by this script is the {\tt glassRun} program wrapped in the app function at lines 21-29. Note that rather than defining main program logic in ``open" (top-level) code, the script places all the program login in the function {\tt CreateGlassSystem}, invoked by the single statement at line 80. This enables the simulation script to be defined in a library that can be imported into other Swift scripts to perform entire campaigns or campaign subsets.
-The {\tt CreateGlassSystem} function starts by extracting a large set of science parameters from the Swift command line at lines 31-44 and 52 using the {\tt @arg()} function. It uses the built-in function {\tt readData} at lines 40-41 to read prepared lists of molecular radii and centroids from parameter files to define the primary physical dimensions of the simulation space.
-A selectable energy function to used by the simulation application is specified as a parameter at line 52.
+The {\tt CreateGlassSystem} function starts by extracting a large set of science parameters from the Swift command line at lines 33-48 using the {\tt @arg()} function. It uses the built-in function {\tt readData} at lines 42-43 to read prepared lists of molecular radii and centroids from parameter files to define the primary physical dimensions of the simulation space.
+A selectable energy function to used by the simulation application is specified as a parameter at line 48.
-At lines 54 and 58, the script leverages Swift flexible dynamic arrays to create a 3D array for input and an 4D array of structures for outputs. These data structures, whose leaf elements consist entirely of mapped files, are set using the external mappers specified for the input array at lines 54-57 and for the output array of structures at 58-61. Note that many of the science parameters are passed to the mappers, which in turn are used by the input mapper to locate files within the large multi-level directory structure of the campaign, and by the output mapper to create new directory and file naming conventions for the campaign outputs. The mappers use the common, and useful practice of using scientific metadata to determine directory and file names.
+At lines 57 and 61, the script leverages Swift flexible dynamic arrays to create a 3D array for input and an 4D array of structures for outputs. These data structures, whose leaf elements consist entirely of mapped files, are set using the external mappers specified for the input array at lines 57-59 and for the output array of structures at 61-63. Note that many of the science parameters are passed to the mappers, which in turn are used by the input mapper to locate files within the large multi-level directory structure of the campaign, and by the output mapper to create new directory and file naming conventions for the campaign outputs. The mappers apply the common, useful practice of using scientific metadata to determine directory and file names.
-The entire body of the {\tt CreateGlassSystem} is a four-level nesting of \verb|foreach| statements at lines 63-79. These perform a parameter sweep over all combinations of radius, centroid, model, and job number within the simulation space. A single run of the script immediately expands to an independent parallel invocation of the simulation application for each point in the space - 1,670 jobs for the minimum case of a 7 x 27 x 10 x 1 space. Note that the if statement at line 69 causes the simulation execution to be skipped if it has already been performed, as determine by a ``\verb|NULL|'' file name returned by the mapper for the output of a given job in the simulation space.
+The entire body of the {\tt CreateGlassSystem} is a four-level nesting of \verb|foreach| statements at lines 65-77. These loops perform a parallel parameter sweep over all combinations of radius, centroid, model, and job number within the simulation space. A single run of the script immediately expands to an independent parallel invocation of the simulation application for each point in the space - 1,670 jobs for the minimum case of a 7 x 27 x 10 x 1 space. Note that the if statement at line 69 causes the simulation execution to be skipped if it has already been performed, as determine by a ``\verb|NULL|'' file name returned by the mapper for the output of a given job in the simulation space.
The advantages of managing a simulation campaign in this manner are well borne out by Hocky's experience: the expression of the campaign is a well-structured high-level script, devoid of details about file naming, synchronization of parallel tasks, location and state of remote computing resources, or explicit explicit data transfer. Hock was able to leverage local cluster resources on many occasions, but at any time could count on his script acquiring on the order of 1,000 compute cores from 6 to 18 sites of the Open Science Grid. When executing on the OSG, he leveraged Swift's capability to replicate jobs that are waiting in queues at more congested sites, and automatically send them to sites where jobs were moving through the system. All of these capabilities would be a huge distraction from his primary scientific simulation campaign were he to use lower-level abstractions where parallelism and remote distribution were the visible responsibility of the programmer.
Investigations of more advanced glass simulation techniques are underway, and the fact that the entire campaign can be driven by location-independent Swift scripts will enable Hocky to reliably re-execute the entire campaign with relative ease.
-He believes that Swift has made the project much easier to organize and execute. The project would be completely unwieldy without using Swift, and the distraction and scripting/programming effort level of leveraging multiple computing resources would be prohibitive.
-\\
-\\
+He reports that Swift has made the project much easier to organize and execute. The project would be completely unwieldy without using Swift, and the distraction and scripting/programming effort level of leveraging multiple computing resources would be prohibitive.
+
+\pagebreak
{\bf \small Swift example 2: Monte-Carlo simulation of glass cavity dynamics.}
%\begin{verbatim}
%\begin{Verbatim}[fontsize=\scriptsize,frame=single,framesep=2mm,gobble=7, numbers=left]
More information about the Swift-commit
mailing list