[WIP] Anisotropy

[AndrewAnnex]

Description

This is a work in progress branch (non-functional yet), for adding anisotropic corrections to the RescaledData class. This pr will likely be up for a while as I learn how to incorporate these corrections and learn more about ways of automatically computing them.

Relates to #266 and #322

Checklist

• [ ] My code follows the PEP 8 style guidelines.
• [ ] My code uses type hinting for function and method arguments and return values.
• [ ] My code contains descriptive and helpful docstrings which are formatted per the Google Python Style Guidelines.
• [ ] I have created tests which entirely cover my code.
• [ ] The test code either 1. demonstrates at least one valuable use case (e.g. integration tests) or 2. verifies that outputs are as expected for given inputs (e.g. unit tests).
• [ ] New and existing tests pass locally with my changes.

[Leguark]

Great to see that you started looking at this! This feature is really important to increase the range of models gempy is able to deal with automatically!

[AndrewAnnex]

@Leguark so I found a deceptively easy way to implement a rescaling factor for x y and z, I just took the max call out of the function. would this change the shape of the data (relative distances between points) in a unacceptable way?

[Leguark]

Let me see if I understood you right. Are you looking for how many times one direction is larger than the other 2 and multiply by that factor?

I think that implementation should work fine for the short term (better than the one we have at the moment!). The main problems (which I think you are already aware of) are:

• the transformation is global. If you have a lot of data in a corner of the model and sparse data in the other corner, there is not a single factor that fits both areas.
• Rotation. Ideally we would do the transformation in any direction not only in xyz.

In any case, as I said before I think trying what you proposed is the first step to see if this strategy makes sense in practice!

I would just add a fast fix: Doing the transformation for each series individually. I think this is fast to implement and since each series is independent from the rest, it is better to treat them separately

[AndrewAnnex]

@Leguark currently no. For this PR I see two primarily goals:

1. to refactor the rescaling class to remove the actual transformation logic into stand alone functions to make future refactoring easier
2. Implement a modest and basic improvement to improve the situation for cases when the z range is much smaller than the x or y ranges.

The current method is a slight modification to the current implementation. For example if X has a range of 10,000, y has a range of 5,000, and z has a range of 10, it will rescale each axis with given twice those ranges, one for each axis. I believe that is totally fine and should preserve the shape of the data. But if I am wrong please correct me.

Any further improvements will be made in later PRs as there is a lot of complicated situations as you point out and no generic function that would work in all cases. Eventually, there will likely need to be a variety of methodologies available to users and as such the current conventions for the rescaleing class will not hold.

[AndrewAnnex]

@Leguark what do you think of the pr in it's current state, I want to make iterative progress so I should probably remove my pca based rotational anisotropy work to just allow for 3 different ranges. I am not sure if the c_0 and range kriging parameters/ the theano graphs need to be updated as well.

[Leguark]

hehe I like the name of the last commit. Sorry for the late response. I was focus trying to get the sprint done.

I will try to check the pull request on the weekend, if it gets too nasty I can adapt the pull request to the new code myself :)

[AndrewAnnex]

@Leguark thanks it should be a lot cleaner now than my earlier attempt (although I didn't keep the commit history).

[Leguark]

I have been on the fence if merging this now before the transform but I think it is better to wait a bit and doing it properly since there are quite big changes:

• Need of scikit learn
• We would need to update all test.

Also I think the rescaling (probably we will need to change the name once we start doing fancy transformations) would need its own module instead having it split across utils and data.

I just started to define a design doc (https://github.com/cgre-aachen/gempy/blob/master/gempy/core/engine.rst) for a summer Epic and I think anisotropies will fit better in that release!

[prisae]

Do not merge!

Hi @AndrewAnnex , I just stumbled upon your "Do not merge" line. When you create a PR you can define it as a draft PR. You can also convert an existing PR to a draft PR: This way it can't even be merged without assigning explicitly that it left the Draft-stage.

[AndrewAnnex]

@prisae good call, I learned to use WIP (work in progress) branches back in 2014 before draft PRs were a thing in github.

[prisae]

They only exist since a year or so, and I also only got to know them a few months back - that is why I thought I'd mention it. It is sort of handy.

[Leguark]

fancy :D

[Leguark]

In gempy v3 we have the transform class to deal with anisotropies link. I close this for now, thanks @AndrewAnnex