OP Software  Documentation of Build Processes and Support Structures

 17 January 2007
Introduction
This document provides information on the source documents for OP programs and documentation; it notes the oddities and workarounds that are undocumented ‘features’ of the various products used to create and support the OP suite of programs.
Format of this document
This document is named  F:\op\PDI_OP_Overview.fm created by FRAME 5 and the output should be converted to PDF using Acrobat Distiller. The printer setup is for Acrobat Distiller and the pdf output to a file F:\op\PDI_OP_overview.pdf
Overview
OP (Open Pit) is a suite of programs that have evolved within PDI Vancouver’s Evalutions Group since the 1970’s, whose purpose is to build computer models of an orebody from drillhole data and to compute mineral resources, mineable reserves and staged development from those models. There are about twenty significant programs and numerous auxilliary programs comprising OP. These amount to more than 100,000 lines of Fortran and 60,000 line of C. 
Source structure
The source code for OP comprises a set of Fortran and C source files, from which are created the executable programs for all currently supported hardware platforms.
Supported platforms are UNIX (Solaris 2.1, IRIX 6.5) and Windows (NT and 2000).
Under a root source directory varlocal/op/src are a series of subdirectories, each named for the OP module that is built from the sources that subdirectory contains.
A single source set for all platforms is achieved through use of a pre-processor to conditionally include or exclude specific segments of code depending upon the target hardware platform.
Under UNIX, this preprocessor is invoked whenever a Fortran source file has the capital .F extension.
Under Windows all Fortran sources are pre-processed.
The following preprocessor symbols isolate code segments for specific platforms: WIN32(for WinNT), PDISVR4(for UNIX), SUNSVR4(for SOLARIS), SGISVR4(for IRIX), PDICREF(for C/Fortran oddities).
The following symbols permanently exclude code: NEVER, WIX32, NIW32, WX32, SKIP_ALL_THIS
The source files for OP are either C-language (.c extension) or Fortran (.f or .F extension). Fortran is legacy-based and nominally Fortran 77. C is more usually K&R rather than ANSI.
Include files are used frequently for both C (.h extension) and preprocessed Fortran (.inc or no extension) and are kept in one single location varlocal/include/pdi
Build processes
Under UNIX, the make utility is used to ensure that up-to-date executables will be obtained whenever changes to source files and subroutine libraries have occurred. make minimises compilation by limiting processing to those files which have been altered (have a later modification date). The various UNIX platforms require some variations in make arguments etc., and these are dealt with ‘automagically’ via a make-invoking script makeit that is directed in its operations by an application-specific Rules file in the application’s source sub-directory.
Under NT, each OP programs is built from an individual Microsoft Visual Studio Project. As with UNIX Rules files, each Project resides in the application’s source sub-directory and the project name is NT. Use of this single project name allowed easy duplication of project settings during the initial port to Windows; in hindsight it was not the most useful convention. Occasionally a subdirectory contains source for more that one OP program, in which case the Visual Studio Projects are placed in individual program sub-directories within the source sub-directory.
How to build NT OP .exe's
buildNT is a bash-script in F:\op\src\NT that finds all Developer Studio
.dsp files under the OP source tree f:/op/src

buildNT's find command executes the tcsh-script chopit which
translates the full-cygwin-path .dsp file into a DOS cd and
an execution of msdev /rebuild on the specific .dsp

the output of buildNT should be directed to a .bat file, then that
 .bat file executed with output to a log file:

buildNT > ddmmyy.bat
ddmmyy.bat > ddmmyy.log

Review ddmmyy.log for build error(s)

buildNT cannot locate libraries first, therefore it would be prudent
to execute ddmmyy.bat twice to ensure inclusion of all library updates
OP DATA FILES
OP programs produce Binary Data Files that are compressed by in-house I/O subroutines and are in BIG ENDIAN format. These I/O subroutines convert these datafiles to LITTLE ENDIAN when the programs are run on WINDOWS systems. 
The Files on Disk are always BIG ENDIAN
Each OP Data File starts with a first 4-byte sentinal describing the file format:
 Table 1: 	
4-BYTE SENTINAL	PURPOSE OF FILE TYPE	
GRID	Surface DTM	
PROF	Bench wise PROFIT model for Pit Optimisation	
FILT	Slope Filter file for Pit Optimisation	
BNCH	Bench wise Grade Model, known as Single Metal Models	
PREP	Prepass file - speeds up Pit Optimisation by rejecting regions that cannot be mined.	
PITS	Stage pit sequence file, multiple GRIDS representing Pit Shells.	
PITI	As PITS format above, but expanded to I*4 for bench number	
TONS	Intermediate resource/reserve file to report on in ASCII or transfer to Excel.	
COMP	Multiple SMM’s can be combined into a Resource Model.	
IKDS	OP29 pik cumulative probability grid, for OP30 postprocessing	
NTR1	Georges Verly’s GEOSTAT format.	
SCMP	Historic composite file - NOT USED	

Deployment
OP program executables are created into a directory structure that is not used by local users. This prevents inadvertent interruption of work-in-progress and allows for testing of changes before release to users.
Once tested, the OP programs are moved into a common Deployment directory structure that is branched to allow the various hardware architectures to ‘select’ their respective executables. An environment variable PDIVER is set to a hardware-specific value and this, when embedded in the PATH variable, becomes the ‘branch’ that selects the appropriate executable. Current valid values for PDIVER are IRIX6, SUNOS5 and NT. (Historically PDIVER has also had SUNOS4 and IRIX5 values for the now redundant operating systems). PDIVER is set during a user’s login.
A user will then obtain the correct architecture-specific OP program by referring to it’s root name only and allowing the PATH variable to find it in the appropriate directory.
Under UNIX, moving a program to the Deployment structure is preceded by moving the current version of that program to a specific temporary name. This allows possible in-progress network executions of that program to continue uninterrupted. A script installit performs these functions with warnings issued for re-installation.
 Periodically, after a suitable ‘grace period’, those temporary old executables can be removed 
