Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@KellySavanna
Copy link

@KellySavanna KellySavanna commented Jun 17, 2025

This repo produces the magnetic and gravitational forward models of ellipsoidal bodies, much like the current Harmonica forward modelling packages. This was achieved with use of magnetic and gravitational ellipsoid derivations outlined in:

  • Clark, D. A., Saul, S. J., & Emerson, D. W. (1986). Magnetic and gravity anomalies of a triaxial ellipsoid. Exploration Geophysics, 17(4), 189–200. https://doi.org/10.1071/EG986189
  • Takahashi, D., & Oliveira Jr., V. C. (2017). Ellipsoids (v1.0): 3-D magnetic modelling of ellipsoidal bodies. Geoscientific Model Development, 10(9), 3591–3608. https://doi.org/10.5194/gmd-10-3591-2017.

There are three main .py files included: ellipsoid_magnetics.py for producing the total magnetic field due to ellipsoidal bodies, ellipsoid_gravity.py for the equivalent gravity fields, and create_ellipsoids.py to create the input ellipsoid for these functions. Tests for the code are included in /tests.

The user can specify the type of ellipsoid (triaxial: a > b > c, prolate: a > b = c, oblate a < b = c where a is the semi-major axis), the rotation components of the ellipsoid in intrinsic Euler angles (yaw, pitch and roll), and the centre of the ellipsoid in their given coordinate system. It also allows for multiple ellipsoidal bodies to be modelled, and produce and produce an array of the total anomaly as three components (be, bn, bu) or (ge, gn, gu) as (easting, northing, upward) magnetic and gravity components, respectfully. Users can also specify which component of the field to return (easting or northing or upward), and relevant input parameters such as susceptibility (isotropic or anisotropic), density and regional field $H_0$.

This code would be a useful addition to Harmonica, particularly in forward modelling for applications such as ore bodies.

! Work in progress !

Current proposed additions / works in progress:

  • Option to add remnant magnetisation
  • Option to return total field anomaly

Open to suggestions! Thank you 🙏

@KellySavanna KellySavanna changed the title Forward modelling of ellipsoidal bodies fir gravity and magnetic fields - Forward modelling of ellipsoidal bodies for gravity and magnetic fields - Jun 17, 2025
@KellySavanna KellySavanna marked this pull request as draft June 17, 2025 22:13
@KellySavanna KellySavanna marked this pull request as ready for review June 17, 2025 22:51
@leouieda
Copy link
Member

@KellySavanna thank you for the contribution and welcome to Fatiando! Great to have you here ❤️

I have enabled GitHub Actions for your pull request. Please take a look at the logs by clicking on each failed job to see what went wrong. Don't worry, this is very normal and we all get failing jobs almost every time.

I'll have a closer look at the code later but for now I can say that we don't need an option to return the total-field anomaly. The anomaly can already be calculated from the B field using https://www.fatiando.org/harmonica/latest/api/generated/harmonica.total_field_anomaly.html#harmonica.total_field_anomaly

Let me know if you need help with anything in particular!

@KellySavanna
Copy link
Author

Thank you! Hopefully most of these issues have now been solved.

@KellySavanna KellySavanna marked this pull request as draft June 19, 2025 15:58
@KellySavanna KellySavanna marked this pull request as ready for review July 14, 2025 08:31
@KellySavanna KellySavanna marked this pull request as draft July 14, 2025 08:32
@nwilliams-kobold
Copy link

Great contribution @KellySavanna. I've been trying to reconcile the Takahashi and Clarke formulations, but now I don't have to! It would be super helpful to have a get_ellipsoid helper function that accepts 3 arbitrary axis dimensions, and then returns the appropriate class. It will commonly be the case that a user has an arbitrary ellipsoid, and just wants to simulate it, without figuring out whether it is prolate, oblate, triaxial. It would be even better if the helper function also handled the case of a == b == c by returning a spherical class (which may just be a wrapper of the existing point source and dipole classes). Is that doable?

@santisoler
Copy link
Member

Hi @nwilliams-kobold. Thanks for your inputs on this PR.

We do plan to include a constructor function for ellipsoids that would work like you describe it.

@KellySavanna also started adding support for remnant magnetization. We were discussing whether the magnetization vector that is passed to the function should be defined in the global coordinate system (easting, northing, upward), or aligned with the ellipsoid's axes (the local coordinate system). The former would define a constant magnetization vector, regardless of the orientation of the ellipsoid. The latter would make the magnetization vector to rotate with the ellipsoid.

We are more inclined to define the magnetization vector in terms of its easting, northing and updated components, but we would like to hear your thoughts considering your potential applications for this code.

@nwilliams-kobold
Copy link

nwilliams-kobold commented Aug 18, 2025

Super cool!

I definitely suggest defining the direction vector and ellipsoid rotation independently. We know they are degenerately-coupled (we can't resolve both at the same time with constraint), but we always hope we can find independent control of one or the other: e.g., paleomag measurements to constrain the vector, or positional or orientation constraints to constrain the ellipsoid shape and orientation. Thus allowing independent and natural inclusion of either directly (vector as east-north-up, and rotation as relative to east-north-up), without having to constantly rotate reference frames is very helpful, and less prone to error.

santisoler and others added 28 commits September 12, 2025 14:04
Use intrinsic rotations for the rotation matrix, instead of extrinsic
ones. To do so we need to use capitalized letters for the axes passed to
the `from_euler()` function.
Test symmetry of the magnetic field when flipping the ellipsoid. The
magnetic field should be preserved when the rotation results into an
ellipsoid of the same geometry (but different angles).
Use the sign convention in Clark et al. (1986), where: H = - N M, so the
minus sign is outside the definition of N.
Pass the internal n_tensor to get_magnetization so we avoid computing it
twice on a single run.
Improve the sanity checks for the inputs of the public function. Move
the casting of the remanence to the function that computes the magnetic
field of a single ellipsoid, so we can pass an heterogeneous list as the
remanence (including Nones). Rename the `calculate_lambda` function to
make it public in the module (but not exposed in the API).
Add test for multiple ellipsoids with remanence.
Extend tests for invalid inputs. Extend check for susceptibilities and
remanent mag to Sequence and ndarray.
Remanence vectors with wrong shape won't reach that point.
Fixes some Ruff complains after updated to latest version
@leouieda leouieda changed the title Forward modelling of ellipsoidal bodies for gravity and magnetic fields - Forward modelling of ellipsoidal bodies for gravity and magnetic fields Sep 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants