Implement tilt filter

[mtb-za]

This will create a filter to determine the tilt of a potential field, as developed by Miller and Singh (1994).

I could use some suggestions on how to create a sensible test for this.

This is the first of a few potential field filters that I want to implement.

Checklist:

• Make tests for new code
• Create/update docstrings
• Include relevant equations and citations in docstrings
• Code follows PEP8 style conventions
• Code and docs have been spellchecked
• Include new dependencies in docs, requirements.txt, README, and .travis.yml
• Documentation builds properly
• All tests pass
• Can be merged
• Changelog entry (leave for last)

[mtb-za]

@leouieda Do you know why the CI is failing with The command "pip install -q --use-mirrors coverage==3.7.1 coveralls==0.5 pep8==1.6.0 sphinx_bootstrap_theme==0.4.5" failed and exited with 2 during .

I do not think that I have touched anything that should affect that....

[leouieda]

@mtb-za thanks for taking the time to do this!

I'll take a look at the Travis log and see if I can figure out what is going on.

As for the tests, does the original paper mention any analytical solutions? Maybe for a point source or something like that. That is always a nice test case. If not, then testing for sanity is already something (like checking if values are within the allowed bounds and other conditions).

[leouieda]

@mtb-za seems that your branch is way behind master. Do you remember if you pulled in the latest changes from fatiando/fatiando before creating your tilt_filer branch?

If not, then you should update your master branch and also this branch. You can do that with the following:

1. Backup your repository somewhere, just in case.

2. Register this repository as a remote option. We'll call it upstream:

   git remote add upstream https://github.com/fatiando/fatiando.git
   

3. Pull in the changes from the upstream master branch to your own:

   git checkout master
   git pull upstream master
   

4. Now we can rebase your tilt_filer branch to be based on the updated master:

   git checkout tilt_filer
   git rebase master
   

5. Rebasing should not give any conflicts for now. If it does, you'll need to resolve them (let me know). Rebasing will change your commits, so the ones you have now are not the ones you have on Github. You'll need to force push the new commits:

   git push -f origin tilt_filer
   

Try this out and let me know if it works.

Also, keep in mind that you should always pull changes from upstream master before creating your branches. And always make your branchs from master.

[mtb-za]

I have no idea how that happened. I am pretty sure that I had pulled in the upstream stuff before going ahead.

Anyway, I seem to have a clean base off master and have restarted.

[mtb-za]

It looks like it will need to be a sanity check. There is no analytical solution within the original paper.

The tilt angle overcomes this problem by dealing
with the ratio of the vertical derivative to the horizontal
gradient. Since both will be smaller for deeper sources,
the ratio will still be large when over the source, pass
through zero over, or near, the edge where the vertical
derivative is zero and the horizontal gradient is a maximum,
and will be negative outside the body where the
vertical derivative is negative. By expressing this as a
tilt angle rather than a ratio it will always be in the range
-90°< TILT< 90 °.

Maybe a relatively simple test that the tilt does return a positive value over a body, zero at the edge, and negative outside the body will work?

[leouieda]

@mtb-za git can be mysterious sometimes always. Reminds me of xkcd:

[leouieda]

Maybe a relatively simple test that the tilt does return a positive value over a body, zero at the edge, and negative outside the body will work?

That might be useful. Maybe use a single rectangular prism with data almost right on top of it. 0 height for the observations might cause problems but maybe have it a 10 meters or so. In that case the tilt should behave as advertised.

Would be good to have a sanity check that everything is within the -90, 90 degree range, even for more complex data.

[leouieda]

Please add a blank line between each section.

[leouieda]

Maybe not "magnetic tilt", as this can be used for other things as well? "potential field tilt angle" perhaps?

[mtb-za]

Hmmmm.... There is definitely something odd going on here.

I am getting a lot of NaN results, after making a simple example similar to the TGA cookbook. I will have to do some checking as to where those might be creeping in.

[leouieda]

@mtb-za nice! Thanks for doing this so fast.

[leouieda]

There is a build error caused by a doctest in fatiando.inversion. I'm fixing that in #264. I'll let you know as soon as that is done so that you can git rebase this off master again.

[leouieda]

@mtb-za #264 was merged and tests are working now. When you get a chance, please do a git rebase of this branch to get the new changes.

[leouieda]

