History of the Software Development
mXrap v5 (2013 - today)
mXrap v5 (2013 – today)
Project Leader: Daniel Cumming-Potvin Software Engineers: Paul Harris, Matt Heinsen Egan Conceptual Software Design: Paul Harris, Johan Wesseloo and Daniel Cumming-Potvin App development: Johan Wesseloo, Paul Harris, Kyle Woodward, Dan Cumming-Potvin, Matt Heinsen Egan, Stuart Tierney, Denisha Sewnun
In 2013 mXrap finally matured sufficiently for us to stamp it as mXrap v5 (the version numbering continued from the v4 of its predecessor).
This is the current version that supports the standard ACG apps. To view these apps you can visit here here
mXrap beta (2012 - 2013)
mXrap beta (2012 – 2013)
Project Leader: Johan Wesseloo Software Engineer: Paul Harris Conceptual Software Design: Paul Harris and Johan Wesseloo App development: Johan Wesseloo, Paul Harris, Kyle Woodward, Dan Cumming-Potvin, Wei Duan
The development of a user-friendly interface was lacking, which made MS-RAP v4 difficult to use. This was in contrast to the purpose of MS-RAP, namely to serve as a technology transfer tool for the research activities. We needed to retain the power of MS-RAP v4 and regain the simplicity of use of MS-RAP v3. Thus, we developed a user-friendly interface and an app system.
With this system we were able to reduce the complexity of the software by creating focussed apps dedicated to smaller tasks, each with its own interface that can be tailored towards the level of the user’s expertise. With this interface mXrap was created.
MS-RAP v4 (2010 - 2013)
MS-RAP v4 (2010 – 2013)
Software Engineer: Paul Harris Conceptual Software Design: Paul Harris and Johan Wesseloo App development: Johan Wesseloo and Paul Harris
MS-RAP v3 added a lot of value to users, however, as the user base expanded it became apparent that the software was not flexible enough to cater for the specific needs and intricacies at all sites. Also, as geotechnical engineers we saw the seismic data as only one piece of the puzzle and had (and still have) the vision of building a full geotechnical model from many different sources of data and instrumentation, and to be able to combine this data and analyse it and turn it into useful geotechnical information. MS-RAP v3 was not suited for this purpose.
We therefore embarked on designing and developing MS-RAP v4 as a platform in which different kinds of data can be imported, manipulated through different scripting tools and displayed and interacted with. MS-RAP v4 as a platform with scripting tools allowed our research team to develop their own analysis calculations, charts, tables, and 3D views and to easily share the data within the team and apply it to different datasets.
The early development was slow as we needed to properly design and build the foundation of this new software in such a way that it will sustain future development. MS-RAP v4 had a very simple interface which worked very well with a limited system. However, the power that the software provided to the research team resulted in the research team very quickly outgrowing the interface.
In a way MS-RAP v4 was born out of the naivety and shear ignorance of how much work, time, tears and pain it would generate on the road to becoming useful. But we persisted. With every new scripting tool and user interface tool added, the capabilities, options and ideas grew at an increased rate. The user-friendliness however suffered. New users to the software was overwhelmed by the software as the user interface lacked structure. As a result the user interface became the limiting factor in the further development of tools for the sponsors.
An interesting observation we made was that there was a strong correlation between the age of the end user and the ease with they learned the new software. Younger users with no previous experience with v3, was the quickest to learn the software and preferred using v4 to v3.
In spite of the difficulties we experienced during this earlier development period, we have experienced the positive support of the projects sponsors and users. This support allowed us to get through the teething period to the point were MS-RAP v4 was mature enough to take the next step, to fix the user interface.
MS-RAP v3 (2005 - 2014)
MS-RAP v3 (2005 – 2014)
Project Leader: Marty Hudyma, Dan Heal Software Engineer: Paul Harris Conceptual Software Design: Paul Harris & Marty Hudyma Dan Heal
Version 3 brought a step change in capability and control to the user. Multiple computations could run in parallel, and a collapsible control panel interface brought easy structured access to controls for the user. To date, MS-RAP v3 is the version with the longest life and support for it was only ended in February 2015. This version included many of the tools for analysis of mining induced seismicity, many of which found its way in one form or another into the mXrap Mining Induced Seismicity – General analysis app.
Screenshot of MS-RAP V3
Clustering and Cluster-Grouping formed the basis for the Cluster Tracking Monitor and spatial filtering. Range filters and time slicing filers were also available to filter data to be plotted on the charts and spatial plots. A Cluster and Cluster-Group based seismic hazard assessment was first implemented into v3, with the Rockburst Damage Potential (RDP) developed by Dan Heal (2010) added later. For this purpose it was necessary to generate points along excavation tunnels so that hazard and RDP calculations can be performed on these points. For the RDP the excavation span was also necessary, which was defined as the biggest disc that can be fitted inside an excavation. These points along the drives were called “minodes” (pronounced “mine-nodes”), a term we still use today. A fast and efficient algorithm was developed to automatically generate these minodes from 3D surveys (or models) or 3D floors.
Amongst other features, MS-RAP v3 also included a blast database which allowed for displaying and studying the relationship between the mining induced seismicity and the blasts. For this reason, the easy generation of “Omori Charts” for blasts selected by the user was also added as a feature.
MS-RAP v3 was very well received and for a long time has served the sponsors well. It was easy to use, quick to learn and quick to perform standard analysis.
But, all good things come to an end, and it became necessary to redesign the software to make better use of new software technology. With this redesign came a change in software strategy and the decision was made to change MS-RAP to a development “platform” for a rock engineering environment.
Project Leader: Marty Hudyma Software Engineer: Paul Harris Conceptual Software Design: Paul Harris & Marty Hudyma
This version of MS-RAP was the first to plot seismic events and mine plans in 3D. Although still very limited, its capability gradually continued to improve. Paul Harris wrote this version in C++ and continue to develop in C++ for all subsequent versions. One of the most frustrating drawbacks of this version was that it performed only one computation at a time, meaning that the software would freeze up and the user would have to wait until the computation had finished before doing anything else. Efficient parallel processing was implemented in subsequent versions.
Project Leader: Marty Hudyma Software Engineer: Harman Information Technology, Paul Harris Conceptual Software Design: Paul Harris & Marty Hudyma
MS-RAP v1 was programmed by Harman Information Technology and was released in 2000. One can not help but smile at the fact that one of the major features was the ability to get seismic events into a Microsoft Access database. Once connected to the database, one could click on the buttons in a tiny window to pop-up other windows, to look at a table of events for example.
Paul Harris joined the ACG’s MSRRM team in the middle of 2001. He inherited MS-RAP v1 and started working on it, focusing on adding new features. MS-RAP v1 was written in Visual Basic. Paul continued the V1 development using VB6 until a rewrite occurred in C++ with Version 2.
After November 2001, Paul was requested to improve the program so that it will be capable of importing all of the 6000 event from a particular data file. Diving into our archives revealed that one mine had about 700 events, another 1400 and yet another 3500. Who would have thought that 10 years later mXrap would be required to load several million events, and perform clustering in a few minutes? The largest datasets that MS-RAP needed to deal with was the survey files (some things never change). The largest survey set v1 was subjected to consisted of only lines between some 20 000 vertices.