The root location for this Deployment directory structure is $PDIHOME/bin . This same structure should be used at PDI mines to facilitate updating with new versions of executables and to allow those sites with multiple hardware platforms to use a single file server. PDIHOME is therefore a site-specific environment variable allowing appropriate file server disk location. Various other subdirectories under PDIHOME house scripts, documentation, graphics library runtimes etc..
Source code to OP (other than OP99 applications) is not distributed outside Vancouver and access to it is restricted to specific groups in Vancouver.
Zip file creation
Georges Verly has a bash script that standardises the zip files that are deployed to sites:
CAHARFP01\Apps\opt\zip_pdi_etc.bash
(CAHARFP01\Apps\opt\grlb_pdi_etc.bash is a slight variation)
You edit the script to specify which zip files to create:
 zip_pdi=yes
zip_geostat=no
zip_gcsim=no
zip_gnu=no
Then you run the BASH script by sourcing it:
. zip_pdi_etc.bash
These zip files are then copied to CD.
OPGUI
OP is a suite of applications, which operate in ‘batch’ mode i.e. executing an application requires a ‘run-stream’ – an ASCII file containing all the input parameters needed to complete the execution.
‘run-streams’ are generally created in a text editor using plagiarized ‘run-streams’ from other OP projects or programs.
This execution style is a direct inheritance from the UNIVAC mainframe batch environment and remains worthwhile because it provides a useful ‘audit trail’ of how resources and reserves were obtained and an ability to repeat a project evaluation. However runstreams are a significant inhibitor to the novice user.
Another significant inhibitor to the novice was the inheritance of the mainframe style of connecting actual files to program ‘logical units’ via ‘job control language’ statements.
To enhance acceptance of OP at minesites, where engineers and geologists were becoming increasingly accustomed to GUI-style interfaces of commercial mining software, it was decided in 1996 to add a GUI front-end to OP. This would provide an interactive interface to users and would build a ‘run-stream’ for the application and execute it, giving the best of both worlds.
The OP application itself would remain relatively unaltered allowing backward compatibility for project resurrection.
The development of this GUI interface OPGUI was facilitated with TeleUSE a GUI development tool. It involved the design of multiple successive input dialogues to cover the ‘namelist’ parameter input, inherited from UNIVAC.
TeleUSE was efficient when used by the experienced contractor who built the initial OPGUI, but has proved onerous on an ad hoc basis to accommodate program enhancements and further, its Motif-based widgets do not present well under Windows.
OP99
There are many additional programs auxiliary to the OP suite, which have been developed by various contributing engineers and geologists. The source code to these auxiliary programs is distributed to minesites from the Deployment directory structure. This gives engineers and geologists the capability to leverage further enhancements to the system without requiring a start-from-scratch, provided of course, suitable compilers are available on site.
In order to facilitate the code-build-change cycle of these op99 programs, another script
 make99 performs the same platform-specific customisation as makeit without the requirement for a Rules file. A similar build process under NT is not yet available, though single source file compilation and linking can be done from a command line under NT. Currently for NT an op99 sub-directory under the source tree hosts individual op99 application Developer Studio sub-directories
GEOSTAT
Georges Verly has his own suit of Geostatistical tools collectively called Geostat. Since coming to Placer Dome, he has utilised the ntran-compressed file I/O that OP uses. GEOSTAT has two filetypes, both of which have content information in their headers:
VIOF are ASCII files with field descriptors in the first 3 lines
NTR1 are Binary ntran files, again described in sufficient detail in a header
GEOSTAT utilises a more historic implementation of dynamic memory which necessitates different Fortran compilation and redefinition of external function symbol names to link to OP libraries. 
EXPL
UNIX
When Bill Green left PDI in 1999, EXPL programs became fairly unsupported. There are few remaining customers for the EXPL programs (Neil Fordoes and Dick Lewis) and only one or two fixes have been applied since Bill’s departure.
The EXPL source tree is similar to the OP source tree with expel as apex rather than op and makeit can be used to build applications.
Windows
EXPL has not been converted to Winches Source Control but there are CVF projects for the main programs 
VULCAN
Vulcan is a commercial mining software package developed by Maputo that allows sophisticated graphic interaction for Mine Design, Geology Modelling etc.
Vulcan has been available on both the UNIX (IRIX6) and Windows (NT and 2000) platforms, though the IRIX6 version is dead-ended.
Connectivity to OP
Source for the OP-Vulcan translation software is kept in the OP source tree under a subdirectory Vulcan.
There are three significant proprietary Vulcan filetypes that require conversion to and from OP. The following applications have been developed to facilitate file transfer:
op_vulcan reports OP compressed models in an ASCII form suitable for Vulcan’s brimport program to read and create .bmf files
. It also creates the required Vulcan .bdf file. Usage:
op_vulcan OP.cmp xxx cutoff - | (sleep 2; brimport xxx.bdf ...)
grd_vulcan converts Vulcan .sfg surface grid files to and from OP .grd grid files
 and optionally fit a VULCAN file to OP’s proj.par limits.
Usage:
grd_vulcan OP.grd VULCAN.sfg or
grd_vulcan VULCAN.sfg OP.grd [fit]
krjatri displays Vulcan .00t triangulation files – there is no equivalent OP filetype but some applications, OP29 for example, can read a triangulation for its own purposes.
 Usage:
krja_tri Vulcan.00t
Connectivity to Datamine
Transfer between Vulcan and Datamine is enabled through their respective translations to and from OP. Two exceptions are
 00t_dm		transfers a Vulcan triangulation (.00t) to the Datamine Point/Triangle file-pair.
arch_dm		converts a Vulcan .arch_d archive to a Datamine strings file.
Remote display on Sun from IRIX 
UNIX Vulcan is an X application that can operate remotely i.e. the execution can be on a remote computer (host_e) with the display coming to a local computer (host_d).
 
Two steps are required to initiate remote display:
Before execution, indicate where the remote display is to happen:
		setenv DISPLAY host_d:0 
Before execution, indicate to the local computer that the remote computer has permission to display
		xhost +host_e
