Mapteks Vulcan Implicit Modeller, the new kid

on the block
Ron Reid
May 30, 2014
In case you have happened to miss the saturation marketing, Maptek has recently released its
assault on Leapfrog in the form of its Implicit Modelling Module released with Vulcan 9.
The Vulcan IM module is not a true RBF implicit modelling method, rather it utilises Ordinary
kriging to build a blockmodel and emulate implicit modelling, much like GeoVias dynamic
shells (which utilises Inverse Distance estimation) and CAE Studios Implicit Shells (Inverse
distance or Ordinary Kriging). In a strange twist Maptek have solved the memory management
issue that plagues RBF functions and actually have an RBF implicit modelling algorithm. They
have chosen to use this in their Eureka software, a tool designed for regional exploration and
data visualisation rather than their more widely known (and used) Vulcan mine planning
software. I believe this decision has roots in the 32 bit / 64 bit issue (Maptek can correct me if I
am wrong), Eureka is a born and bred 64 bit program whereas Vulcan is historically a 32 bit
program and 32 bit systems are unable to handle the memory requirements. Whilst I have not
used Eureka Beta myself I got to see a demonstration of the Beta at the Vulcan Users
Conference last year (thank you Maptek for the invitation) and it certainly looks more than
capable. It is able to create surfaces and generate non-intersecting surfaces for seam / vein
modelling etc) and solids of grade and object data. Searches can be controlled using multiple
ellipses, polylines (with normals to control inside/outside) and input points can be edited to add
new information to control the interpolated boundary. As well as drillhole data any data that
contains points (points, lines and triangulations) can be modelled. The output appears
reasonable as indicated in Figure 1. All in all from the demonstration it appears to be quite a
challenger even in its early form but only available to those select few that own and use
Eureka.

Figure 1. Implicit models of a drillhole dataset using Eureka.

Now to the program under discussion, as mentioned Vulcan 9 has introduced a new module
they call Implicit modelling and it comes at no cost for anyone owning the standard geology
tools modules. The menu shown below contains the various options available;

Yep, not many options but what does the Implicit Modelling Editor do?
The editor fires up a standard Vulcan form with a series of options on the left. The first option is
the Open Specifications page which allows you to select a parameter file when selected it will
populate all the fields with saved parameters, if you type in a new parameter name the options
you enter will be saved in this parameter file.

You have the option of selecting a categorical model (such as lithology) or a grade model
which is either categorical (as in indicators) or continuous. You can model from a drillhole
database, or from an Isis composite file. If you select from the DH database you are offered the
ability to use the data as is or generate a composite file given the estimate is an ordinary
kriged estimate, compositing the data to a regular sample support is recommended. If you do
select an already formed composite database you are not required to select a composite
length. The database is used to create a distance Map file a 3D point file that contains the
distances away from the 0 point for each category/grade cut-off which is then used to
estimate each variable into the blockmodel. Both the Distance_Map file and the blockmodel are
written to the project folder. You can either set up a new blockmodel by defining a name and
setting up blocksize, origin and extents or you can select a pre-existing model. Uniquely the
distances are negative inside and positive outside the reverse of that seen in Leapfrog or
Micromine.

Figure 2. Various options for setting up the estimate.

Like Micromine, Vulcans method is technically a local method as it uses a local search as part
of the OK estimator and as a result the search parameters need to be set up prior to running
the estimate. You can limit the output (as in the categorical shells not grade shells) to a
topographic surface and amend how you want to handle the data, select search parameters
and setup a variogram for each category. The variogram can be advanced as in a standard
variogram you have modelled, or you can use a slider that generates a simple variogram that
varies between a continuous shape to a smooth shape not a lot of information on what either
option means but it essentially creates a single structure spherical model and adjusts the

nugget value. Setting it at very continuous sets the nugget to 5%, very smooth sets the nugget
to 95%, ranges are based on the search ellipse you have entered. You can set up min and
max number of samples, and adjust the amount of smoothing both within the model, and
within the final output surfaces. You also can use a structural trend and/or a direction of
maximum continuity to force and mould the resulting shells.

