Documentation

NanoHive-1 logs events to a log file. Both the location (logging.outputDirectory) and granularity (logging.outputLevel) of these events can be specified.

The following table describes the various logging.outputLevel values. Each value is inclusive of lesser values. For example, if logging.outputLevel=400, events with levels 0 - 400 inclusive will be emitted.

The following is some sample logging output:

  2004-01-21 02:38:21,464 INFO [Logger] *********** Logging started. ********** 
  2004-01-21 02:38:21,464 INFO [NanoHive] Loading entity manager plugin: RAMEntityManager 
  2004-01-21 02:38:21,554 INFO [PluginGroup] Loaded RAMEntityManager 
  2004-01-21 02:38:21,554 INFO [PluginGroup] Instantiated RAMEntityManager 

Each entry comprises a timestamp (yyyy-mm-dd hh:mm:ss,mmm), output level, the component generating the log entry, and the log message.

Set the simspec.schema to the location of the simulation specification schema file (normally found in the data directory.)

  # Command Queue
  commandqueue.plugin.0=SocketsControl
  SocketsControl.ipAddress=127.0.0.1
  SocketsControl.port=3000
  SocketsControl.clientTimeout=30000
  commandqueue.plugin.1=ConsoleCommand
  ConsoleCommand.resultCodesFile=data/local/en_resultCodes.txt

Multiple Simulation Control plugins can interact with NanoHive-1's command queue. Each different Simulation Control plugin, and the order in which it's loaded, is specified by the integer N in the commandqueue.plugin.N= lines, starting with zero, and not skipping any numbers. In the configuration file example above, the first Simulation Control plugin to load is SocketsControl (0), followed by ConsoleCommand (1).

Additionally, parameters specific to each Simulation Control plugin should be placed with its declaration. In the example above, SocketsControl's IP address parameter is specified, as well as ConsoleCommand's result codes file. See the documentation for each Simulation Control plugin used for an explanation of any additional parameters it requires.

  # Entity Manager
  entityManager.plugin=RAMEntityManager
  entityManager.importExport.0.plugin=nanoML_ImportExport
  entityManager.importExport.0.importFormats=nanoML
  entityManager.importExport.0.exportFormats=nanoML
  entityManager.importExport.1.plugin=OpenBabelImportExport
  entityManager.importExport.1.importFormats=OpenBabel
  entityManager.importExport.1.exportFormats=MOL,PDB,XYZ,CML

Following the entityManager.plugin configuration line are the Data Import/Export plugin specification lines. Each Data Import/Export plugin is indexed by an integer starting from zero and not skipping any numbers. Each plugin is described with the name of the plugin, a comma-separated list of importFormats, ie, a single word describing the data format, and a comma-separated list of exportFormats.

In the above example, the nanoML_ImportExport plugin handles a single data/file format, the nanoML format. The import/exportFormats are used in the Simulation Specification (sim-spec, described later) to determine which plugin to use when importing/exporting data - the descriptor for each file in the sim-spec specifies its format. The OpenBabelImportExport plugin can import and export many data formats. Instead of listing every import data format, we just specify OpenBabel; then, in the sim-spec, we specify OpenBabel as the format to invoke the OpenBabelImportExport plugin.

  # Physical Interaction Calculators (PICs)
  pic.0.name=popper-1
  pic.0.type=local
  pic.0.pipPlugin.0=MPQC_SClib
  pic.0.pipPlugin.1=AIREBO
  pic.0.pipPlugin.2=AIREBO
  pic.0.pipPlugin.3=BondCalculator

Each Physical Interaction Calculator (PIC) is indexed with an integer starting at zero (and not skipping any numbers). It's name must be unique in the NanoHive-1 computing network. The type is either local or distributed.

The distributed type and all its particulars are described in the section later in this chapter explaining distributed computing with NanoHive-1.

Each PIC can support multiple Physical Interaction plugins. Each plugin is indexed with an integer starting at zero (and not skipping any numbers). List each plugin as many times as the number of threads desired. In the above example, two AIREBO plugin threads will be launched and made available for processing.