A feature of Sun workstations when receiving this remote (IRIX6) execution is that the user must move the startup window, by grabbing the top window-banner, or else Vulcan will not continue with its startup.
DATAMINE
Datamine is the other significant Mining Software Package in use throughout PDI. Its use usually predates the PDI decision to adopt Vulcan as a ‘standard’.
Connectivity to OP
A variety of conversion programs have been developed to convert Datamine files to OP.
Datamine files are all similarly structured in that the file contents can be determined and then accessed via the field definitions in the file’s header block.
ascii_dm
		builds a Datamine strings file from ASCII input
dm_geo		converts a Datamine block model to an OP GEOL geology model
dm_ntr1		converts a Datamine file to a GEOSTAT NTR1 file of same fields
dm_smm
		converts a Datamine grade block model to an OP SMM
dxf_dm
		converts AutoCAD dxf points, test and (poly)lines to Datamine Plot
grid_trpt_dm
		converts OP GRID file to Datamine point/triangle pair
ntr1_dm
		converts GEOSTAT NTR1 file to Datamine file of same fields
smm_dm		converts an OP SMM to a Datamine grade block model
MineSight
Mintec’s Minesight has recently been acquired at Porgera and work is underway to accommodate it’s interaction with OP and Datamine
Connectivity to OP
In 2003, Mintec are releasing Python-based modules to allow I/O to many of their proprietary binary file formats.
Connectivity to Datamine
msr_dm module
Porgera have Datamine in their Geology department and Meds Minesight for Engineering and have requested some trasfer software.
In December 2006, a module was developed for Minesights Grail running under Python2.2. Currently it trasfers shells within an .msr file to pt|tr datamine wierframe files.
Some pointers in developing modules for Grail and Python 2.2
 There is no debug version of Python 2.2. To use Visual Studio you must dasable debug by inserting #undef _DEBUG before
#include "Python.h"
 Visual Studio dll’s that contain Fortran subroutines must be:
 Fortran Dynamic Link Libraries
 Have module_name.def containing:
EXPORTS
		initmsr_dm
   #undef _DEBUG before
#include "Python.h”
 initmsr_dm(void)
{
  Py_InitModule("msr_dm", op_methods);
}
 e.g. static PyMethodDef op_methods[] = {
   {"head", ex_head, METH_VARARGS, "OP GRID header"},
    {"grid", ex_grid, METH_VARARGS, ".msr shell set-up .dm"},
    {"poly", ex_poly, METH_VARARGS, ".msr points"},
    {"tri",  ex_tri,  METH_VARARGS, ".msr triangles"},
    {NULL, NULL}
};
Dubugging Python
 Python script must be working before using Visual Studio to debug the modules that the  script calls. Use Pythonwin check 
for Pythonwin and TabNanny check
 Use Visual Studio EDit>Advanced>UnTabbify to get the indents correct.
 Use dos2unix to get consistent line endings.
 Use Pythonwin rather than IDLE for debugging python scripts.
 Because of conflicting use of DDE with Visual Studio and other apps. e.g. dbExplorer, launch pthonwin through:
C:\Python22\Lib\site-packages\Pythonwin\
start_pythonwin.pyw /nodde

Hardware Platforms
Platforms dropped from support
As of June, 2005, SUN and SGI platforms were officially dropped from OP Software Support. (ref. Kevin Gould, ISG- Snr. System Architect). Zaldivar and South Deeps were notified
SUN
Remaining platforms
Sun workstations and servers are now a very small and dead-ended component of PDI’s technical computing environment (Vancouver 4; PDSA 1)
Specific disk storage
placer4 still has the original OP sources under /opt The new Windows-served OP structure is mounted on placer4 at /opt1
All other UNIX workstations are solely Windows-served under /opt
SGI
With corporate selection of Vulcan as the Mining Software standard SGI became the baseline technical computing platform. Maptek never did have decent support for Sun workstations.
Remaining platforms
There are still a number of SGI UNIX workstations within the technical computing environment – Zaldivar runs OP under unsupported IRIX5 ! Elsewhere IRIX6 workstations remain a background workhorse for technical computing.
Specific disk storage
Specific issues
SGI compilers are more aggressive in use of local stack variables and uninitialised variables (zero under Sun) caused numerous problems. As a result all SGI applications are compiled with the –static flag which assigns “hard” addresses for all variables
SGI C compiler generates errors on source files with DOS line-endings
SGI Debugger cvd will only run on IRIX-hosted displays. Occasionally cvd will generate copious messages referring to “tt”. To get beyond this issue the command:  mv ~/.tt ~/.tt_old
Geneology
Sun UNIX workstations were the first platform used by PDI in 1987 to replace the mainframe Univac 1110.
This geneology explains some of the OP software design features:
OP has a proprietary disk I/O functionality ntran which emulates UNIVAC ntran.
The development of a disk I/O subsystem allowed the development of our effective and efficient data compression algorithms which not only reduce disk data storage but also reduce network traffic. 
OP has a proprietary user input functionality namelist which emulates UNIVAC Fortran’s namelist
NOTE: changes to character parameters in a namelist should use the namelist sting input feature to properly reflect the character length in namelist output.e.g.:
npar = namlst('#param~', 'outtype=op04~', '#param~')

NT and Windows 2000
The OP port to NT was begun in 1998 with GKS porting in 1999. TeleUSE OPGUI porting was unsatisfactorily completed in 2000 and relies heavily on the lack of current interest in it!
Groups for users of OP
Access to programs:
Everybody who uses OP from the caharfp01\Apps network directory need to be in the Evaluations and Exploration group.
Access to data:
Use of the caharfp01\group project disc space should mount below the group in Evaluations or Exploration, otherwise GKS will crash because write-permission is not available to caharfp01\group.
Specific Disk Storage Issues
Windows2000 is now the primary disk server in Vancouver. Disk serving to UNIX platforms is achieved through Hummingbird Maestro. This setup causes protection problems for UNIX users because of the different file protection strategies of UNIX and Windows. UNIX users are often stripped file ownership and of group and world access which often requires superuser intervention. Additional issues with phantom SID’s have been discovered if the Windows Server is changed.
	Windows-serving to UNIX via Hummingbird Maestro sometimes causes permission problems, which necessitate becoming UNIX root and changing owner/group, then file permissions:
