-
Notifications
You must be signed in to change notification settings - Fork 85
Forward modelling of ellipsoidal bodies for gravity and magnetic fields #568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@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! |
|
Thank you! Hopefully most of these issues have now been solved. |
|
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 |
|
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. |
|
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. |
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.
Add more tests.
Remanence vectors with wrong shape won't reach that point.
Fixes some Ruff complains after updated to latest version
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:
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:
Open to suggestions! Thank you 🙏