MGinv3D

Downloads [Company Logo Image]

MGinv3D

The program MGinv3D can be used to invert mag and gravity data to generate 3d models of susceptability and density. The 3d model uses voxels which are draped under the surface topography using triangular facets to give a good approximation of the surface. The program currently handles TMI, gravity and gravity gradient data.

One thing to keep in mind when inverting data is that the resulting model can only be guaranteed to be feasible in that it will fit the observed data to the best degree possible. It does not guarantee that the resulting model is in any sense close to the actual geological structure. The utility of the model comes from how well it fits with known geology and how well the user can make inferences about the structure in areas where the geology is not known.

This aspect of mathematics has a long history and I recently came across the following quote from Bayes (1736) which expresses it quite well:

"It is not the business of the Mathematician to dispute whether quantities do in fact ever vary in the manner that is supposed, but only whether the manner of their doing so be intelligible; which being allowed, he has a right to take it for granted, and then see what deduction he can make from that supposition.... he is not inquiring how things are in matter of fact, but supposing things to be in a certain way, what are the consequences to be deduced from them; and all that is to be demanded of this is, that his suppositions be intelligible, and his inferences just from the suppositions he makes." http://www.york.ac.uk/depts/maths/histstat/bayesbarnard.pdf

Install Set Version 2.10 (25th September, 2024)

Download the installer, double click on the downloaded file and the program will be installed on your system. When you run the install for the first time you should ensure that the Add application directory to your system path checkbox is turned on.

Full MGinv3D 2.10 install (26,876 KB)

Install Set Version 1.24 (11th November, 2013)

Full MGinv3D 1.24 install (17,375KB)

MGinv3D 1.24 manual install (17,375KB)

MGinv3D Cluster Controller

Benchmarking and dependency on number of cores

With the delivery of a new Digicor MAXTRON dual CPU machine with 16 cores in total, I have undertaken a benchmarking process to determine how well the sensitivity calculation scales with the number of cores available. The first figure shows that the program is unable to take advantage of more than 4 cores:

After profiling the code to determine what parts were causing the problem, the processing time as a function of number of cores looks like this for Version 1.20:

In this figure, the processing time (mostly) decreases as a function of the number of cores until 9 cores are in use and then remains steady. The main difference between version 1.19 and 1.20 was achieved by reordering the parallel code to reduce contention in the use of the data arrays as well as the conversion of some of the previous serial code to parallel form. The hump at 6 processors is probably due to memory cache coherency problems, but is probably not large enough to warrant further investigation at this stage.

To compare how the new machine performs relative to my previous machine, I ran the benchmark with my previous Dell Studio XPS single CPU 4-core machine and the processing time looks like this:

This machine has 4 physical cores and has hyperthreading turned on. It is interesting to see that processing time does decrease as the number of threads allocated to the program increases above the actual number of physical threads. However, the processing time deteriorates significantly when the number of threads allocated to the program increases above the 8 available hyperthreads. This is expected as swapping of processes will be required causing a loss of efficiency. This figure also shows that the new machine is approximately twice as fast as the old one when the program is using all available cores. The XPS has a Core i7 975 running at 3.33GHz while the new one has dual Xeon E5-2687W CPU's running at 3.1GHz (both have turbo boost enabled and can run at peak speed of 3.4GHz). So the extra speed of the Maxtron machine is probably due to architecture improvements in the Xeon chip, increased speed of the QPI link and increases in the amount o available cache.

The above benchmarking has shown that version 1.20 has significantly increased the speed of the mtx calculation process when using 4 or more cores, but it is clear that advantage of using more than 4 cores rapidly diminishes. The reason for this reduction lies in something called Amdhal's Law which shows that the maximum speedup is determined by the amount of sequential code in the program. For the mtx calculation, the principal sequential section is that devoted to calculating the wavelet compression and this is not readily amenable to conversion to a parallel form. Fortunately, the work I have done on implementing the Cluster Controller for the sensitivity calculation means that a high-level parallelisation can be applied to the mtx calculation by splitting it up into multiple tasks. Using 16 cores, the mtx calculation time for MGsen3D is 12:06 minutes. If we instead use the Cluster Controller to allocate the mtx calculation process to two separate processes on the MAXTRON machine each using 8 threads, then the total calculation time is reduced to 8:00 minutes. Going one step further and splitting the calculation into 4 processes each using 4 threads, the time is further reduced to 4:50 minutes giving a speedup of 2.5 over the standard version. Taking this one step further still and using 8 processes with 2 cores each reduces the time taken to 4:11 minutes, so it is clear that the reduced parallelism in each task is counterbalancing the increased parallelism from adding extra processors and that 4 processes with 4 cores each is probably optimal for this particular machine.

Applying the same splitting process on the XPS machine to split the calculation between 2 processes each with 4 threads results in the calculation time being reduced from 23:24 minutes to 16:50 minutes. So there is some speed increase, but less than that for the Maxtron machine because the 8 threads available under hyperthreading are not as efficient as the real 16 cores available to be shared between the four processes running on the Maxtron.

As a final exercise, the Cluster Controller was use to run the mtx calculation using 2 processes each with 4 threads on the XPS and 4 processes each with 4 threads on the Maxtron. The time taken for this configuration was 3:50 minutes which is a speedup of about 3 times relative to the standard calculation program (or 4.4 times when compared with using best time for the XPS machine).

If you have any spare time, download the benchmark dataset below, run the inversion and send me the log files and the hardware configuration and I'll start compiling the results.

Benchmark dataset (187KB, 23rd August, 2012)

Update Log

1.21:
Improved triangulation of topo to reduce setup time for large inversions
Modified utility routines to support joint inversions
Modified cluster controller to make the specification of servers simpler
Added support for setting up joint inversions to cluster controller
NB the above changes require installation of WinDisp 5.6.180 or 3DModeller 5.6.72
1.20:
Improved performance when using multicore computers
1.19:
Added cluster controller program to distribute mtx calculation across multiple networked computers
1.17:
Added support for joint inversion of Falcon Gne and Guv data
Modified MGinv3D so that it reports RMS misfit
1.15:
Fixed bug in lbfgs library code that causes final iterates to have poor misfit (in rare circumstances)
1.14:
Added options for Apparent density style inversions
0 = normal 3D inversion
2 = Apparent den/sus (constant den/sus vertical prisms from surface to base of model)
3 = Surface + Apparent den/sus (surface layer at top of model over basement with constant vertical prisms)
Added option to automatically determine background model value from the observed data
0 = No backgraound value calculated
1 = Calculate background value using correlation between topo response and observed data values
2 = Use specified den/susc value
Added and option to specify the maximum number of observed data values per cell (only for data file input)
0 = Use all data values read from the file
1 = Use the data value closest to the centre of each cell
>1 = Use up to the specified limit data values for each cell
Added a command line option to limit the number of thread used
Usage: MGsen3d mgsen3d.inp OMP_NUM_THREADS=4 ! NB do not use any blanks between the "=" and the thread limit number