chown -R grlb *
chgrp -R engineer *
chmod -R 664 *
find . -type d -exec chmod 777 {} \;
Windows can also apply the read-only attribute to a file which then prevents the above UNIX permission changes. To remove read-only use the DOS attrib command:
		attrib -r filespec [/s - to recurse through sub-directories] 
Recently, there was a change of file server which led to the retention of an historic ‘phantom’ SID of the old file server (S-1-5-21-1004336348-362288127-725345543-500). This blocked any UNIX root access to file ownership changes and must be removed by Windows Explorer:
Windows can also convert text files from UNIX line endings to DOS line endings (<CR>). This causes serious problems with re-building OP applications:
DOS’d Rules files will cause the makeit scripts to malfunction and do incomplete erroneous builds
DOS’d C source files will fail to compile on SGI IRIX6 platforms.
To preserve file time-stamps, any ‘dos2unix’ script used should only alter the file if DOS <CR> is present. 
Issues with UNIX systems
Windows uses the opposite endian  convention for data storage from UNIX. All OP files are stored in UNIX (Big) endian form. The ntran read/write functions automatically convert endian form on a 4-byte basis.
- “Foreign files” which are not Big endian must use a negative ntran read/write code to avoid endian conversion or else re-map endian back to Little.
-Character strings (i.e. byte data) are endianless and become scrambled by the ntran automatic conversion.
-Double precision (8-byte) data requires attention because ntran does 4-byte. 
UNIX used the “system” function often to do system-type operations (file copy etc..). A special PDI-developed system function was developed which would allow access to Cygwin BASH, Hamilton C and other UNIX-like shells instead of just DOS. 
NOTE: The cryptic message:
/C: /C: is a directory 
indicates that the wrong (CVF-supplied) system subroutine has been linked
FORTRAN
Extensions to Fortran 77 in use
The significant extension is use of dynamically allocated arrays (pointers and malloc)
 to allow project block model sizes to grow to suit the demands of modern geostatistics.
