Are you surveys really slow to load? Are you having difficulty rotating your 3D view?

The problem might be the level of detail in your survey files. If the level of detail of survey files is unnecessarily high, it will slow down the 3D view for no reason. This is often the case with stope CMS files. To reduce the level of unnecessary detail in your survey files:

Open the Survey Setup Window (can be found in the General Analysis app) and select the surveys you’re interested in (on the left). Click on Decimation, then turn on the Decimation Override using the tick box. Set the Target Reduction. This number is how much mXrap will try to reduce the size of your surveys (i.e. with a Target Reduction of 90%, mXrap will try to reduce the number of points to 10% of the original size). You should set this to as high a number as possible, while still being able to see the level of detail in your surveys that you need (somewhere between 60 and 90% often improves the speed of the 3D view dramatically, without making the surveys look awful). Don’t forget to Rebuild the Cache and hit Save before looking at your 3D view!

If you need a refresher on updating surveys, watch the Survey Setup training video here.

Are you unable to see your surveys, but can’t work out why? Are some of your surveys located a long way away from the rest of your mine when they shouldn’t be?

This could be due to the input configuration of your survey files. The order of the co-ordinate components (Easting, Northing, RL) are sometimes different for some survey formats, so we have to ‘flip’ the X and Y co-ordinates. This is often the case for DTM files. To fix this:

Open the Survey Setup Window (can be found in the General Analysis app) and find the surveys with an issue. Click on Input Config, then turn on the Override using the tick box. Click the swap button between X and Y to change whether X and Y are the first or second column. Don’t forget to rebuild the cache and hit save!

If you need a refresher on updating surveys, watch the Survey Setup training video here.

The Iso View in the Hazard Assessment application expresses the seismic hazard in two ways.

The current yearly hazard within the chosen grid volume. This is shown in the footer of the 3D view, as the probability of an event exceeding the design magnitude.

The spatial distribution of the hazard. This is highlighted by the hazard isosurfaces.

In the case below, the design magnitude is set as M_{L}2. The corresponding hazard isosurfaces for M_{L}2 can be interpreted as the most likely location for that event to occur.

The M_{L} rating essentially delineates the areas of the mine from lowest to highest hazard. The volume bounded by the M_{L}2 isosurface indicates the M_{L} rating is above M_{L}2. Note that the colours in the legend are slightly different than the isosurfaces’ apparent colour in the 3D view. This is due to transparency effects and viewing multiple transparent surfaces on top of one another.

It is important to note that while the data period can change (6 months in the example above), the hazard calculations are all referring to the yearly hazard. This is a simple matter of normalisation. E.g. if you record 100 events in an area in six months, this area is assigned an activity rate of 200 events per year.

The use of yearly hazard is to help interpretation. Reducing the time period used in the definition reduces the probabilistic hazard and this can be misleading. For example, let’s say you give your mine manager a report every day and it says that based on recent data, the probability that we will experience an event in the next 24 hours over M_{L}2 is 0.77%. You do this every day for a year and each day, the mine manager looks at the number and thinks, “Hmm, 0.77%, that’s pretty small, risk is pretty low”. A daily hazard of 0.77% is the same as the yearly hazard in the example above.

1 – (1 – 0.0077)^{365} = 94%

The mine manager may interpret the risk more accurately when presented with the same hazard but expressed for a hazard period that is more intuitive.

The current yearly hazard displayed in the footer of the 3D view applies to the entire volume of the chosen grid. We also compute the yearly hazard in the VTM table in General Analysis. So, you might reasonably assume that if you specify a volume in General Analysis the same as the grid volume in the Hazard app, the two numbers should match. In fact, while the probability of exceeding M_{L}2 is 94% in the example above, the same volume and time period in the VTM table gives 86%.

This is because the two calculation methods are quite different. To compute hazard, the main inputs are the seismic activity rate, and the b-value (M_{min} and M_{UL} are also required). In the VTM table, a single b-value and activity rate is computed for events within the volume, and the seismic hazard is computed directly. In cases where the b-value does not vary significantly within the volume, this is a reasonable approach. However, in most cases, the b-value varies in space, and this approach tends to underestimate the seismic hazard.

This is illustrated in the figure below. You can represent the full volume with its activity rate and b-value to compute the probabilistic hazard, like in the VTM table. In the Hazard app, the variations in activity rate and b-values are calculated on a regular grid through space (in sub-volumes). While the event search radius for each grid point may exceed the grid cell spacing, the activity rate is normalised and the b-value is assigned to represent the seismicity for the specific grid cell volume. The probability of exceeding the design magnitude within each sub-volume can then be calculated. Then the probabilistic hazard for the full volume can be calculated by integrating together all of the sub-probabilities.

M_{L} Rating – Technical Meaning

As mentioned already, the yearly seismic hazard is expressed as the probability of exceeding the design magnitude. An alternate definition of hazard, is to use a design reliability rather than a design magnitude. I.e. the hazard can be expressed as the magnitude that, to the design reliability, will not be exceeded. We use a reliability of 85%. The M_{L} rating is the design magnitude that would have a probability of exceedance of 15%.

An M_{L} rating is assigned to each grid point to compute the isosurfaces. On the surface of the M_{L}2 iso for example, the M_{L} rating refers to the magnitude that, to a reliability of 85%, would not be exceeded within the standard volume given one year’s seismicity. The standard volume we use is that of a sphere of 50m radius.

Minodes are what we use in multiple places in mXrap if we want to assign information to development. They are just point locations, dotted along your development, in roughly 5m intervals. Things like ground support and PPV hazard are really only relevant for development locations, so minodes are our way of denoting these places. Minodes are also used to calculate the span of the excavation at that point. The tunnel length is also used in the Hazard Assessment app.

