[0.23] Alternis Kerbol - Release thread - [v0.1, Jan. 3] (development halted)

[cttw]

Hi, I am trying to use this mod and I am not sure what I am doing wrong but it changes nothing. I put the right folder in gamedata, I see the menu on startup and enable the mod and click apply, but then I start a new game, and the map view and tracking station views show the same old kerbal system. No errors are displayed.

[hrhtml99]

Looks amazing Nova! You continue to impress me! Good work!

[restordoc]

If I am in a high Bop orbit I seem to lag a lot but not in map view.

I've noticed that the texture for Bop switches to a darker one when one gets close to it. The lag seems to come from the gradual switch from one texture to another that starts in a high orbit. I don't know if this texture switching happens in the stock game, since I've never been to Bop in it.

[NathanKell]

It's not switching textures, it's switching from the scaledspace model to the PQS (the procedural terrain). That's true for all CBs except Jool (which doesn't have a PQS).

[restordoc]

Oh, I see. Well, the switching from scaledspace to PQS is lagging the game considerably.

[Hotblack Desiato]

I accidentally sent jeb on an escape trajectory out of the kerbol-system (close encounter with laythe, and that shot him out there).

but when he changed from jool-SOI to sun-SOI, the craft started to rotate at high (1000x) warp, the rotation was proportional to the warp-factor.

when I switched to KSC and then back to jebs ship, the rotation stopped, it works just fine again.

(sadly, I use TAC life support, and he has food/water/air for just another 220 days).

[NovaSilisko]

It's not switching textures, it's switching from the scaledspace model to the PQS (the procedural terrain). That's true for all CBs except Jool (which doesn't have a PQS).

I get the opposite sometimes. Periodically when leaving Kerbin's SOI into Jool orbit, I get a ton of FPS issues... a quicksave and quickload usually fixes it, though.

No idea about the rotation thing, Hotblack. Dunno anything I've done that could possibly do that... How much rotation was it? Could it have been a side effect of perhaps having free camera mode on the sun?

[NathanKell]

When PQS is unloaded, there's a LOT of stuff to be freed by the next garbage collection pass.

[eggrobin]

Hooray! I went ahead and did an n-body simulation of the updated system, but so far only the case where Bop is still a moon of Jool. This time around, Mun gets ejected very quickly, by about 1.5 Ms (illustrated here: http://youtu.be/aGvYWqj7dfk ) Pol gets ejected later, around 560 Ms (animation to come). But after that, I ran the simulation out to 3 Gs and saw no other changes.

It turns out to be very stable! (at least through 100 years) You put it into a low enough orbit around Kerbin that I think it would take another body passing by pretty closely to do much to it.

I switched to doing the simulation using a fifth order symplectic integrator (coefficients from The accuracy of symplectic integrators, Robert I. McLachlan and Pau Atela (1992)) that I just wrote in C#: it's faster, 1 year in 149 s with a 10 s timestep, and it's symplectic, which can't be a bad thing.

Below are some results from a 1-year simulation with a constant 1 s time step, downsampled to 100 s for plotting due to memory usage.

The Mun hasn't quite escaped, as seen from the kinetic energy plot, but is well on its way.

The Mun's trajectory is highly chaotic: in a previous simulation where I encountered some issues with the sun (my integrator doesn't like stuff that has velocities/positions close to 0), the Mun made a close Kerbin encounter (certainly below the Roche limit, probably a collision). While Boepli (this is what I called the small version of Bop) had its inclination significantly altered (last picture in the album), it fared pretty well despite the close encounter with such a large body. Similar conclusions hold for the 5t satellite in equatorial circular 100km Kerbin orbit that NovaSilisko asked me to add to the simulation. It seems Kerbin orbit is a very safe place.

Javascript is disabled. View full album

Finding a configuration for the Jool system that makes the Mun more stable would be an interesting exercise.

Edited January 6, 2014 by eggrobin

[Hotblack Desiato]

I get the opposite sometimes. Periodically when leaving Kerbin's SOI into Jool orbit, I get a ton of FPS issues... a quicksave and quickload usually fixes it, though.

No idea about the rotation thing, Hotblack. Dunno anything I've done that could possibly do that... How much rotation was it? Could it have been a side effect of perhaps having free camera mode on the sun?

approximately one revolution per two second at 10000x timewarp. so it was quite slow. at lower timewarp, it was basically not visible.

[lantay77]

