6 RUNNING STOPE SHAPE OPTIMISER EXTERNAL TO INTERFACES

The default way to run the Stope Shape Optimiser is to take advantage of a customised user interface developed by the mining software vendor. This interface will use familiar screens, default values, and access to supplier integration tools for data storage and field specification, and viewing of outputs. Vendors also have implemented case management.

In some cases, vendors have options to run external executables from within the mining software interface with scripts or batch files (consult vendor documentation for details). It is also possible to run the Stope Shape Optimiser engine as a standalone executable.

A vendor license for the Stope Shape Optimiser is required at all times, so the vendor requirements for concurrent execution need to be understood.

6.1 XML and Log files

An XML file is generated for each run with a standard name (produced from the vendor's GUI implementation). The file details the parameter settings. This file can be loaded and viewed in many freeware XML editors available off the web or even in Internet Explorer. The user has the option of importing settings into the vendor’s GUI from any XML file, or saving the parameters for a run in an external XML file. The XML file identifies the location of input and output files. The engine will trap bad XML syntax, but validation is best done in an XML editor

A log file is also generated which summarises the stope optimisation process. It includes a copy of the parameter settings used in the run, a line for the optimisation of each quad value, the processing time and a tabulation of results in a similar format to that created in the stope report file. The tabulated results in the log file include a line for each stope (RESULT=1) and a value for stopes with RESULT = 0 (the final stopes not generated or not meeting the defined parameter settings).The log file can report useful diagnostic information if stopes are not created, and will also give an error message if the run is aborted.

6.2 Batch Files

Batch files are easily created to run the Stope Shape Optimiser engine as a standalone tool from a CMD box or from a shortcut or tile on the windows desktop.

From the working directory access is required to:

· Stope optimisation engine (StopeOpt.exe),

· An XML parameter file, typically modified from one created by a vendor interface.

· DTD file (STOPEOPT_Activity.dtd) that defines valid XML syntax, and can be used in an XML editor . The DTD file should be referenced to in the XML file you are editing.

· Library DLL's

· System environment variables may need to be set

· Batch files to manage multiple cases

· Block model,

· Control surface files (if applicable),

· Control string file (if applicable),

The XML cases can define the exact path names for the input and output files. If not specified, then all input and output files are assumed to be in the working directory.

An example batch file is provided below.

Using a Vulcan cshell and a Vulcan stope optimiser parameters file (.sof):

#!/usr/bin/csh -f

$VULCAN/bin/exe/vulc_stopeopt.exe <parameters file> <scenario id>

Using a Vulcan cshell and a valid XML file:

#!/usr/bin/csh -f

$VULCAN/bin/exe/stopeopt/StopeOpt.exe -v <xml file>

To create an XML file from a Vulcan paramaters file use

$VULCAN/bin/exe/vulc_stopeopt.exe -x <parameters file> <scenario id>

Using a command prompt batch file:

@echo off

rem - ensure the runtime dlls are available

set PATH="C:\Program Files\Maptek\Vulcan 9.1\bin\exe\stopeopt";%PATH%

StopeOpt.exe -v test.xml

pause

6.3 Multiple Scenario Runs (Sequential or Parallel Processing)

It is best to run multiple scenarios using a batch file, with verbose output setting, to assist with any error messages and monitoring run progress and any errors or diagnostics. A typical batch file format would contain, “stopeopt.exe -v scenario1.xml” for scenario 1 run, and another line for scenario 2, etc., when running the scenarios sequentially.

Effective concurrent processing of scenarios is limited by the number of cores on your machine and one execution per core is recommended, and best to leave one idle for keyboard input.

Running cases using a command shell with system administrator privileges is not necessary.

Three options are available to manage and run multiple scenarios:

(1) The XML file is structured to allow multiple scenarios in a single file. Typically the vendor interfaces write a single scenario per XML file. These allow sequential processing of scenarios from the one XML, and it is possible to select scenarios for processing with the skip_evaluation="yes | no" option.

(2) Parallel processing with multiple batch files

Parallel processing is essentially achieved by duplicating all the files in independent working directories and having as many command shells running as available cores. While simultaneous access to a single model file (read only) is possible, the outputs need to be written to different files (no shared write access).

It is possible to parallel process scenarios from the one working directory using the one set of input files but the output file names (and batch files) must be unique for each case.

(3) Parallel processing with a single batch file

This approach is similar to (2) but the batch file uses the ampersand (&) character to spawn independent jobs. Ensure that two processes do not attempt to write concurrently to the same log and output files.

6.4 XML and XML Editor

From the vendor interface an XML file is generated for each run with a standard name. The file details the parameter settings. This file can be loaded and viewed in many freeware XML editors available off the web or even in Internet Explorer.

Currently the XML editors recommended by AMS (after a detailed review of freeware and commercial editors) are:

· Notepad++ (freeware).

· Oxygen XML editor (commercial software available from: http://www.oxygenxml.com/download_oxygenxml_author.html