The use of dynamic allocation can cause serious malfunctions that might not otherwise occur when programs are optimised under Windows CVF.
Trace dynamic allocation
To help tracing malfunctions, the ‘mempdi’ function has been expanded to produce a log file, when asked to.
The environment variable PDI_DEBUG can be set to the name of this logfile. Otherwise no log file is produced. The passed parameters, and those returned are dumped in the log. 
Windows
Developer Studio ‘features’
When debugging via input from a runstream ( < runstream) you must open that runstream (file > open) during the current session of the program in Visual Studio
If you generate Assembly listings, you will not be able to view variable values – assembly listings cause variable names to be changed!
When cygwin BASH is expected to be the underlying “O/S” (for calls to “system” for example, you MUST launce Developer Studio from a BASH shell with the command: dfdev
Likewise for GKS applications, in order to pick up teh GKS environment variables, you MUST launce Developer Studio from a BASH shell with the command: dfdev
Help is available for C and Fortran. You must select either C or Fortran as the default Help via Tools>Options>helpSystem>PreferredCollection
The following Table lists handy short-cut keys
Shift+F5	Cease execution	
Ctrl+F7	Compile	
F7	Build	
F5	Run/Continue	
F9	Set/Delete Breakpoint	
Ctrl+F9	Keep but clear breakpoints	
Alt+F9	Edit breakpoint	
F10	Step to next 	
F11	Step into subroutine	
Shift+F11	return	

Configurations
Visual Studio is set up with two configurations:
Win32 Debug for building debuggable executables that can be controlled and watched during execution
Win32 Release for building faster non-debug optimised executables.
Resources
Resource (.rc) files can be added to a project and are used at execution time (through the project parameters needpar subroutine) to display version information.
New additional Libraries to link OP applications:
mpr.lib to find a files mount point - a new ntran feature when opening a file
version.lib to find version info. for a executable - called in getarea.c->pdisys->needpar
Startup files in C:\Documents and Settings\All Users\Start Menu\Programs\Startup
There are two different tasks for the Startup files in C:\Documents and Settings\All Users\Start Menu\Programs\Startup:
	Sycronization with the Server so that CVS can work - nettime.bat:
date /T >> d:\grlb\nettime.log
time /T >> d:\grlb\nettime.log
NET TIME \\CAVANFP01 /YES /SET >> d:\grlb\nettime.log
time /T >> d:\grlb\nettime.log
Substitute Drive letters for directories with spaces or too lengthy -susbt.bat:
subst D: C:\D_drive
subst Q: "C:\Program Files\Microsoft Visual Studio"
REM subst L: O:\opt
REM subst F: L:\varlocal
REM subst I: L:\pdi
REM subst H: R:\Data\grlb\grlb_p4_2
REM subst S: R:\Data\grlb\p1_1
REM net use D: \\IS-BARBERG2\C\D_drive
REM net use Q: "\\IS-BARBERG2\C\Program Files\Microsoft Visual Studio"
net use L: \\CAVANFP01\APPS\opt
net use F: \\CAVANFP01\APPS\opt\varlocal
net use I: \\CAVANFP01\APPS\opt\pdi
net use H: \\CAVANFP01\EXPLORATION\Data\grlb\grlb_p4_2
net use S: \\CAVANFP01\EXPLORATION\Data\grlb\p1_1
Compaq Visual Fortran
 Support
Compaq Fortran has a long development history, being built upon the compiler knowledge of Digital. Compaq and now Intel provide excellent Email support through  This is a free service and initial response is usually next day, with continued support from the same analyst until the problem is resolved.
Although you cannot request him, Steve Lionel has been a particularily valuable contact in porting OP to NT
Environments
Environments are stored in:
 C:\Documents and Settings\BarberG\Application Data
in files named dvfenv.ini
Visual Fortran requires to different ‘environments’ or pre-defined compiler/linker option settings to handle OP programs and GEOSTAT programs:
The OP environment command line flags are:
/browser /check:bounds /compile_only /debug:full /define:"WIN32" /fpp /iface:nomixed_str_len_arg /include:"NT___Win/" /nologo /nopdbfile /traceback /warn:argument_checking /warn:nofileopt /check:nobounds /keep
The GEOSTAT environment command line flags are:
/asmattributes:source /asmfile /compile_only /debug:full /define:"WIN32" /fpp /iface:nomixed_str_len_arg /nologo /nopdbfile /traceback /warn:argument_checking /warn:nofileopt
Problems Debugging:
Recently {20/07/2006) op39 refused to srart in the debugger.
I don’t know why, other programs are OK, but I have a workaround:
Start OP39 in a Bash Window: /F/op/NT/39 < run-op39 & 
Launch Developer Studio from shortcut, or from the Bash Window: dfdev &
Attach Process

Stop the process
Set appropriate break points and continue..
OP70 has developed similar problems (another GKS application). 
This time continuing execution , sending the signal to the debugger
MALLOC PROBLEMS
Generally problems with dynamic memory show up in crashes that appear in unrelated places, like write statements etc.
The PDI-programs use a subroutine MEMPDI, and this has a trace feature which can help tracking down the out-of-range access. By setting the environment varianble 
PDI_DEBUG=filename, a log-file tracks each allocation of memory and write the address of the start of the memory block, and the sequence number of the allocation.
Sometimes the program will run without error under Developer Studio, and crash as it cleans up at the end and give a hex. address of the ‘heap’ that is was de-allocating,e.g.:
HEAP[29.exe]: Invalid Address specified to RtlFreeHeap( 930000, 9426d8 )
HEAP[29.exe]: Heap block at 00942540 modified at 00942568 past requested size of 20
This is not the same address that is contained in the log file but it is within the range of the allocation so you can get the sequence number of the ‘offending’ memory block.
You can do a stop within MEMPDI for that sequence number and from that see what array is being allocated and check all storage to that array
Setting Breakpoint Conditions
Note the mixing of C-style ‘==’ with FORTRAN ‘.AND.’
Tools Options Directories
Registry Entry [ command regedit ] 
Include Search Directories
Library Search Directories:
Source Control
PushOK Proxy provides the connection of Developer Studio SCC and WinCVS so that CVS source control can be easily administered from within Developer Studio.
Occasionally it is necessary to do a cvs update from WinCVS of a source directory to ensure correct 
checkout annotation of files within Developer Studio. 
PLATFORMS
UNIX
Sun Fortran
Sun Fortran and Sun’s model for program execution allowed for, in hindsight, sloppy programming. Sun initialised memory to zero, which was often the desired value for local variables. This masked problems of uninitialised variables and program testing was therefore seen to be problem free all the while hiding serious flaws discovered only when ported to other platforms.
IRIX Fortran

IRIX Fortran compilation is much more aggressive in its use of unititialised stack local variables. This led to significant problems as a result of the benign development environment offered under Sun. In order to minimise the effect and accelerate the port to SGI, all Fortran compiles within the makeit build process for IRIX use the -static argument which eliminates unititialised stack variables. 
C
Interface issues with Fortran
UNIX
There have been no interface issues regarding C and Fortran in the UNIX implementation, or rather the UNIX implementation adheres to the C-Fortran interface convention
Windows
A number of issues must be dealt with regarding the C-Fortran interface between Microsoft Visual C and Compaq Visual Fortran:
Calling convention
When arguments are passed to a subroutine, they are placed on a stack. CVF’s default convention is that, before returning to the caller, the callee clears the stack. It is therefore essential that the caller have the same number and type of arguments as the callee. Messages regarding inconsistent argument length should not be left unresolved..
String argument length placement
Each character string argument in CVF has the length of the string passed as an additional argument. These can be placed in the argument list immediately after their respective string arguments or successively after all the arguments. The CVF compile flag /iface:nomixed_str_len_arg sets all lengths after all arguments.
Entry-point name
To alleviate issues surrounding mismatched stack pushing and poping (see 1. above)
, Visual Fortran crafts the entrypoint symbol name for a subroutine from the byte length of the argument list, i.e. the number of bytes it will pop off the stack before returning. Similarily a call to a routine crafts a symbol name reflecting the arguments being passed (i.e. pushed onto the stack).
Multiple Entry Functions - OP46 orevnu.f and others
Multiple Entry functions may require the keyword RECURSIVE in front of the first FUNCTION definition. It appears to be benign if there unnecissarily. If the user uses the function entry name as a variable in the body of other entries other than its own, the results are spurious if the RECURSIVE keyword is absent.
 C and GEOSTAT subroutines 
C-subroutines have different symbol naming conventions and stack handling. CVF has a special comment structure CDEC$ allowing redeclaration of symbols and calling conventions. All of the OP C-subroutines that are called from Fortran are declared by CDEC$ ‘statements’ in a single include file that can be picked up, when required, by the preprocessor:
  #include “op_nt.inc”
NOTE: If more than one occurance of #include “op_nt.inc” is required in one source file [because the CDEC$ statements do not carry across “END” statements], subsequent #include statements must be preceeded by #undef PDIWIN32
There are also Fortran-Fortran interface issues between the subroutines developed for OP and the programs developed for GEOSTAT

. The same include file ( “op_nt.inc”) holds those OP subroutines used by GEOSTAT and are picked up when the preprocessor variable PDICREF is declared.
K&R Vs ANSI issues
GKS
Background
Graphical Kernel System is an ANSI Standard 2D Graphics API for which a number of commercial implementations were available. One graphics application had been developed on the UNIVAC mainframe using a 2D Tecktronix-based library suited to GKS.
When Sun was selected as the UNIX platform for PDI, SunGKS was an available implementation of the ANSI standard Graphical Kernal System. Though there were few graphics applications within OP on the UNIVAC, SunGKS became the graphics API for OP graphics programs.
The following are the graphics programs of OP:
OP75 Geology modelling was a Tecktronix application on UNIVAC and so became the prototype SunGKS application
OP35 OP File Display is a C application for displaying sections through the various OP files
OP39 Mine planning allows short and long term interactive mine planning and pit design
OP70 Naive Statistics allows the noormal suite of single and bivarite statistics and, more recently, allows sophisticated variogram modelling
showXX a series of similarly implemented programs graphically display bench-level OP file contents:
showit contours
show3d 3D isometric rule lines
dialit ‘hour-hand’ indicator of block values
shade 3D isometric rendered image
lips29 3D isometric rendered image of search ellipsoid
digit a digitizer interface program for construction and editing of polygons and polylines from maps
When Maptek’s Vulcan was adopted as a Mining Software Standard for new PDI operations, it became clear that Sun was not the preferred platform for Vulcan – Vulcan worked best on Silicon Graphics (SGI) workstations and as mines acquired SGI hardware it became necessary to port OP to SGI.
At the same time, Sun abandoned their SunGKS product, which forced selection of a replacement. We  selected S-GKS from Xelion, Holland and Scientific Software Ltd  (SSL) UK.  This selection fortuitously offered both Sun and SGI libraries.
SunGKS Wrapper
The ANSI GKS Standard applied only to the Fortran API. During the development of OP Graphics Applications on Sun, a number of applications (OP35, digit) were developed in C.
The S-GKS C binding was ANSI C with a quite different API to that of SunGKS. Fortunately SSL had invested in providing a ‘wrapper’ mapping SunGKS API to S-GKS API.
Build libraries
SSL GKS libraries are stored in:
 \\cavanfp01\APPS\OPT\SSL_GKS\NT\GET-X_3.2.10\LBRRY
SSL GKS include files are stored in:
\\cavanfp01\APPS\OPT\SSL_GKS\NT\GET-X_3.2.10\ETC
Deployment
Although not strictly necessary, GKS runtime environments for different platforms are distinguished by the previously mentioned PDIVER environment variable
Specific issues
UNIX
There remain a number of nuisance issues in our GKS applications which can only be resolved by Xelion, who no longer maintain the product:
text cannot be entered in a text dialog unless the mouse-cursor is moved into that dialog.
From Event Mode, do not set locator mode to request before setting it to sample – set it to sample directly from event.
Windows

If the Cursor dissappears look to the file $SYSTEMROOT/getx.ini. It should be setting inputcolor=0 (not 15). This file is created by F:/op/src/opgks/lib/gbcolr.f when not there already and uses the value of GKS_COLOUR to decide to set it to 15 for black background.
Developer Studio must Use Program Database because a Xelion library libdgks.a did
More Windows
A 3-button mouse requires the ‘middle’ button to be configured as “Middle Button” via ControlPanel>Mouse>Buttons
. A 2-button mouse achieves “Middle Button” by simultaneous use of “Left Button” and “Right Button”.
Text in C-based applications (OP35) cannot be entered in a text dialog unless you click the mouse in that text window
The program will crash if executed in a directory of a mounted file system where the user does not have write access to the mount-point directory
.
The crash that occurs with OP70 look like:
Cortez resolved this by giving Administrator privilege to users
-an effective but dangerous work-around :)
HPGL
Print Spooling from Windows
plotting to DesignJet
lpr –S cavanfp01 –P bn15nw-hpd02 –o l filename
lpq –S cavanfp01 –P bn15nw-hpd02 (note: lpq demands lowercase)
printing
lpr –S cavanfp01 –P bn15sw-hpl09 filename
AutoCAD
AutoLisp
A significant effort went into the development of AutoLisp routines to assist in Mine Planning at properties:
Larry Thon at Gibraltar developed a library of drafting utilities for mine planning
Peter Nahan in Vancouver and Sydney developed another suite more specifically suited to mine design which remain an active development effort and has been converted to Visual Basic.
Both of these suites of AutoLisp routines are kept within the PDI Deployment Structure under $PDIHOME/op/opacad 
OP uses AutoLISP to automate conversion of Mine Planning polygons designed by OP39 into dig plans and also to generate AutoCAD mesh surfaces from OP GRID .grd files
Windows
AutoCAD2000 is the current version of AutoCAD in use in Vancouver
. The License Server in Vancouver is cavanapp03.pdinc.pdgcorp.net (at IP 199.175.113.131)
UNIX 
Remaining R13 setup
AutoCAD R13 is the last version for UNIX workstations and a floating license is shared between Sun and SGI workstations by flexlm running on placer4
DXF 
Issues with feet-inch units
A file drawn in foot-inch units will “dxfout” as inches. To get a dxf file of feet, you must change the file to decimal feet and rescale.
Man pages
UNIX is well known for its concept of man pages - online documentation triggered by the command man. OP utilised the man page style, through the attendant nroff and troff document foratters, to develop the initial suite of OP Documentation. These man pages are accessed unider UNIX by the csh alias opman.
With the advent of the OP GUI and its graphical Dialog Boxes, the OP Documentation was revamped using Adobe Framemaker and a pdf document created (see below)
OP Man page documentation is still useable, though rarely up-to-date, under WinNT cygwin via a bash alias:
		alias opman='man -S1 -M /o/opt/pdi/op/opman'
