Documentation

Version 1.2.0 Beta 1

4. Creating Simulations

4.1. Simulation Workflow Scripting

Simulation workflow scripts tell the simulator how to process the simulation. The scripting language is TCL (here's a quick tutorial.) Here is an example workflow script that imports all the input entities from a list, performs the simulation - outputing intermediate results - then outputs the final results and writes the final state of the simulation space to a file.

  foreach inputEntity $inputEntityList {
    NH_Import $inputEntity
  }

  set maxIterations [expr $startIteration + $iterations]
  for {set iteration $startIteration} {$iteration < $maxIterations} {incr iteration} {
    NH_Intermediate $iteration $simResult
	
    NH_Prepare $iteration $traverser
    NH_Calculate $iteration $physicalInteraction $traverser
  }

  NH_Final $simResult
  NH_Export $outputEntity

The functions NH_Import, NH_Intermediate, NH_Prepare, NH_Calculate, NH_Final, and NH_Export control the simulator. They are described below.

The symbols inputEntityList, startIteration, iterations, maxIterations, simResult, traverser, physicalInteraction, and outputEntity are all defined in a Simulation Specification (sim-spec) file, discussed in the next section.

The workflow functions that control the simulator are summarized in the following table.

Table 4.2. Simulation Workflow Functions Summary


NH_Import <input>
This function imports <input> into the simulation space. <input> is a data source that must be defined in the sim-spec.

NH_Export <output> [<filename>]
If no <filename> is specified, the entire simulation space will be written to <output>, where <output> is a directory/filename defined in the sim-spec. If a <filename>is specified, the entire simulation space will be written to <output>/<filename>, where <output> is a directory defined in the sim-spec, and <filename> is a string defined by the script.

This second form makes it possible to write the simulation space out to a unique file at every iteration, or modulus thereof. For example:

  set maxIterations [expr $startIteration + $iterations]
  for {set iteration $startIteration} {$iteration < $maxIterations} {incr iteration} {
    NH_Prepare $iteration $traverser
    NH_Calculate $iteration $physicalInteraction $traverser
    set filename [format "out.%04d.xyz" $iteration]
    NH_Export $outputEntity $filename
  }

This would output files with filenames of the form out.0000.xyz, out.0001.xyz, out.0002.xyz, etc, one per iteration.

NH_Intermediate <iteraton> <result>
<result> is a Simulation Results plugin that must be defined in the sim-spec. The <result> plugin's intermediate routine will be called to output the simulation space's current state results. <iteration> is the current iteration (integer.)

NH_Final <result>
<result> is a Simulation Results plugin that must be defined in the sim-spec. The <result> plugin's final routine will be called to output its final results.

NH_Calculate <iteration> <traverser>
This form is deprecated, use NH_Prepare instead.

NH_Prepare <iteration> <traverser>
<traverser> is an Entity Traversal plugin that must be defined in the sim-spec. The <traverser> plugin's prepare routine will be called to perform any pre-calculation required before traversing the simulation space. <iteration> is the current iteration (integer.)

NH_Calculate <iteration> <calculator> <traverser>
<calculator> is a Physical Interaciton plugin that must be defined in the sim-spec. The simulation space will be calculated with the specified <calculator> and <traverser>. <iteration> is the current iteration (integer.)

Note

Be sure to prepare the <traverser> with NH_Prepare before using it in this function, or it's behavior may be unexpected.

NH_ApplyPath <iteration> <path> <atomSet>
<path> and <atomSet> are objects that must be defined in the sim-spec. This function applies the <path> to the specified <atomSet>. <iteration> is the current iteration (integer.)

All the parameters to the functions, except for the <iteration>, are passed into the script variable space from the Simulation Specification (sim-spec.)

4.2. The Simulation Specification

The Simulation Specification (sim-spec) determines all the particulars of a simulation such as the input files, traverser plugins, calculator plugins, result plugins, and output files. The sim-spec is expressed in XML, and its entities can be passed into the simulation workflow functions described in the previous section.

This schema shows the list of entities in the sim-spec - all of the parameters for the simulation workflow functions listed above are described there. The top-level entity is the <simulation> entity.

The schema .xsd file is in the appendix (see Appendix for Simulation Specifications Schema) and also available here: simulation-1.0.1.xsd.

Here is an example sim-spec followed by an explanation:

  <simulation>
    <description>Carbon nanotube simulation.</description>

    <parameter name="timeQuantumLength" value="5e-16" />
    <parameter name="environmentTemperature" value="300" />
    <parameter name="startIteration" value="0" />
    <parameter name="iterations" value="1000" />

    <simulationFlow file="simflow.tcl">
      <list name="inputEntityList">
        <input type="nanoML" file="cnt55.nml" />
      </list>

      <output name="outputEntity" type="nanoML" file="cnt55-out.nml" />

      <traverser name="traverser" plugin="RC_Traverser" />
 
      <calculator name="physicalInteraction" plugin="AIREBO">
        <parameter name="deltaTbyTau" value="1.0" />
      </calculator>

      <result name="simResult1" plugin="MeasurementSetToFile">
        <parameter name="outputInterval" value="20" />
        <parameter name="outputFile" value="results.txt" />
        <parameter name="datumSeparator" value="\t" />
      </result>
    </simulationFlow>
  </simulation>

The <description> is simply a description of the simulation. The plugins have access to this description and, for example, the MeasurementSetToFile plugin can be configured to output it along with the results.

The <parameter> key/value pairs are simulation parameters; they are passed into the workflow script variable space. The following table describes the standard top-level simulation parameters, but you can add additional parameters as necessary for your workflow script.

Table 4.3. Simulation Parameters

ParameterDescriptionRequiredDefault
timeQuantumLengthThe amount of time since the system's state was last calculated. Physical Interaction plugins may use this to calculate new atom positions given the atom's velocity, for example. The value is in seconds.Y 
environmentTemperatureThe desired temperature of the system being simulated. Note that this may not reflect the actual temperature of the system, and can be treated differently depending on the Physical Interaction plugin used. The value is in degrees Kelvin.Y 
startIterationAn integer dictating the first iteration value. This is often not specified, but useful when resuming a simulation so that pathing is kept synchronized. (Pathing can be applied to sets of atoms and depends on the current time, ie, (current iteration) X timeQuantumLength. See section on Pathing for more explanation.)N0
iterationsThe number of simulation iterations to process.Y 
baseDirectoryThe directory prepended to relative path/file values. This can be over-ridden by starting the path/file value with a / (Unix) or drive:/ or / (Windows), in which case nothing is prepended to the path/file value.NThe directory where this sim-spec is.
performanceReportingIf set to "on", a per-iteration timing report file will be generated in the simulation's directory. This report is useful for tuning distributed computing networks.N"off"


The <simulationFlow> block enumerates additional symbols available to the simulation's workflow script; especially for passing to the workflow functions. See a description of the <simulationFlow> entity in the specification schema.

4.3. Pathing

Atoms and molecules in the simulation space can be powered or simply forced to follow predetermined paths by the simulator - useful for activating motors, modelling dynamic phenomena, or moving molecular tools in to, and out of, molecular work areas, for example. We'll work through the concepts with simple pathing, then explain the linear force activator and rotary force activator.

In the system to the right, the red boxes encapsulate stationary atoms, while the green box encapsulates atoms that will be moved along a path as indicated by the green line.

To effect this functionality we need to specify the atom sets and their pathing instructions in the simulation specification.

Note

All the examples used in this explanation come from the complete hydrogen-abstraction example simulation included with each distribution.
    

4.3.1. Atom Sets

Atom sets are specified in the simulationFlow section of the simulation specification as follows:

  <atomSet name="atom-set-name">
    atom-set-description
  </atomSet>

where atom-set-description is a set of atoms. Currently there are three ways to specify atom sets.

nanoML spatialComponents with this form:

  <atomSet name="tool">
    <nmlSpatialComponent name="h-abstractor" />
  </atomSet>

The nmlSpatialComponent refers to nanoTITAN's nanoML spatialComponent entities, which are containers that can contain atoms.

MMP shafts with this form:

  <atomSet name="tool">
    <mmpShaft name="h-abstractor" />
  </atomSet>

The mmpShaft refers to the shafts in Nanorex's MMP file format. Specifically, the atoms specified for "jigs" can be used as atom sets with this form.

Boxed sets with this form:

  <atomSet name="tool">
    <boxedSet
      corner1XYZ="-2.0e-10 11.85e-10 -0.2e-10"
      corner2XYZ="2.0e-10 13.85e-10 0.3e-10"/>
  </atomSet>
corner1XYZ and corner2XYZ specify opposite corners of a box containing the desired atoms. The units of the coordinates are meters.

4.3.2. Pathing Instructions

Pathing instructions are specified in the simulationFlow section of the simulation specification as follows:
  <path name="path-name">
    <interval start="start-timestamp" end="end-timestamp">
      <velocity ... />
        or
      <linearforce ... />
        or
      <rotaryforce ... />
    </interval>
    <interval ...
  </path>
Each path has one or more intervals. Each interval specifies the time in seconds from which it is active (start) to when it is not active (end). The interval is active: [start, end).

The simulation workflow scripting command to apply a path to an atom set is:

  NH_ApplyPath <iteration> <path> <atomSet>

where iteration is the current iteration (integer) from which the current timestamp can be obtained, path is the name of the path to use, and atomSet is the name of atom set to apply the path to. Here, for example, is a fragment from the script for our examples above:

  ...
  for {set iteration $startIteration} {$iteration < $maxIterations} {incr iteration} {
    NH_ApplyPath $iteration $toolPath $tool
  ...

4.3.3. The Velocity/Anchoring Activator

The form for the velocity activator pathing instruction is:
  <path name="path-name">
    <interval start="start-timestamp" end="end-timestamp">
      <velocity fixed="true | false"
                componentsXYZ="x-axis y-axis z-axis" />
    </interval>
    <interval ...
  </path>
During the interval, the atoms to which the path is applied will undergo the specified velocity, expressed with either the fixed or componentsXYZ attributes. Use fixed="true" to freeze or anchor atoms. The componentsXYZ attribute specifies the x,y,z velocity components in meters per second (m/s). The default value for fixed is "false" so you can omit it when using the componentsXYZ attribute.

Note

  • When anchoring atoms, use fixed="true" instead of componentsXYZ="0 0 0" as it affords some computational benefits in terms of speed and accuracy.
  • When an interval ends, any atoms controlled during that interval are set "free" until another interval comes into effect.
Here, for example, is the path controlling the hydrogen abstraction tool shown above:
  <path name="toolPath">
    <interval start="0" end="180e-15">
      <velocity fixed="true" />
    </interval>
    <interval start="180e-15" end="2345e-15">
      <velocity componentsXYZ="0 -0.2e3 0" />
    </interval>
    <interval start="2345e-15" end="2580e-15">
      <velocity fixed="true" />
    </interval>
    <interval start="2580e-15" end="3300e-15">
      <velocity componentsXYZ="0 0.2e3 0" />
    </interval>
  </path>

The first interval holds the tool stationary for 180 femtoseconds (fs) while the system stabilizes. The second interval moves the tool downwards toward the diamond seed at 0.2 picometers per femtosecond (pm/fs) for 2165 fs. The third interval holds the tool stationary for 235 fs while the tool abstracts a hydrogen from the diamond seed. The final interval pulls the tool, with its abstracted hydrogen, up and away from the diamond seed at 0.2 pm/fs.

4.3.4. Linear and Rotary Force Activators

The linear force activator applies a linear force against the atoms in the atom set. The rotary force activator applies a torque against the atoms in the atom set. Each activator has a speed parameter. The simulator will use the given force to try and maintain the given speed (in the direction of the force vector.) As the actual speed of the atoms approaches the target speed, less force is applied. Here is the formula used to determine the multiplier to apply to the force to maintain the desired speed:

Equation 4.1. Force Activator Near-Target-Speed Dampening Multiplier


The following is a graph of how the dampening multiplier works:

Figure 4.2. Force Activator Near-Target-Speed Dampening

Force Activator Near-Target-Speed Dampening

The form for force activator pathing instructions is:
  <path name="path-name">
    <interval start="start-timestamp" end="end-timestamp">
      <linearforce speed="linear-speed" componentsXYZ="x-axis y-axis z-axis" />
        or
      <rotaryforce speed="rotary-speed" torque="rotary-force"
                   centerXYZ="x-axis y-axis z-axis"
                   normalXYZ="x-axis y-axis z-axis" />
    </interval>
    <interval ...
  </path>
linearforce - The speed is the target speed to attain using the force described with componentsXYZ. The speed, combined with the directional vector of the componentsXYZ comprise the target velocity. speed has units of m/s, a typical value is 200 m/s. componentsXYZ has units of Newtons (N), a typical value is 5e-9 N.

rotaryforce - The speed is the target speed to attain using the torque in a clock-wise rotation around the vector indicated by centerXYZ and normalXYZ. speed has units of rotations/second (s-1), a typical value is 100 GHz = 100e9 s-1. torque has units of Newton meters (Nm), a typical value is 5e-9 Nm. centerXYZ and normalXYZ have units of meters (m).


Last Modified: 5/17/2006