Closed seanmcleod closed 5 months ago
@bowers and I confirm that this patch allows the ball orbit script to produce the same exact output on linux and windows. Thank you!
Yep, I'm just waiting for @jonsberndt to review my logic and the changes to make sure that they make logical sense. Just because we're getting the same results via gcc and MSVC doesn't mean my logic is correct :wink:
Also, @bcoconni and @agodemar could potentially also double-check the orbital mechanics logic I've gone with.
@seanmcleod this pull request is fine to me. Thanks for the improvement -a
@agodemar I'm not sure why you're referencing @jentron in terms of the pull request, I submitted the pull request :wink:
@seanmcleod pardon my lapsus ;-)
Yep, I'm just waiting for @jonsberndt to review my logic and the changes to make sure that they make logical sense. Just because we're getting the same results via gcc and MSVC doesn't mean my logic is correct š
Also, @bcoconni and @agodemar could potentially also double-check the orbital mechanics logic I've gone with.
Hi, @seanmcleod,
Sorry it took so long for me to respond. I think your logic is correct and seems like you have solved the problem. I don't have any objections to this.
I may be taking a look at my astrodynamics book this evening and will see if I can find something more specific for argument of perigee in equatorial orbits. It also makes me ask the question if our calculations are robust enough to also handle polar orbits.
One more comment: In "Fundamentals of Astrodynamics (2nd ed.) there is this on page 48:
"If there is no ascending node (equatorial orbit) then both Ļ and uā are undefined."
Ļ - argument of perigee uā - argument of latitude at epoch
So the question is: what's the best approach to assigning values to argument of perigee in an equatorial orbit? Is a value of 0.0 incorrect or misleading? Can a value of #undef (whatever that might be) be assigned? Does that make sense, or is it even legal?
Yep, my understanding is that the argument of perigee isn't defined in this case and so set it to 0, although 0could be misleading. Setting it to 0 was partly also based on there being existing code which set it to 0 if the eccentricity was < 1e-8.
I guess one option is to return a floating point nan
to make it clear it's not defined, although other code may not handle nan
potentially causing exceptions etc.
One more comment: In "Fundamentals of Astrodynamics (2nd ed.) there is this on page 48:
I have the first edition from 1971. Found the same sentence on page 60.
Issued raised here - https://github.com/JSBSim-Team/jsbsim/issues/834#issuecomment-1775288126