FRAMEMAKER
This document is written in Adobe Framemaker 7.0 for Windows.
Frame 5.5.6 under UNIX allowed the generation of a single PDF document from a Frame Book composed of individual Frame documents of OP Applications. This PDF was custumised for online viewing as 8.5” x 6.5”
Under Windows, PDF generation was not able to create this format and various upgrades of the Frame and Acrobat products have yet to allow 8.5 x 6.5
UNIX Framemaker5 is available on placer4
To access this, first allow X display on your workstation:
xhost +placer4
rlogin placer4
setenv DISPLAY your_ws:0
There can be difficulties launching Framemaker5 on placer4 that relate to bad X defaults. A workaround is to remove Maker resources from the X resources database:
		/usr/openwin/bin/xrdb -remove Maker
Source for OP documentation is kept with OP source code in /var/local/op/src/Frame.
The online version is kept in the directory pdf and collected in main.book
Making a pdf from a Frame document requires Adobe Acrobat. 
Adobe Acrobat Distiller 5.0 when it makes bookmarks leaves the heirachy expanded. An free Acrobat Plug-In collapses all the bookmarks for you
 This plug in can hide bookmarks in the collapse process. If that happens you must manually collapse the bookmarks in question before you collapse by use of the plus-in
Cygwin

Scripts
Executable
To make scripts executable you must do two things:
Make the file executable - chmod u+x filename
have as the first line in the file:
#!/usr/bin/bash
Basename
When outputing log-file using the script filename : out_$0, you should always have
out-‘basename $0‘ to strip off the ./filename that $0 becomes
Download
Cygwin is a UNIX environment, developed by Red Hat, for Windows. It provides a number of UNIX shells: Bash (a superset of sh) and Tcsh ( a superset of csh). It also provides a near complete set of UNIX utilities under Windows, such as vi, diff, sed, grep, awk.  Downloads of current versions of Cygwin can be obtained from 
http://www.cygwin.com/
Man pages
Cygwin comes with a  helpfull set of man pages.
Man -t redirected (>) to a .ps file, can be viewed with Ghostview and printed from there.
Many other commands have a --help option.
Prompt
Because of some cygwin oddity, the standard Bash prompt (PS1) will always be administrator@hostid rather than the expected username@hostid
A better prompt can be obtained by defining PS1 in the .bashrc to be:
PS1="\[\033]0;\w\007 \033[32m\]\!@\W $ "
This will annotate the window with the current directory and prompt with
history-number@directory-tail
CYGBIN
This is an OP99 program, a shortcut to which is created in the SendTo folder of the user. When a folder is ‘Sent to’ cygbin, the program launches BASH.exe from the place stored in the registry and opens a BASH shell window opens up in that ‘Sent to’ folder.
To enable cygbin, extra lines must be added to the .bash_profile in the users HOME directory:(This is done for you in f02_cygwin.inc of the GEOSTAT setup):
# Pick up a directory spec. if one there then remove it
# This convolution handles spaces in names which cygpath did not handle
  if [ -e ~/dir.cyg ]; then
      cat ~/dir.cyg | tr -d ':"' | tr '\\' '\/' | sed s/\ $// > ~/cyg.dir
      cd "/`cat ~/cyg.dir`/"
      rm ~/dir.cyg ~/cyg.dir
  fi
