New sub-block model format

Leapfrog’s new sub-block model format, based on octree subdivision, will enhance your geometry representation in block modelling.

Leapfrog now has a brand-new sub-block model format based on octree subdivision that enables a much more efficient representation of geometry in block modelling. In this blog we explain the basis to this new format, and what it means for your block modelling.

Each recursion corresponds to a binary sub-division of the dimensions of a parent block (or previously created sub-block). In our implementation of octree up to 6 levels of binary recursion are allowed below the parent block level, with the smallest sub-block created thus being 1/64th (=1/2^6) of the parent cell dimension. We have modified our implementation so that different levels of recursion can be applied to each axis . If 6 levels of recursion are applied to all three axes the volume of the smallest sub-block created is thus 0.0003815% of the parent (=1/(1/64)^3), and theoretically up to 262,144 (=64^3) sub-blocks could be created per parent. In practice, nowhere near this number of sub-blocks are produced, because division of blocks or sub-blocks is only triggered if a boundary passes through them.

Illustration of sub-block geometries produced by Leapfrog’s old fully sub-blocked format (left) and the new octree format (right).

The exact reduction in the number of sub-blocks depends on the geometry and number of triggered blocks and will vary between projects.

As an example, the table below compares the number of sub-blocks required to represent a narrow vein system containing 4 veins using the existing Leapfrog sub-block format and the new octree format. Globally, the octree model requires only 15% of the blocks required by the old fully sub-blocked model. For the vein system alone reduction is smaller (55% of previous) because the veins are very thin and are mostly represented by the smallest sub-block. For bulkier domain geometries, the proportional reduction will be greater – typically requiring only 25 % of previous (or a 75% reduction).

This means smaller file sizes when Leapfrog block models are exported and faster processing times with less cells to process. But more significantly a look at project sizes highlights the main reason that we chose octree as the basis for our new model. It is well known that octree is not the most efficient sub-block format in terms of minimising number of cells, but the hierarchical structure of an octree is highly efficient and brings big advantages for the storage and retrieval of block information and faster visualisation.

For the vein model shown above, the old sub-block model requires 1.548Gb of on-disk storage, while the new octree only requires 18Mb. The size of this particular project reduces by a massive amount, from 1.74Gb to 210Mb.

Work to even further optimize the size and performance of octree models is ongoing.

It goes without saying, that all the standard validation and reporting tools you enjoy with the existing sub-block models are also available for the octree: calculations and filters, statistical reports, summary reports, grade tonnage curves and swath plots.

One question that frequently comes up with sub-block models is whether it is ‘geostatistically correct’ to estimate directly onto sub-blocks – something that is even more pertinent when sub-blocks are of variable size. This is too large a topic to explore here and will be discussed in a later blog article. But suffice to say, that our implementation of estimation onto sub-blocks addresses any concerns about ‘support’ by translocating a discretisation grid appropriate to the parent onto each sub-block, thus ensuring that that support correction implied by using ‘block kriging’ is appropriate to the dimensions of the parent block.

The upgrade path for conversion of your existing block models is straightforward – simply create a new model and choose the objects to trigger and evaluate. You can export calculations and filters and re-import these to the new model. You will need to re-create reports and swath plots. Because this process is so easy, we elected not to put effort into creating an automated upgrade. Re-creating the model gives you the opportunity to evaluate and compare the old and new models side-by-side – a valuable further validation. We are confident that you will immediately realise the advantages that our new model provides and make this migration.

If you require the variable Z option (and can’t use fine sub-division on one axis to achieve the geometric resolution this gives), you can simply continue using the existing sub-block model.

Sub-block model import
In another much-awaited development, you can now import an octree sub-block model in CSV format into Leapfrog, allowing you to visualise, validate and report from imported models. You can add new triggering and new evaluations and estimations to imported models, while preserving the integrity of imported categories and values.

It is important to note that imported models must adhere to the rule that the minimum sub-block dimension is a binary sub-division of the parent cell dimension (in x, y and z). Blocks with arbitrary sub-block dimensions can be handled provided they obey this rule. In practice many modellers define their arbitrary models within this geometric constraint anyway, as it facilitates transfer of block models between different applications.

See in figure 2, how the import interface follows the familiar pattern of choosing an input file and selecting the columns to import, before defining the grid structure to import to: parent and sub-block sizes, position, and extent.

For non-rotated models, it is a simple task to specify the minimum and maximum corner positions in orthogonal project coordinates.

If the model is rotated, we currently provide two pre-set options for importing specific CSV file exports from Leapfrog and Surpac. Both options are set up to accept the model minimums, maximums and rotations as contained in the header information that can (and should) be exported with the data files.

Models exported from other packages (where rotation conventions may differ) can still be imported with one of these options. If you know the model dimensions, use the Surpac option to specify the maximum corners as minimum corner plus model dimensions (i.e. in pre-rotation space). We recommend first importing the model as points, filtering the points to isolate parent blocks, then using these points to check that the containing model is correctly located with respect to data locations.

We are aware that the experience of importing rotated models is not yet optimised. Work to refine and improve the importer is ongoing.

Summary of advantages of the new sub-block model format

In summary below are the main advantages of using our new sub-block model format with octree branching:

1. Enhance your geometry representation in block modelling without generating unmanageable block model files.
2. Less blocks, less rows, therefore smaller block model files.
3. Smaller block model files, lighter Leapfrog projects for exporting or publishing to Central.
4. Less blocks, faster estimation.