Inclination

[Roshex]

I think the problem with inclination is that the H.z component is not necessarily perpendicular to the reference plane... The solar System simulation when converted gets only slightly wrong values in most cases, but in some other sims I have an object with i=74 deg, converted to i=1.7, while i=16.5 is converted to i=15... it's clearly measuring a different angle...

If you compare the US2 inclination values of the Solar system to here: https://en.wikipedia.org/wiki/Orbital_inclination It seems that US2 defines the ref plane as the ecliptic (earth's orbital plane). But this makes no sense in any other sim - without Earth's orbit there's no ecliptic...

In other sims the ref plane seems to be the main Star's equator. The biggest star you add always starts of with 0 obliquity and without an input box for inclination so it's clear it's aligned with the ref plane. But I'm not sure the z axis is necessarily aligned with the main star because then the incli. calculation would have worked. Also note that after creation the obliquity 0 of the main star can be changed. That means we can't use the parent's equator as reference plane to calculate inclination, because this calculation will fail for objects with obliquity !=0.

I guess what I'm saying is that we need to find the actual reference plane...

[SethFusion]

Yeah, I've known about this for some time. Well, not the extent to which it was incorrect, but I knew the values were not proper. I'm not totally sure how to fix this right now, but I'll dig into it a bit to see what I can find.

I don't know specifically how the h vector could be calculated wrong unless it has something to do with subtracting the pos/vel of the parent from the object. It seems to produce normal results for everything else calculated though, so... I'm not sure. I also would expect inclination to possibly be slightly off because of the nature of simulation vs emulation. But I've never seen anything as drastic as your examples. Could you attach that file that produces those results here so I can take a look?

Edited because I misread your post.

[SethFusion]

The more I look at it, the wronger it is... I mean the orbits look okay, but then when you actually compare the numbers directly to US, just about everything but semimajor axis is totally wrong. Eccentricity is okay if it isn't binary. Maybe I just forgot how wrong it was, lol, but I'm surprised.

I'm convinced now it is a problem with the h vector. That affects every value that is calculated incorrectly, and I've long suspected something was off about it. That means that subtracting the parent's vel/pos from the current object's vel/pos is not correct, but the thing is... I wouldn't know how else to do it? There must be something more intrinsic about planetary motion that I just don't have a complete enough knowledge of.

I'm afraid I'd like to postpone releasing this again until those glaring problems are fully addressed. I will look for outside help on my campus. Maybe then I can slap a 2.0 sticker on this and feel like it deserves it.

[Roshex]

The more I look at it, the wronger it is...

Haha yep! Excatly!

To me it seems that Obliquity, Inclination, AscendingNode, ArgOfPericenter, and MeanAnomaly are all equally wrong, or rather "usually almost right and sometimes horribly wrong". The math on these seems right. I only looked into Obliquity and Inclination but these two should be right. So because they are wrong, and because they all require the h vector to work, I believe the issue is there...

But the way the h vector is calculated also seems to be right. I agree that H.z should align with the Simulation Grid's Z axis, but if it was aligned the math would work... The error could pop up if the root object's state vectors aren't relative to the simulation grid. This would carry through most of the orbital calculations because all the other objects are relative to that first object. I'm at a lost, however, on how to find the simulation grid's coordinate system to check if this is the case.

Eccentricity is a different story, because it seems to be broken only in binaries. So I'm ignoring it above...

I'm afraid I'd like to postpone releasing this again until those glaring problems are fully addressed. I will look for outside help on my campus. Maybe then I can slap a 2.0 sticker on this and feel like it deserves it.

That would be wise... "Almost right 95% of the time" is fine with my "needs", but I do believe this is fixable and not a simulation vs emulation issue (although I could be wrong). Hopefully you're able to find someone who can help!