QuickEdit Mode
Make sure that QuickEdit Mode is ticked for all BASH Windows. Either set through Window Properties or Regedit
Regedit:
Bash Window Properties
Source Control
OP sources are isolated from inadvertent corruption using a Source Control System.
Under UNIX, SCCS provided a mechanism for ensuring that only one person could alter individual source files at any time. 
SCCS is not available under NT so, after some searching and trials winCVS was selected (over Microsoft’s Visual Source Safe) and SCCS is no longer used, i.e. all OP Source Control is implemented from NT
SCCS - Source Code Control System
SCCS is now the historic ‘legacy’ system not to be used. All sources must now be controlled using WinCVS from a Windows platform. 
SCCS built individual Source Repositories under each OP application subdirectory in a further subdirectory named SCCS. Each source file of the application had two corresponding files in SCCS: a change history file s.filename and a lock file p.filename. The lock file noted the individual currently editing filename and prevented others from making changes until the first changes were registered (delta’d) into the change history file.
Change Summaries
SCCS allowed the building of useful cron’able procedures to build monthly change history. The shell script $PDIHOME/op/csh/op_changes built a monthly log of committed SCCS changes - see SCCS_sum directory.
Another script notified users via UNIX mail of any checked-out files they had.
CVS - Concurrent Versions System
CVS maintains a single Source Repository. Through use of CVS aliases, this repository has a sub-directory structure almost identical to the OP source tree. The CVS Source Repository for OP is located at varlocal/op/CVSROOT. 
A second repository for EXPL source is at varlocal/expl/CVSROOT.
The CVS structure is defined in the CVS modules file. A line for each module is specified:
key –a path
where key is the module name e.g. OP29
          -a  causes alias behavious
          path is the relative path from CVSROOT to where the ,v change history files are stored for that module. Alias behaviour uses that same relative structure when creating working copies.