Figure 3. The variogram set-up form, you can also select a triangulation to act as a
structural trend to drive the estimate.

The whole process relies on Vulcans block modelling tools to build and then estimate the result
into the blockmodel as a distance function, grade shells are then created to generate the
output. If you are modelling categorical shells then the shells are meshed together to ensure
there are no holes in the model, and they are trimmed to the topography if that has been
selected. As the basic block modelling tools are used Vulcan is required to generate a BEF file
to control the estimate, and when run you get a standard validation report. Both these files are
written to the TMP file on your C: drive and are overwritten every time you create a model.
Although the BEF file is a standard file that you can open, edit and adjust it seems you cannot
re-run the estimate using the standard estimation process, although you can create distance
grade shells on the fields in the blockmodel. As an OK estimate it suffers all the foibles of a
standard OK estimate, some understanding of the OK estimation process is really required to
get a useful output although it is very easy to generate a basic result.
So what about the results? I have taken the tutorial datasets I used for the Leapfrog-Micromine
comparison run them through Vulcan. As for the Micromine comparison; below I present the
same comparisons between Leapfrog (using Mining, but Geo outputs the same result) and
Vulcan.
Figure 4 shows the results of a basic Isotropic search of the copper variable from Leapfrogs
Marvin dataset. Its trying is probably as much as you could say for this isotropic result. It must
be remembered however that this a very basic no frills unconstrained OK estimate which for
anyone with a bit of experience in this field knows can be very full of pitfalls. With some trial
and error and some basic knowledge of the estimation processes and a study of the grade
distribution the output looks much better (Figure 5).

Figure 4. Isotropic search on copper from the Leapfrog Marvin dataset, Leapfrog on the
top, Vulcan on the bottom.

Figure 5. Adjusted estimate using a basic search direction and adjusting the nugget
variable in the variogram.

Figure 6 shows the results of using the Lithology modelling. Here like in the Micromine
comparison I have modelled the QzP rocktype from the Marvin Dataset. The final output shows
similarity between the two. In order to complete the Vulcan surface I have had to play with
block size and smoothing but the result is acceptable from a block model domaining point of
view. Figure 7 shows the total lithology modelling output when all 3 rocktypes have been
modelled. Again given the simplicity of this model the resulting wireframes are quite good and
are sufficient for domaining and modelling. More complex models are certainly possible but you
are constrained by the fact that you require the blockmodel to create the shells and thus are
required to use an appropriate block sizes. As you are compiling a rocktype estimate and thus
have a dataset that is largely continuous (very low nugget) you can get away with blocks that
are smaller than you could if doing a grade estimate blocks of 5-10 times smaller than
drillhole spacing (ie 10-20m blocks on 100m spaced drilling) are acceptable, any smaller
though and you get artefacts in the wireframes. If you were doing a grade estimate you would
be hard pressed to defend blocks any smaller than drillhole spacing (25m for the 100m
spacing) and some would argue you should not go any smaller than (50m).

Figure 6. QzP wireframe of the Leapfrog Marvin dataset, Leapfrog on the top, Vulcan on
the bottom.

Figure 7. Setting up all the rocktypes in the IM form will build a solid model of the
geology, the output for simple geological models such as in the Marvin is quite
acceptable.
Figure 8 shows the results of modelling the 5gpt gold grade shell from Micromines NVG
dataset using the same anisotropy. From this angle it looks to be OK.

Figure 8. 5gpt shell from the Micromine NVG dataset, Leapfrog on the top, Vulcan on the
bottom.
However, when looking normal to this you can see significant estimation errors (Figure 9). This
is a by-product of the OK estimation methods used by Vulcan. Playing around with all the
various estimation parameters, and the blocksize can reduce these errors but at the loss of
definition. A significant amount of the high grade does also get left out of the estimate again
due to this being a standard OK estimate it may mean that blocks in the High Grade areas are
more smoothed and thus lower grade.

