Relevance of snapping to drillhole contacts for resource estimation

Jurgen Fitschen 9 years ago in Resource Estimation updated by Yan 9 years ago 17
Hi, I will be first to admit that I dont have much experience at all when it comes to resource estimation and the "issues" we have had from clients regarding this sometimes seem foreign to me. So any thoughts or opinions will be welcome.

So for a bit of background let me explain the situation:
We have a client who have been claiming that the best way to model is by creating individual triangles between drillhole intersections until the entire model is completed - as you can imagine this would be very time consuming. Since we started modelling for them in past few years and we have slowly changed the way they think about modelling and managed (for the most part) to break out of this mould of modelling triangle by triangle. We did this by first getting them accustomed to interpolated surfaces from which models would be created to now recently dropping the implicit modelling (IM) bomb on them. This caused some concern as the geometries between the modelled traditional sectional solids and the IM solids are completely different, after many meetings we managed to quell some of the concern but they are still very sceptical about the IM function - but we are getting them to come to the party.

Our biggest problem now and actually the reason for the post is the following. One stipulation this client has put down is that we must honour the drillhole contacts - so a vertex created at the drillhole intersection. As we all know IM can get close to the contact but will never be exactly on it. This is causing the headache for us in the sense that we need to modify the IM solids so that they snap to drillhole contacts - we accomplish this by importing the IM solid into GoCAD and using their snapping tools (hopefully Micromine will add this functionality sometime soon!), the solid then needs to be reimported and validated before sending off to the client. By the chance that we do miss an intersection we get loads of emails back saying that there is "leakage" and the solid does not encapsulate all the assayed intervals. As already stated earlier Micromines IM does not ever hit the contact and we do a best attempt to resolve this in GoCAD.

The question really is does one need to honour the drillhole contact for resource estimation? If so does this mean that IM solids can never be used for resource estimation and best practice for building models for resource estimation is the traditional triangle by triangle methods this client loves so much? OR can IM solids be used for resource estimation and the "leakage" is overcome in some different way?
Under review
Good Day Jurgen 

My answer would be no you don't need to snap to the drillholes. It needs to be close and in implicit modelling you can set it so that it is pretty close to snapping to the points.How close does it need to be snapped will depend on the dimensions and size of your orebody.
I completely agree, the size and type of ore is extremely relevant when considering how close one should be to a drillhole contact.

However, if we consider resource estimation derived from modelled wireframes, and a specific volume misses a drillhole contact by ~70cm, then arguably that 1m assayed interval and sample has to be discarded, thus decreasing the total estimate of ore in that region. 

How do geostatisticians get around this issue when doing resource estimation?  Or is this even an issue to begin with?
If a wireframe misses a contact by 70 cm, and you have assayed at 1 m intervals this interval would be excluded when doing the calculation. This to me would be an issue, how big an issue depend on how many intervals intersect the wireframe. I would say at the very least a wireframe should never be out by more than half the assay interval and preferably much closer. Most of the time when I do implicit modelling I would hope if wouldn't be out by more than 10cm. 
We also get within 10cm most of the time, but does this mean that the sample for that 1m interval is discarded?  
No if it was over half so 50 cm away it would be discarded.
Well then, this begs the question as to why anyone would need to snap to drillholes?  Thanks for the clarity.
I think people snap to drillhole to get the proper depth on a 3d point. Even if Vizex is a 3d space, you are working on a 2d monitor, so snapping to drillholes is the only way to get that 3rd component of a point.
Yes for sure, and it would also be nice to have this (snapping) functionality anyway, as Jurgen mentioned below.
Hi Jurgen,

What is the difference between the generated wireframe and the interval points, as the other are saying, depending on the size, even if it doesn't exactly honor the drillhole, it probably doesn't make a big difference.

This is not an answer to your question, but we could look into a way to try to 'force' the polygoniser to include contact points, if it really is an issue. Would be good to know if anyone else faces similar problem using IM.
Hi Yan,

That would be great considering this is a large multinational client of ours.

We are currently trying to get them to replace their SURPAC licenses with Micromine licenses but we find it difficult to get them to change over or to convince them to change over when we basically have to market two software packages (Micromine and GoCAD) for them them to get the end product they want.

The sparse surface modelling has been a great inclusion and we are using it daily to construct these models but we still have the issue when building their ore with Implicit Modelling (Lithology Modelling) as the volumes dont and cannot be snapped to the contacts within Micromine.

Even if it is not possible to include the contact points immediately into the final wireframe output from IM it would be great if Micromine could maybe look at incorporating the same (or similar) functionality as GoCAD has where one can create a point set of contact points, add a snapping tolerance (in m), optimise the shooting (snapping) direction from the wireframe to the points (automatically) and then snap.  This functionality would help us justify why this particular client should scrap their SURPAC licenses and reinvest in MM.  We have now set the bar for them in terms of what their models should look like as they have been updated with IM models (snapped in GoCAD).  As there are very few true IM software packages you can imagine which one we are recommending.
To add to the above discussion, I agree that it depends on the size and type of your ore body. If you have very narrow intercepts in your ore body it becomes much more important to be snapped to that point. What I have found is that in our ore body we go from extremely narrow intercepts to very broad intercepts very quickly (within 25 feet sometimes). The IM struggles with this "Lensing" that we see.

As for the Geostaticians question, The way you set up your interpolation and search ellipsoids usually takes care of most of those "leakage" areas. I.E. they frequently get coded as waste anyways due to the way the grades are calculated.

In cases where you have a large data sets like blast holes, level drift samples or incredibly tight drilling I wouldn't worry about snapping to every interval, but if you have long reaches between drill holes I would respect the data as best you can. Errors in thickness will be more significant the thinner the mineral solid is. To check if you are generating bias I would re-pierce (Wireframe>Calculations>Pierce Points) the solid with the drill holes and compare the thicknesses. If your average is the same you are probably in good shape but if you sway one way or the other I would rethink it.

Be careful with results that are drastically different than expected if you are generating a domain that will later control the tonnes and therefor the resource. The easiest way may not be the best.
I think the discussion on if snapping to drillhole is relevant or not is really interesting, but I added the option to snap to drillhole or input points for a lithology or polygon modelling. This should fix most of your problems and will be available in the next BETA build.
Hi Yan,

That is fantastic, I look forward to seeing how well it works!

Thanks to jdyer and Geoff for you input to the discussion,  hopefully the additional functionality Yan is talking about will be of benefit to you two too.

Another suggestion I have for how to better increase the result/speed of the Implicit Modelling would be to more easily define the Search Ellipsoid.  My suggestion for this would be that when runs "Stats->Variogram Map" there should be an option to generate a search ellipsoid at the centroid of the input data as an output.  This way one could go through all the directions needed to define a search ellipse and output one straight away for input into the IM.  Would this be possible to do?
Something similar is going to be available in the next BETA build. We will probably write a post a that time to explain how it works.
Thanks Yan,

Look forward to seeing all the additions the next BETA build has to offer!