Housekeeping + moving #130 code to a new module

[pc494]

---

name: Housekeeping + moving #130 code to a new module
about: A number of minor improvements and refactors.

---

What does this PR do? Please describe and/or link to an open issue.

(FAO: @din14970) sphere_mesh_generators

• I have moved the code you provided into a new module, this helps keep things a bit easier to read, I apologise for doing it in a seperate PR like this
• I have change the output of get_grid_beam_directions to be euler angles, converted using the function you wrote

other things

• makes use of the .github folder
• removes python 3.6 testing
• black reformatting

TO DO

• Think of the best way to write the changelog
• correct the docstrings on get_grid_beam_directions

[din14970]

Note though that these are not precisely the same anymore. Ignoring the rad/deg conversion:

arctan ( tan(theta) / sqrt(2) ) != theta/sqrt(2)

See:

The orange curve is the arctan one vs angle in degrees, the blue is the linear one. For small angles they are about the same so on the grid it won't make a big difference.

The double tan expression is derived from the relationship between angles of the first gridpoint from 001 towards 011 theta_011 and the first gridpoint from 001 towards 111 theta_111. It can be shown that for the cube mesh:

tan(theta_111) = tan (theta_011) * sqrt(2)

On the normalized and spherified edge grids, theta_011 = resolution, but by cropping to the hexagonal fundamental zone, the closest gridpoint to 001 becomes the first point towards 111. Hence to maintain the definition that resolution is the smallest nearest neighbor angle, I set resolution so that theta_111 = resolution will hold in this case.

But considering that both curves represent resolution and the blue line is always below the orange line, it is more conservative and "safer" in a way.

[pc494]

@din14970 thanks! That is poor from me, and you are obviously correct. I will revert that change, I assume I misread the brackets and was (too) excited to remove code.

The deg2rad rad2deg change is fine though?

[din14970]

Removing the max angle check is a bit unfortunate in a way because this is how I found the issue with the hexagonal grid. But obviously if get_beam_directions_grid now directly outputs euler angles this test will no longer work.

[pc494]

Removing the max angle check is a bit unfortunate in a way because this is how I found the issue with the hexagonal grid. But obviously if get_beam_directions_grid now directly outputs euler angles this test will no longer work.

I've been wondering about generalising the "max_angle" test method to all our griddings, and this is probably the evidence I need that we should do that.

EDIT: but also, I think outputting euler angles is far more consistent with the other functionality in rotation_list_generators

[din14970]

@pc494 it was just a comment because I noticed it wasn't the same, but now looking into it I think this simplified expression is in fact better. So I would leave it as is in fact. Otherwise one will run into weird issues if a user would select a very widely spaced grid.

[din14970]

@pc494 yes agreed, perhaps the max angle function can be rewritten, or another similar one can be made, to accept euler angles/rotations/quaternions as input. I think the way I have implemented it should be quite performant.