Bugfix: IEEE invalid operation when checking for central body collision

[tobiscode]

Hi all,

I sometimes stumble across the following warning message when running Mercury:

Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

With not much more to go on, I added the gfortran compiler flag -ffpe-trap=invalid to find the problem: calling acos() for a value less than -1, for which acos is not defined. Here is the part (line 963 in mercury6_2.for):

u0 = sign (acos((1.d0 - r0/a )/e), rv0)

I assumed that it was a rounding issue, since the values I got when checking were -1.0000000000288831 and -1.0000000002232341 (all at high e), but I don't understand all of the variabls exactly so I can't be 100% sure. I therefore added a check for the value before passing it on to acos, and setting the boundary values when a value is outside the (-1, 1) range. I also added the compiler flags to the Makefile to make sure people will catch more of these bugs when/if they occur.

Hope that helps someone!
Cheers

[texadactyl]

@tobiscode Suggest you create an issue for tracking. Explain precisely how you ran Mercury (E.g. parameter values).

Since you were debug printing, what were the values of r0, a, e, and rv0 when this occurred?

What environment ('nix, Windows, Mac, ...) do you use and how did you compile the project?

[texadactyl]

@tobiscode

"Avoid invalid acos calls when checking for central body collision"

Given certain input parameter values, what if that calculation uncovered an inherent issue never before seen? Your code would cover it up.

A value of -1.0000000000288831 can be excused with an appropriate error tolerance. But, a value of -42 should not be excused - throw an exception and provide as much empirical evidence as possible (E.g. values for r0, a, e, ev0).

You need to distinguish between "close enough" and "this is not correct at all".

Again, before the project owners (4xxi) take any action, they will probably need to see an issue recorded with DETAILED directions from you for reproducing your findings. Your report must be reproducible by a second party.

Using the sample parameters, I cannot reproduce your findings.

[tobiscode]

I totally agree @texadactyl, it should not mask a different error - Sorry for the delayed response (busy week). I've created an issue #20 with initial conditions that reproduce the error, and with more debugging info.

[texadactyl]

@tobiscode I suggest that you withdraw/cancel this pull request as @idovgalyov-4xxi has said that he will address issue #20.