Loading ...
Sorry, an error occurred while loading the content.

FW: [ai-geostats] Sum of Estimates

Expand Messages
  • Colin Badenhorst
    Hello List, Ok, I have discovered the true source of the discrepancy in the total sulphide count. I was able to do this after Bob Sandfurs reply prompted me
    Message 1 of 1 , Sep 1, 2005
    • 0 Attachment
      Hello List,
      Ok, I have discovered the true source of the discrepancy in the total sulphide count. I was able to do this after Bob Sandfurs reply prompted me to revisit the database and look at the stoichiometry, and David Reids email confirmed Bobs suggestions.
      Firstly, I should point out that I was incorrect about the Zn.Pb and Fe limiting values used in the estimation : these are in fact high yield limits that apply to samples that lie outside a nominated high yield search ellipsoid (different to the classic sample search ellipsoid). So, if values greater than this limit occur, and they lie inside that high yield ellipsoid, they will get used, and this is exactly what has happened.
      Now, when examining the database, I have found that there are Fe assays that are greater than 46.6%. ALL of these assays are located in the areas where the total sulphide summation discrepancies occur. The high Fe content here is due to the occurrence of several iron oxides (note oxides) such as haematite and limonite, where the Fe content is greater than 46.6%.
      Thus, the real problem here is the way that the total sulphides are calculated - nothing more. Remember that the the basic assumption is that all Fe comes from pyrite - it is now clear that this assumption is flawed, and I need to address it.
      Thanks for all the help,
      -----Original Message-----
      From: Colin Badenhorst [mailto:CBadenhorst@...]
      Sent: 31 August 2005 12:58
      To: ai-geostats@...
      Subject: [ai-geostats] Sum of Estimates

      Dear List,
      I have a rather interesting problem with my Kriged estimates for a base metal mine. I am estimating Zn, Pb and Fe, as percentage, the sum of which should total to no more than 100% total sulphides.
      All Zn comes from sphalerite (ZnS) at 0.671 proportion. Sphalerite SG = 3.80
      All Pb comes from galena (PbS) at 0.866 proportion. Galena SG = 7.40
      All Fe comes from pyrite (FeS2) at 0.466 proportion. Pyrite SG = 4.80
      Total Sulphides = (Zn estimate x 1.4903) + (Pb estimate x 1.1547) + (Fe x 2.1459)
      What I have discovered is that I have areas in which the total sulphides are greater than 100% - with very few exceptions, the total is no more than 105% total sulphide.
      My estimation domains for Zn and Pb are well constrained and validated, and the variogram models and estimation parameters are robust, and have been tested and validated to ensure they match the geological expectations. My domains for Fe are less well constrained but the variogram models are robust, as are the estimation parameters, and these also match the geological expectation. So, at the time of the estimation, there was very little I could do to improve on these. The estimation database (composited drillhole samples) have upper data value limits (or cut-offs if you wish to use that terminology) imposed on them such that :
      Zn > 40% is never used to estimate a block
      Pb > 10% is never used to estimate a block
      Fe > 46.6% is never used to estimate a block
      Thus, there is no combination of Zn, Pb and Fe in the estimation database that totals more than 100% total sulphide
      The areas with the anomalous (erroneous?) total sulphide summation all correlate, without fail, to areas of thick ore with very dominant pyrite content - there are individual blocks scattered across the mine that buck this trend. This leads me to suspect that the Fe estimates may be erroneous, or simply speaking, the Fe content is being overestimated, hence the total sulphide count exceeds the theoretical limit.
      The only solution to this problem is modifying the Fe variograms and estimation parameters, but currently, in my judgment, there is nothing I can modify that would lead to better variograms or estimation parameters. Of course there may be blocks where the total sulphide is actually underestimated, but that is impossible to determine, so the overestimates may balance the underestimates in which case there is no bias, but that needs to be tested.
      Has anyone heard of similar issues on other base metal mines? In the absence of revisiting the estimation parameters, is there anything I can do to realistically address this issue?
    Your message has been successfully submitted and would be delivered to recipients shortly.