Hooray! I went ahead and did an n-body simulation of the updated system, but so far only the case where Bop is still a moon of Jool. This time around, Mun gets ejected very quickly, by about 1.5 Ms (illustrated here: http://youtu.be/aGvYWqj7dfk ) Pol gets ejected later, around 560 Ms (animation to come). But after that, I ran the simulation out to 3 Gs and saw no other changes.

Did you write your own program to do these simulations? They are awesome.

[NovaSilisko]

Making the ambient and sun light mod now. It will work off a preset system. Fairly minimalist normally, unless you enable the editor. Just a text box and a button to load the preset. When in-game, you can hit a hotkey to open up an editor GUI to play with values. Not made the GUI yet though, just working on the preset load/save options. Also, Alternis will have its own lightshifter embedded by default, but it can be disabled with the same options screen it uses to configure other stuff.

Edited January 6, 2014 by NovaSilisko

[Mattasmack]

I switched to doing the simulation using a fifth order symplectic integrator (coefficients from The accuracy of symplectic integrators, Robert I. McLachlan and Pau Atela (1992)) that I just wrote in C#: it's faster, 1 year in 149 s with a 10 s timestep, and it's symplectic, which can't be a bad thing.

Below are some results from a 1-year simulation with a constant 1 s time step, downsampled to 100 s for plotting due to memory usage.

Very nice! I commend you for your decision to go your own way -- as you've already found, writing your own program specially to solve a particular problem usually gives you much better performance than very-general-purpose software. Plus, you become intimately familiar with the numerical method being used and better able to judge when its results are reliable.

Your relative errors look to be between one and two orders of magnitude lower than mine. And I can't make mine much smaller by adjusting the time step size; they seem to bottom out at around 10^-14 - 10^-13 regardless of the step size or local error limits I set. So I would say you've made a good choice of integrator to use.

The Mun hasn't quite escaped, as seen from the kinetic energy plot, but is well on its way.

Which version of the Alternis system are you showing here? A number of bodies changed from v0.0 to v0.1.

...

Finding a configuration for the Jool system that makes the Mun more stable would be an interesting exercise.

I think a good first step would be to not put it in a resonant orbit with Kerbin and Laythe!

[Mattasmack]

Did you write your own program to do these simulations? They are awesome.

Yes, thanks! And, I've just cleaned it up to make it publicly available: https://www.dropbox.com/s/39mi6hqq3ve73vt/MLROrbit-v0_1.zip . It's a command-line program, not interactive at all. To make the animations, I use the .m files included in that zip file to read the results into Octave and generate a series of plots to be frames for the animation. Then Gimp and it's animation plugin (GAP) to crop them to the proper size, then ffmpeg to encode them into a movie. I am halfway tempted to put code in the simulator itself to generate the frames directly, but it sounds like a pain and I'm not frustrated enough by the Octave->Gimp->ffmpeg process yet to do it.

Included in that zip file are input files for simulating Alternis Kerbol versions 0.0 and 0.1a and 0.1b. I call 0.1a the version with Bop a moon of Jool and 0.1b the version with Bop as a moonlet of Kerbin.

[Zeggpold]

Hi, I am trying to use this mod and I am not sure what I am doing wrong but it changes nothing. I put the right folder in gamedata, I see the menu on startup and enable the mod and click apply, but then I start a new game, and the map view and tracking station views show the same old kerbal system. No errors are displayed.

I had the same problem here, running on Linux. Looking though the log files, I found this suspicious looking line:

[EXC 22:52:45.984] IsolatedStorageException: Could not find a part of the path "/home/player/GameData/AlternisKerbol/PluginData/Heightmaps/tylo_newheight.png".

This is the wrong directory (the file is in the appropriate KSP_linux/GameData/... directory). Some the other textures load correctly, so it looks like the tylo_newheight.png is being loaded differently from the others, and looking at the source I see that it and some other textures are loaded with System.IO.File.ReadAllBytes. And indeed, if I run KSP directly from the KSP_linux directory, everything works. Not sure if that has anything to do with your problem, but I thought I'd mention it.

[NovaSilisko]

Well, what's different about the heightmaps is they're loaded using System.IO as opposed to GameDatabase. I guess something about that doesn't work on linux... (cttw, are you on linux too?)

[cttw]

Yes I am on Linux too.

[cttw]

Also it seems running it from the KSP_linux folder does not work for me or I am doing something subtly wrong. I start KSP with this script

#!/bin/bash

cd /home/username/games/KSP/23/KSP_linux/

./KSP.x86_64

cd -

[eggrobin]

Very nice! I commend you for your decision to go your own way -- as you've already found, writing your own program specially to solve a particular problem usually gives you much better performance than very-general-purpose software. Plus, you become intimately familiar with the numerical method being used and better able to judge when its results are reliable.

Yes, and for once, I have a reason to write an integrator (something that was severely lacking from my Numerical Mathematics courses).

Your relative errors look to be between one and two orders of magnitude lower than mine. And I can't make mine much smaller by adjusting the time step size; they seem to bottom out at around 10^-14 - 10^-13 regardless of the step size or local error limits I set. So I would say you've made a good choice of integrator to use.

How do you deal with the accumulation of unit roundoffs? On this kind of number of steps, this can become very significant... I use simple compensated summation when accumulating the steps, but not within the actual Runge Kutta stages. Depending on your number of steps, perhaps doubly compensated summation might be worthwile. I'm very worried about the outliers in the errors in H, p and L though (bear in mind that this is sampled down by a factor of 100, so there are probably more of those). I suspect something is coming to close to 0, though I'm not sure why my integrator goes mad in those circumstances.

Which version of the Alternis system are you showing here? A number of bodies changed from v0.0 to v0.1.

This is v0.1, with an added satellite and both Bop and Boepli. Again, the Mun's trajectory is highly chaotic, it changes significantly over a year between a 10s and a 1s time step, so I'm not sure much can be deduced from that.

I think a good first step would be to not put it in a resonant orbit with Kerbin and Laythe!

I think the intent was to replicate the Io-Europa-Ganymede resonance, but that would probably help.

Edited January 6, 2014 by eggrobin

[Motokid600]

Any update on the stand alone lighting?

[eggrobin]

Yes, thanks! And, I've just cleaned it up to make it publicly available: https://www.dropbox.com/s/39mi6hqq3ve73vt/MLROrbit-v0_1.zip .

I just looked through your code and unless I'm missing something it doesn't seem like you're implementing compensated summation. That means you'll get a very significant accumulation of unit roundoffs, which would explain the higher errors. I would suggest taking a look at http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html#1464293172 (this article is about SPRK methods, but it can also be applied to your integrator; basically, you run your Runge-Kutta step to compute the increments instead of the actual state, and you use compensated summation to add up the increments). There are also a few places where you could shave off an unit roundoff or two, e.g.,

      r = 1.0/(dx*dx + dy*dy + dz*dz);
      r *= sqrt(r);
      tmp = sys[j].mu*r;
// Could be:
      r = (dx*dx + dy*dy + dz*dz);
      r *= sqrt(r);
      tmp = sys[j].mu/r;
// That will cost you a division, as you also do that with sys[i], but you gain an unit roundoff by doing a division instead of an inversion followed by a multiplication.

but this is minor.

In my simulation over 10 years with a constant 1 s time step (downsampled to 1 ks for plotting), Minmus and Pol escape (Boepli and the satellite are still happily watching the show in highly stable orbits). I'm not sure simulations make much sense with such a chaotic Mun though.

I looked at the positions and velocities when I get outliers in H, p and L, and they don't seem to be near 0. I have no idea where these outliers are coming from...

There are some close Kerbin approaches by the Mun and Pol. I think the closest Mun approach is either a collision or a Mun-shattering encounter: the closest distance I have is 1351 km center-to-center, which is above the Roche limit of 921 km, but I only sample every 1 ks, so the distances at the datapoints either side of the minimum are 2360 km and 2480 km. A collision is well within the uncertainty.

Javascript is disabled. View full album

[NovaSilisko]

Any update on the stand alone lighting?

Watching SpaceX launch, work will resume after that

[Mattasmack]

I just looked through your code and unless I'm missing something it doesn't seem like you're implementing compensated summation. That means you'll get a very significant accumulation of unit roundoffs, which would explain the higher errors. I would suggest taking a look at http://reference.wolfram.com/mathematica/tutorial/NDSolveSPRK.html#1464293172 (this article is about SPRK methods, but it can also be applied to your integrator; basically, you run your Runge-Kutta step to compute the increments instead of the actual state, and you use compensated summation to add up the increments).

Correct, I don't have any roundoff compensation. I wrote this code initially to simulate ships moving around the KSP solar system with the planets still on rails. 'Common wisdom' on the forum was that this was too computationally intensive to do in the game, and I wanted to put that to the test. So, my focus was on speed and large time steps (so that trajectories could be pre-calculated and then stored), and accuracy just had to be good enough to not produce obviously wrong results in the game. Now I'm using it for something else and these little errors that didn't matter before ... start to matter. If I do much more with this code I will definitely look into roundoff compensation, but I don't know if there is enough interest to justify spending much time on it. I'd had a few requests for the code, but now that it's released I doubt more than 5 or 10 people will care.

[NovaSilisko]

Lighting mod now loading values properly, woo

So that makes it saving and loading correctly. Next up: sun lens flare color, then loader GUI, then editor GUI

[team.leit]

Lighting mod now loading values properly, woo

http://i.imgur.com/jf2Edgd.png

So that makes it saving and loading correctly. Next up: sun lens flare color, then loader GUI, then editor GUI

Nice choice of colors, but I think it proves your point