WinCVS
CVS is used on Windows platforms through GPL-licensed WinCVS (V1.2). 
Because Cygwin comes with its own version of cvs, it is important to place the WinCVS binary directory in PATH ahead of cygwin executables. 
SCCS to CVS Conversion
CVS is a natural successor, via its intermediate parent RCS, to SCCS. Conversion utilities were readily available through the Open Source community. 
Conversion was performed on Sun Solaris (placer4) where a version of RCS was downloaded from FSF, built and a script sccs2rcs used to build RCS change history files. For each source file, sccs2rcs would check out each historic version from the SCCS subdirectory and add it as a delta into the RCS subdirectory. These were then copied into the CVS Repository structure.
Specific instructions for CVS Conversion:
On placer4 add /opt1/varlocal/bin to PATH
cd to a particular OP application subdirectory
Make sure that all SCCS s.filename has no DOS line-endings and that no s.filename is checked out for editing.
Ensure there is no RCS subdirectory present
Use the command /opt1/varlocal/op/src/sccs2rcs/sccs2rcs –b 
If there is a crash then move RCS/* to some safe location, rmdir RCS then rerun
Developer Studio
Two plug-ins have been used to interface WinCVS with Developer Studio as proxies for Source Safe:
 1.	Jalindi Igloo (GNU GPL)
was used up until June 2003 when problems began to arise in EXPL Developer Studio Projects
http://www.jalindi.com/igloo/
 2.	PuskOk CVS SCC Proxy (freeware until Aug 2003)
was then discovered, tried and found to relieve the EXPL problems and provide some added useful functionality
http://www.pushok.com/soft_cvs_proxy.php
Current Versions
Current version of PuskOK is 1.2.040216. Anything newer tham that gives problems.
Installation .exe is stored is D:\GNU\puskok.
PuskOK versions of CVS
Change Summaries
Scripts to generate change summaries, matching those of SCCS, have been developed for cvs on NT. In the SCCS_sum directory, the bash script NT_changes.bsh uses the cvs log command and a perl script convert.pl to create monthly summaries for a specified year (YYYY). These summaries are the files changes_YYYYMM.log is SCCS_sum
Additional Software
PushOK has become the SCC interface of choice for Developer Studio and
ExamDiff from PrestoSoft has become the file difference ‘engine’ of choice for PushOK.
Emacs
Emacs has a BETTER side-by-side difference feature that highlights the specific differences in records.
Type: emacs file1 file1
<return> for each buffer offered.
You must register the cursor in the Ediff window.
Then | for side-by-side; then maximum width; then next or previous to progress though the differences, 
? for help
CVS admin
There is two very useful cvs admin command:
 to change the description associated with a checked-in version (usually when you forget to describe that version):
cvs admin -mx.y:”description” filename where x.y is the version number of filename
Remove a revision ( sccs rmdel equivalent) by using the -o option to ’outdate’
a version.
NOTE: This may leave gaps in the version numbering unless you remove from the last version backwards.
cvs admin -o x.y filename
Consolidate the latest changes
or roll back the last committed change:
in Developer Studio				checkin filename.F
in BASH: 				cp filename.F filename+.F
in BASH:				chmod 644 filename+.F
in CVS  				cvs admin -0 m.n filename.F removing all that you want.
in Developer Studio 				checkout filename.F
In BASH				mv filename+.F filename.F
in Developer Studio 				checkin filename.F
CVS Lock Problems

If ‘cvs log’ (see above) is interrupted or if several developers try to run CVSNT at the same time, one may get the following message: 
[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo 
CVSNT will try again every 30 seconds, and either continue with the operation or print the message again, if it still needs to wait. If a lock seems to stick around for an undue amount of time, find the person holding the lock and ask them about the cvs command they are running. If they aren't running a cvs command, look in the repository directory mentioned in the message and remove files which they own whose names start with #cvs.rfl', #cvs.wfl', or `#cvs.lock'. 
If PuskOK plug-in hangs with no message, run CVS NT and look for lock messages like above.
CVS ‘Administrator’ problems
If Cygwin thinks that the user is ‘administrator’ and Developer Studio is launched from Cygwin Bash [dfdev &] thinks that the user is ‘administrator’ and logs CVS changes to that user.
The fix is to add your username to /etc/passwd under cygwin. Do the following from a cygwin bash window at the install directory for cygwin:
mkpasswd -l > /etc/passwd
mkpasswd -d | grep BarberG >> /etc/passwd
Look at the group for BarberG is GGGG then
mkgroup -l > /etc/group
mkgroup -d |grep GGGG  >> /etc/group
This will allow cygwin to get the right username BarberG instead of administrator and CVS to log changes to that username.
Other Open Source Applications
Open Source applications have allowed
 engineers and geologists to continue, under Windows, to take advantage of many of the tools to which they had become accustomed under UNIX
Groff
Groff is the GNU version of UNIX troff. 
One OP program interp29 creates a troff output documenting in English the parameters in an OP29 runstream usually in fort.18. To get Postscipt conversion of this troff output you have to do 2 things:
dos2unix fort.18
groff -ms -t -e fort.18 > fort.ps
Ghostview, Ghostscript
Under UNIX, engineers and geologists in PDI had come to rely heavily on Postscript as a means of presenting graphical data in a report-quality form either from software that created postscript graphical output or by directly writing Postscript files.
Ghostview and Ghostscript allow these practises to continue uninterrupted under Windows
RCS, WinCVS, Jalindi Igloo
, PushOK CVS SCC Proxy
While the more obvious Source Control System for Windows was Microsoft Visual Source Safe, there were a number of factors against it:
The history of changes to date would have been lost
Source Safe has proprietary data storage which can make original source inaccessible.
Source Safe is relatively expensive (US$550) given the requirements of OP source control; the usage issues surrounding it and the migration difficulties from SCCS. 
The following three Open Source products have allowed the full history of source code changes that have taken place to OP since 1990 to be converted over to the new WinCVS source control system under Windows:
RCS on Sun with the attendant script sccs2rcs allowed SCCS s. source history files to be used to build RCS ,v source history files.
CVS through its GUI interface WinCVS provides a full featured Source Control System under Windows
Jalindi Igloo provides a seamless integration of WinCVS into Developer Studio that matches Microsoft Visual Source Safe SCC.
PushOK CVS Proxy has replaced Jalindi as a better and more solid interface.
Winmerge
Winmerge has proved to be an invaluable replacement for the side-by-side file difference utilities of UNIX: filemerge under SUN and gdiff under SGI. Winmerge connects directly to the source difference functionality of winCVS
ExamDiff 
ExamDiff is a file comparison tool from Presto Soft which is a little better than Winmerge
TeleUSE
TeleUSE, from Aonix, is a Graphical User Interface development tool which allows graphical layout of an interface as a series of dialogues composed of customary widgets; builds these dialogs as an X application
 and provides C language stubs which can be expanded to manipulate these dialogues to suit the application.
TeleUSE was selected for development of the OP GUI based upon the experience of the contract programmer, Pierre Frioud, retained to do the initial development. In his hands it proved to be extremely valuable in building a consistent look-and-feel for the GUI and, indeed, for UNIX it was not that difficult for an untrained programmer to ‘dabble with’ in order to introduce new parameters required for an enhancement to the underlying OP application.
Building
UNIX
Windows
Deployment
UNIX
Deployment of TeleUSE applications, because all UNIX workstation displays were X servers, required only a couple of runtime libraries, having to do with its Motif-based graphics where Sun was OpenLook
Windows
Because Windows is not X based, TeleUSE deployment adds the requirement of providing an X server on each Windows platform. TeleUSE Windows development environment includes Hummingbird eXceed for this purpose, but this has a cost (US$275/seat) when distributing it to minesites.
A number of different X servers were investigated and one useful and adequate alternative was Xmanager from Netsarang (US$69/seat)