Minodes are not generated automatically for new development. The minode calculations use an older generation of code that can’t be used in the current mXrap. So, we need to generate the minodes for you periodically as you add more development. Minodes can be created from floor strings but 3D development surveys work best, the same formats you use for mXrap.

Minode Update Procedure

Add your most recent 3D development surveys to the #Data folder in your root. Include all surveys where you want to show minodes, even if minodes are already there.

Run a default backup of your root folder in mXsync. If you are unsure how to do that, review the “Intro and Default Backup” video on the mXsync page.

Send an email to support@mxrap.com and ask us to update your minodes. Please confirm that you have updated your surveys, run a backup in mXsync, and indicate which surveys are for minode generation. It can take some time depending on other work, so please indicate if it is especially urgent.

We will generate your new minodes and merge all previous information from the old minodes. We will let you know when it’s done via email.

Your new minodes will be sent as a patch in mXsync back to you. All you need to do is apply the update. See the “Apply patch” video on the mXsync page.

Review your new minodes (in the Hazard Assessment app for example) and confirm they are as expected. Then run another default backup in mXsync if you are happy. Contact support if there are any problems.

Yes, this is a frequently asked question…. M_{UL} or M_{Upper-Limit} refers to the truncating magnitude of the Gutenberg-Richter distribution. We used to refer to this as M_{max} in the Hazard Assessment app and on the Frequency-Magnitude chart but we found there was confusion caused by M_{max} being used to describe multiple things. Hopefully if we refer to M_{UL} or the Upper-Limit Magnitude, this will clear up the terminology a little.

A quick review on the terminology that concerns the Frequency-Magnitude chart and the Gutenberg-Richter distribution:

M_{min} – The magnitude of completeness, the dataset is considered complete above this magnitude (property of the data)

b-value – The slope of the Gutenberg-Richter distribution, describes how the frequency of events scales with magnitude (property of the statistical model)

X_{max} – The largest magnitude event in the dataset (property of the data)

a/b – The magnitude at N = 1 of the GR distribution (property of the model, maximum likelihood, see previous blog post)

max(m,n) – This is the probability density function, given n events, of the largest event in that n events. This is a property of the GR statistical model. In other words, given a certain GR model, if you record N events, what is the largest event? This is not a single number but a likelihood distribution. The maximum likelihood of the largest event is the a/b value.

M_{UL} – The Upper-Limit Magnitude of the max(m,n) distribution. It is an estimate only and a property of the statistical model.

The truncating magnitude has slightly different meanings in mining seismology and crustal seismology. M_{UL} is usually referred to as M_{max} in crustal seismology literature and is generally considered constant for a particular area. In mining seismology M_{UL} generally increases over time given the gradual increase in mining dimensions and loading of the rock mass. For this reason the definition is slightly modified in mining seismology to be the upper limit of the next largest event.

Why do we need an upper-limit or truncating magnitude?

The truncated Gutenberg-Richter distribution, rather than the open-ended distribution, is the most common frequency-magnitude relationship used in mine seismology. If there is no upper limit given to the GR distribution, then to evaluate the total energy of events in the relevant time period, the energy tends to infinity as the relationship is integrated above M_{min}. This is clearly unrealistic.

We know there is a physical limit to possible magnitudes since the size of large earthquakes is related to the slip area of the fault and the physical size of faults is limited. Earthquakes on Earth above magnitude 10 (Richter) are essentially impossible given the size of known faults and a magnitude above 12 represents a fault area larger than the Earth itself!

So it is safe to say that M_{UL} for a particular mine is going to be less than Richter Magnitude 10. The question is how much less is reasonable given the significantly reduced physical dimensions in mining.

How do we estimate M_{UL}?

An empirical method of estimating M_{UL} can be taken using a dataset compiled by McGarr et al. (2002) of large events and the largest dimension of the human activity associated with them. The figure on the right comes from Wesseloo (2018) who added a few extra points to the dataset from Australian and Canadian mines. The range applicable to mining indicates rough dimensions between 500 and 5,000m.

Aside from the empirical approach, there are also statistical approaches to estimating M_{UL}. These generally take the form:

M_{UL} ≈ X_{max} + Δ

There are a number of different methods for calculating the Δ value. Many of these methods are described by Kijko and Singh (2011). Most of these have been implemented in the Hazard Assessment app along with the associated uncertainty of each method as described by Lasocki and Urban (2011).

It is better to over-estimate M_{UL} than to under-estimate it. In terms of probabilistic seismic hazard calculations, the truncated GR model will always give a lower hazard result than the original GR, for magnitudes approaching M_{UL}. For magnitudes well below M_{UL}, the seismic hazard calculations are the same. In the Hazard Assessment app, we take the maximum of each M_{UL} + σ estimate from multiple methods.

These statistical approaches assume the recorded magnitudes of large events are reliable. Moment is under-recorded for large events if there are no low-frequency sensors installed. The figure to the left comes from Morkel and Wesseloo (2017) showing the effect on the frequency-magnitude relationship, given certain sensor bandwidth limitations.

In cases like this it is best to override the M_{UL} as it is likely to be under-estimated with statistical methods.

Conclusion

While it is important to understand what M_{UL} is and how it effects seismic hazard calculations, it is not something to use for design purposes or to communicate seismic hazard. It is just one part of how seismic hazard is defined. By definition, the probability of an event exceeding M_{UL} is zero, so it isn’t a great measure of seismic hazard.

If you have any questions regarding this topic, or something to add, feel free to leave a comment or send an email to support.