Orbital period of binaries

[Roshex]

https://github.com/SethFusion/US2-to-SE-Converter/blob/6d0ae88b22832193f8d8bec2eff1a98bbcbf6f27/US2%20to%20SE%20Converter/US2%20to%20SE%20Converter.cpp#L529

Another minor bug: this calculation only works if the orbiting body's mass is <<< than the mass it orbits. I suggest to change to the full equation that would work for binaries and bodies of similar mass:

obj.semimajor = ( 1 / ((2 / obj.position.magnitude()) - (pow(obj.velocity.magnitude(), 2) / mu)) ); // as already written
semimajor_of_partner = ( 1 / ((2 / obj.parent->position.magnitude()) - (pow(obj.parent->velocity.magnitude(), 2) / MU) ) ); // calculate like above but switch parent and child (mu is not the same as MU)
obj.period = ( (2 * PI) * (sqrt( pow(obj.semimajor + semimajor_of_partner, 3) / (mu+MU) ) );

Another point about barycenters:

The print function shouldn't bother printing the following for those, since barycenters aren't real objects: Class, Radius, RotationPeriod, Obliquity, Atmosphere { Pressure, Greenhouse }

With those issues fixed, I think barycenters and binaries would work as intended...

[SethFusion]

First of all, you're totally right about printing out that extra information for barycenters. I just forgot to take it out because it doesn't affect SE negatively if it stays in. So that is an easy fix.

Second of all, give me some time to take a look at the equations you posted above. I'll need to figure them out and test them. I may not have time right now to do a full test, but if that is the change I need to get barycenters working properly, I'll thank you greatly for the help.

[Roshex]

Many thanks for the quick replies! I'll just reply to everything here and close the other issues haha! Anyway, thanks again for coming up with this tool - it's great even as is!

Anyway -

1. about the angularVelocity - in one of my sim I noticed that two bodies (a moon and planet) had some values in the x and z coords, after they converted with super low spin. It's an easy fix anyway... (the way I solved it below works)

2. the related issue of obliquity - I've only started toying around with trying to fix it using the angularVelocity - because I'm sure what the 4-vector of orientation represents... anyway, not sure if it works yet (see below)

3. I was trying to add support for moonmoons, planet+brown-dwarf binaries, moon binaries, and moon+planet binaries orbiting a binary... It resulted in a very very long list of "ifs"... So instead I came up with an alternative way to match the objects. See below - based on my systems it seems to work (just the match-up). The sort() is not necessary but finding the heaviest body is, and the rest of main() is n^2 complexity anyway so I just left the sort() there after changing the rest of main() + bond().

4. The code below is still in progress though, cause I haven't had time to adopt the new main to calcOrbit and Print fully... But I did add the orbitalPeriod correcting the binaries not orbiting at the same rate issue (although my original code in that comment was quite misleading !)

5. To sum up - I'll work on integrating it all tomorrow (for now it crashes)... Have a look if you like - I'd love some corrections! (also, I copied it directly from the .cpp so it's untidy... maybe I should fork your project instead?)

Edit: forked because the code displays bad here...

[SethFusion]

1. That's super interesting. I've looked at quite a few simulation files and I've never seen any value other than 0 for x or z under angular velocity. I wonder if I am using outdated files and US stores things differently now? Anyway, yes the fix is super simple, and the effect is the same even if there are 0's.

2. Who would have thought that obliquity would be one of the trickiest parts of math to get right... Not me when I started this. The truth is, I don't really know what the 4 numbers after orientation represent either or how to use all of them to get an obliquity. But I do know we need those to calculate obliquity because I actually asked the US devs themselves if they could help. They sent me back a bit of pseudocode, which I tried to implement but never figured out. I just don't know the math behind it enough to read the pseudocode properly. I asked them for clarification, but they never got back to me and I didn't want to bug them for a college lecture in advanced geometry. Their job is to develop US, not to teach amateurs how vectors work. I'll attach the file they sent me, and if you can get something out of it, you're a better mathematician than me (which isn't a high bar to pass haha).

3-5. You've piqued my interest in this project again, so I'll take a look at it and see what I can do. I'm not worried about time complexity since the average simulation in US has so few objects it shouldn't take more than a second to process anyway. The file I use for most testing is 4390 objects it it takes around 7 seconds to process, which is more than acceptable for a simulation that won't actually run on my computer.

Thank you for the continued interest in this project. If I have anything else to add, I'll post comments here; and as solutions are found, I'll update the main repository here as well.

obliquity.txt

[SethFusion]

Okay so I've looked through your changes a bit. I made a few small changes just to get the code running and viewable in SE with the output files. I would have pushed them on your forked repository, but I don't have access to do that, so instead the .cpp is attached here: US2 to SE Converter.txt (Just change the extension from .txt to .cpp. Sorry to do it this way, I'm still learning my way around Github.)

The major changes are 1) the way the root is found. You had the line root = object.at(0).parent; before any objects were given parents yet, so root was always NULL. I fixed that after the main for loop. That was one reason the code wouldn't run correctly, and attractor and neighbor weren't being initialized to NULL (which the compiler didn't like).

And 2), the system wouldn't be rendered in SE if a star has an invalid obliquity printed, so I cleaned up the print function to make stars and barycenters look better.

With those changes, it runs, but it still needs work. I noticed a few objects would never find a parent by the end (and so would never get printed), and a lot of minor moons would lose their parent altogether and just orbit the parent star. When testing for the Earth and the Moon, it didn't seem to pick up their relationship properly. Some other binary planet systems worked, and others still didn't. It was super limited testing and you know your code better than I do, so keep at it if you want.

[Roshex]

Thanks a lot for cleaning up the code! Could convert my simulations and check the issues directly... Also, yes you are right! Should have remembered to initialize those pointers lol I'll put this version on the fork - how do I let push to mine? I'm very new to github and really only joined for this tool...

Based one what I checked now, those are fixed:

1. moon-moons
2. moons distant from gas giants (for some reason didn't work before)
3. jupiter-dwarf sun binaries
4. orbital period of binaries is equal
5. angular velocity fixed on the very few bodies were it was wrong:

Checked again my biggest sim - it was wrong on two planets, closest to a binary sun, one of them with a Moon-like moon. Those are the coords:

"Orientation":"0.03724333;0.08753189;-0.2865362;0.6380199", "AngularVelocity":"-1.46215526797278E-07;-3.01416662296106E-07;6.69846770051663E-07", "Position":"-144282394538397;57868559574049;117395747379242", "Velocity":"49274.5624400694;93.7742866468323;-68470.4761819415",

"Orientation":"0.3097987;0.1791168;0.1543991;0.7660354", "AngularVelocity":"3.19526589009911E-06;-4.41716547356918E-05;-3.01673617286724E-06", "Position":"-144195033544630;57868559513823.9;117482056559992", "Velocity":"-41545.2192346601;94.1024493692539;36907.157167731",

Still buggy:

1. I also have no clue how the orientation works - will have to give it an in depth look later... Although it's pretty awesome that you got some explanation from the devs. I don't even get why it has 4 components instead of 3...
2. Moon-like moons are now broken... A new bug... It should be an easy fix because they are identified as a barycenter. But the barycenter doesn't seem linked to them. Maybe there's a children count issue? Or the parent / partner are wrong? I'll have a look...
3. Haven't fully checked binaries yet, but at least one circumbinary planet doesn't even show up - with your version it wasn't even converted, with this version it's converted twice. End result is the same because SE ignores two of the same object. Not sure why it behaves differently...

Edit: fixed issues 2 and 3.5 (missing objects), as well as frags and added recursive binaries. Only tilt and some bad binary orbit numbers are left now ;)

[Roshex]

Hey,

So I decided to give the converter another look today to fix the type identifications. Ended up fixing another bug in my Bond function I missed before and some other changes. Feel free to correct any new issues I might have introduced if you notice them LOL

I came across this tool via a forum post, don't remember which, but there was the .exe there. Might be a good idea to update it, even though some issues remain (obliquity, some binary orbit math, some class math, +newly discovered issues of Trojans).

[SethFusion]

Sorry for the long absence. Had a lot happen in the last few weeks, including classes starting back up now. I only want to push this to the public if I am happy with the result, so give me a bit of time to do some testing myself and I'll update the forum post.

Again, thanks for your help. If I notice anything buggy or strange I'll be sure to let you know. Hopefully, obliquity and weird binary orbits can be fixed in the future if I can recruit some help from my professors.

[Roshex]

No worries! I also only returned to this program a couple of days ago when I realized I never checked trojan objects before and decided to also fix the types. Several minute ago I uploaded what I have so far -

1. Obliquity - figured out that the 4-vector has to be an orientation quaternion (kind of obvious in retrospect). If this is true, it should be possible to convert those to the 3 Euler angles, which depending on the order of rotation and how you pick the axis, are: precession (arg. of obliquity), obliquity, and self-rotation angle (yaw in US2). However, I'm clearly doing something wrong with those angles because the values are still wrong... Maybe you'll have more luck...

2. Trojans - after some fixes they work when you load the files up. However, over time, the 60 deg angle between the primary planet and trojan is not maintained, and they "phase" thru eachother. In reality, trojans do a U-turn when approaching too close to the primary (in tadpole and horseshoe orbits), but I don't think SE supports this... Other than that "minor" phasing issue, they are working.

3. Binary orbits - semi-major axis and period seem to work fine. The problem seems to be with eccentricity, but I don't know why. All my binaries look wayyy to eccentric, and even converting real systems looks wrong. For example - the sextuple star Castor (alpha Gem) when converted results in hyperbolic orbits (although the hierarchy is right!). Haven't had the time to look into it further haha.

Anyway, I think I'll take a break now and let you take a look at what I changed so far (take your time). Thanks again for not losing interest in this! I know I'm rather late to the party 😅

[Roshex]

Thanks for the invitation! All the conflicts seem fixed, so I merged them...