Figure 9. Figure showing the Vulcan estimate normal to the plane of dip, search ellipse
artefacts arrowed in green.
Figure 10 shows the results of a largely unguided lithology interpolation of one of the NVG
veins, the results from both programs is unacceptable. Whilst I have used an anisotropy for the
search both programs have failed to adequately model the vein although the Vulcan option
looks more continuous it commonly includes/misses data it should not, at least the Leapfrog
program includes all the relevant data.

Figure 10. Unguided vein interpolant of a single vein from the Micromine NVG dataset,
Leapfrog on the top, Vulcan on the bottom.
Figure 11 however, shows the results using a vein modelling approach. The Leapfrog surface
uses an interval selection and the vein modelling methods to drive the interpolation as
discussed in the Micromine comparison. With Vulcan I have used every guiding option I can
think of when using the interpolator, including using a structural trend surface and polygons
basically an explicit interpretation driving the implicit model. And played with all the various
input options, block size, etc. The result is far from acceptable. Although it has to be said that
Vulcan does have its own workflows for creating vein models by extracting the footwall and
hangingwall points and creating grids which are then meshed together but these options do
not make any use of the Implicit Modelling package which is what I am reviewing here.

Figure 11. The same vein from the Micromine NVG dataset, Leapfrog using vein
modelling on the top, Vulcan using structural trend modelling and polygons on the
bottom.
In the final analysis, whilst the output for Vulcan is generally acceptable from a basic 3D
geological model generation point of view as demonstrated with the Marvin dataset it struggles
when handling the more complex geological architecture indicated in the NVG dataset.
Leapfrogs ability to handle complex datasets; its rapid shell generation, its true RBF method
and data analysis capability is a significant factor in its favour. Vulcan however requires quite a
bit more set up and planning getting to the same point, additionally some basic understanding
of kriging and its pitfalls is a requirement in getting a final end product.

Geological models in Leapfrog use domains (in the case of LF Mining) or Geology Models (in
the case of LF Geo) to create a solid 3D geology model with inbuilt overprinting and
stratigraphic relationships. In Vulcan you use the geology in the logging to manually define
each of the rocktypes and these are then modelled and meshed together en-mass. The
process does give an acceptable result from a block model point of view (again if the domains
are simple) but has significant problems modelling more complex data.
In its current form Vulcans Implicit Modeller is much more advanced and capable grid based
traditional system than GeoVias Dynamic Shells. It is a tool that would be of benefit to the
resource geologist looking to develop a series of resource domains on large bulk style deposits
(copper porphyries for instance) where geometries are simple and overprinting relationships
are not significant. The ability to generate simple grade shells, and basic domains allows you to
flag up a block model with the domains and then flag and extract the composites for statistical
analysis. As a component in the resource modelling workflow it might be useful. Also from a
basic broad scale assessment of a deposit it might also be helpful. It does however struggle
with more complex deposits where the RBF approach really comes into its own. Leapfrog and
Micromine do a much better job of handling these sorts of deposits gold for example, and are
much more versatile when it comes to 3D modelling of larger province or camp scale models. If
Maptek can implement the RBF method that has been added to the Eureka software into
Vulcan I think there will be a measurable improvement in the IM module.
All in all I think the IM module is a useful addition to the Vulcan Package, and as it comes
standard with the basic geology modules may get a lot more use (and thus feedback for future
development) than where you are required to pay for the privilege. However, outside the
resource geologist playing around with domains and obtaining a first pass looksee I think it has
little to offer but the ground work and potential is certainly there for Vulcan to become a
significant player in the field.
Is this implementation true Implicit Modelling, I think not as I feel you require some form of
RBF or similar process (- the rubber band effect) to truly be called Implicit although there
are others who argue that if it creates a model without using explicitly digitised strings then it is
by definition implicit. These arguments are probably circular and will have a ways to go before
they are truly settled and I think for now I will stick with my own probably biased opinion.