Eric Stoneking

Hi Richard, Thanks for the bug report. Please insert a call to BodyStatesToNodeStates in OrderNMultiBodyRK4 (like in KaneNBodyRK4) and see if that fixes the issue. It should, but I don't have time to test it properly right now. The refactoring of nodes postdates the inclusion of Order-N dynamics, and I missed adding that. Regards, -Eric

Hi Javier, Sorry about the belated response. I don't monitor this page, and somehow your message didn't get forwarded to my email. To your question. I recommend that you download the latest version, and read "Docs/Using Standalone AcApp/Using Standalone AcApp.txt". To give away the ending, 42 can talk over sockets. If you can get Simulink to talk over a socket (and I suspect you can), then you can set up exactly the architecture you describe. Regards, -Eric

Hi Charles, For Earth-centric problems, I have the conversions from True-Equator-True-Equinox (TETE) and True-Equator-Mean-Equinox (TEME) to J2000 in HiFiEarthPrecNute. I have conversions from ECEF to WGS84 and back. As noted in 42 Overiew.pdf, planet positions use ephemerides from Meeus, with no conversion for reference frame creep, so the implied assumption is that those are their TOD positions. Beyond that, the best answer is that if the distinction matters to you, then you might want to bring...

Real Time Simulation Speed

Terms retained in the equations for flexible bodies

Mac Installation

Reaction Wheel Crash (Windows)

Hi Peter, You are correct. The application I was writing for at the time wasn't sensitive to clock drift, so I wasn't very careful about it. Here's one way to keep the clock from drifting: In 42exec.c:AdvanceTime(), replace the usleep call with: while(CurrTick == PrevTick) { CurrTick = (long) (1.0E-6*usec()/DTSIM); } PrevTick = CurrTick; with PrevTick and CurrTick defined as: static long PrevTick = 0; static long CurrTick = 1; (I already had a usec() function, so this is a more modest change than...