@mtb-za let me know you want me to look at this again. Nice work!

[mtb-za]

I could use some help with setting up the test we discussed.

The paper does mention that there is an analytic solution, by the way, but not what it is.

[leouieda]

@mtb-za testing is hard. I haven't gotten that used to it yet as well. Specially when you don't have a good comparison.

This is the case with the prism forward modeling. It's not practical to calculate the solution by hand. So what I did was run a lot of sanity checks and compare against a pure numpy implementation. See test/test_gravmag_prism.py. A lot of those tests I wrote as consequence of a bug.

Some ideas for the tilt:

• Should all be in a certain angle range (is it -90-90?). So you can calculate for a single prism model and check if all are in the range.
• Should be symmetric if the prism is a cube and in the middle of the data grid. Both sides of the grid should have the same tilt right?
• Check if the code fails when it should. The shape multiplied should be the size of the arrays. The arrays should be equal size. All these should be checked with an assert at the start of the function. You tests should pass bad input and check if an AssertionError is raised.

[leouieda]

@mtb-za just thought of this and wanted to write it down:

It would be good if the function had the option to receive the x, y, z derivatives as input. They could default to None and be calculated by derivx etc if that is the case. This would be good if the user has the derivatives somehow, maybe measured or calculated some other way (like equivalent layer).

This would also be handy when testing. We could test the function passing it analytical derivatives (calculated from the model) and check against the numerical result. It should be the same if the anomaly is error free and not truncated.

[mtb-za]

I think I misread/forgot/ignored that z is positive down.

Your example works well, and is what I would expect:

It seems to return something reasonable for the following as well, with nothing else changed:

model = [mesher.Prism(-3500, -2500, -200, 200, 0, 1000, {'magnetization': mag}),
    mesher.Prism(-500, 500, -200, 200, 300, 1300, {'magnetization': mag}),
    mesher.Prism(2500, 3500, -200, 200, 600, 1600, {'magnetization': mag})]

It also seems to be ok on pole-reduced data that starts with an inclination of some kind, albeit with some edge effects, and a series of artifacts if very close to the top of the prism. I offset the blocks slightly in the x-axis here.

I have had a look, and it seems like additional padding on the edges of the grid which can be removed later does not seem entirely unheard of in cases like this, so it seems to be behaving better than I initially thought.

I will try and get some good tests done as soon as possible; am looking forward to putting this one behind me.

[leouieda]

@mtb-za I ran a git rebase master on this branch and got a sane commit history now. This is something I've struggled with before. It's one the things that can trip you up in git. But it should be fine now.

Beware though that the tests have moved to fatiando/tests and that the tests are run with py.test. Take a look at the Makefile or the latest dev docs.

[leouieda]

Please avoid the mpl module as a replacement for matplotlib.pyplot. This will be removed in the future. I really need to write this down somewhere or deprecate it already.

[leouieda]

I'll make some changes to your tests just to get things moving a bit faster. I guess you're pretty sick of looking at the tilt by now 😄

[leouieda]

Avoid comparing to None with == or !=. The proper way is to use xderiv is None or xderiv is not None.

[leouieda]

Would it be worth it returning the tilt in degrees instead of radians?

[leouieda]

@mtb-za I made slight changes to your tests. The first tests for sane results and I removed the pole reduction for simplicity. It seems that the pole reduction is adding a lot of noise to the tilt, so it's better to test without it. The second tests checks if the tilt results are the same when given analytical derivatives. I'm using gravity for this case. Both cover 100% of the function code so they are good enough.

I also transformed your cookbook recipes into a gallery plot. I tried doing the pole reduction on this but it looks terrible. The problem is with the pole reduction, not the tilt. So I'm using data at the pole for the gallery and linking it to reduce_to_pole for completeness.

Lastly, I made some PEP8 adjustments that were causing Travis to fail.

All this needs now is the changelog entry. Would you do the honors? Then we can merge this and be done with it!

[mtb-za]

Changelog is done, even if you did most of the work. Glad to finally lay this one to rest though!

Onto the next thing: depth estimations. panics

[leouieda]

@mtb-za non-sense! You did all the preparation and investigating what the tilt should actually do. I just polished it up. Truth is, I'm also learning all this as I go. I cringe every time I look at code that's > 1 month old.

I'm looking forward to the next PR! Keep 'em coming!