raptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fréchet. We currently target 1.5.1, 1.6.1, and 1.7.x. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly… | <egg> also 4e16 m * 2^-52 is uncomfortably large
<_whitenotifier-d13c> [Principia] Vannadin opened issue #2447: i have planet texture issue with your mod. - https://git.io/JvUYE
<_whitenotifier-d13c> [Principia] Vannadin edited issue #2447: i have planet texture issue with your mod. - https://git.io/JvUYE
egg|laptop|egg has quit [Remote host closed the connection]
egg|cell|egg has quit [Ping timeout: 190 seconds]
Mike` has quit [Ping timeout: 189 seconds]
Mike` has joined #principia
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Ping timeout: 198 seconds]
<_whitenotifier-d13c> [Principia] pleroy synchronize pull request #2446: Fix more Clang warnings - https://git.io/JvUT6
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4091/
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4091/
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord-> S​ir Mortimer. — @egg I found a slightly better formula for calculating the shadow period for vessels orbiting a body: https://wiki.kerbalspaceprogram.com/wiki/Orbit_darkness_time
<discord-> S​ir Mortimer. — it still is very stupid (it always returns the worst case) but at least it works with elliptical orbits and will return consistent results, no matter when we happen to do the calculation
<discord-> S​ir Mortimer. — and of course its even wronger with n-body shenanigans.
<discord-> e​gg. — when it gets to sufficiently-n-body shenanigans you can only look at the history and compute the shadow time in the dumb way like that
<discord-> e​gg. — if it's perturbed Keplerian you can probably fudge something, but is it worth the hassle?
<discord-> e​gg. — (since perturbed Keplerian only happens with Principia, which knows history anyway)
<discord-> S​ir Mortimer. — well, for our purposes it doesn't have to be very exact. we just need something that tells us if the vessel will run out of electricity eventually.
<discord-> e​gg. — I don't have complete context on what the ultimate goal is here
<discord-> e​gg. — also I should probably go to work
<discord-> e​gg. — brb from phone on tram probably
<discord-> S​ir Mortimer. — so should I, but who cares 😛
egg|laptop|egg has quit [Remote host closed the connection]
<discord-> S​ir Mortimer. — context: when timewarping very fast (hours of simulator time per tick), we average sun exposure time vs. orbital period to get a factor. that factor is used to calculate the EC output of solar panels, and some other stuff (f.i. power requirements for habitat climatization and solar radiation).
<discord-> S​ir Mortimer. —
<discord-> S​ir Mortimer. — currently we assume a circular equatorial orbit at whichever altitude the vessel happens to be at when we calculate.
egg|cell|egg has joined #principia
<discord-> S​ir Mortimer. — now I found this, which gives consistent results (it doesn't use current altitude), and now I'm thinking about how this could be improved to estimate solar exposure for elliptical orbits with inclinded apsides, like Молния orbits.
<discord-> e​gg. — @Sir Mortimer right so just estimating the fraction of the time that the craft spends in the dark doesn't work, because you care about how long the stretches of darkness get?
<discord-> B​utcher. — What if you're in a Heliosynchronous orbit?
<discord-> e​gg. — @Sir Mortimer i.e. my question is why doesn't sampling work
<discord-> e​gg. — At every frame, don't do smart stuff, see if you're in the dark, and in the long run you would get an estimate of the percentage of time that you spend in the shade
<discord-> e​gg. — You wouldn't directly get the length of the stretches of shade of course, tough you could deduce that with the assumption that the period stays constant
<discord-> S​ir Mortimer. — stretches of darkness are irrelevant for now (ideally they wouldn't be, but currently they are).
<discord-> S​ir Mortimer. —
<discord-> S​ir Mortimer. — taking a sample every frame is fine until you encounter an orbital period of 59 minutes and a sampling interval of 60.
<discord-> B​utcher. — I assume the problem is at 6 million warp you might haen to hit always in sun / shade erroneously.
<discord-> B​utcher. — I assume the problem is at 6 million warp you might hapen to hit always in sun / shade erroneously. (edited)
<discord-> B​utcher. — I assume the problem is at 6 million warp you might happen to hit always in sun / shade erroneously. (edited)
<discord-> e​gg. — @Butcher that only matters if you have a correlation like @Sir Mortimer suggests
<discord-> S​ir Mortimer. — say you're in shadow for 20 minutes of the 59. this means that kerbalism will see a shadow period of 20 *orbits* = 20 hours. the kerbals are dead by the time this corrects itself.
<discord-> e​gg. — @Sir Mortimer ah but that's not what I suggest
<discord-> B​utcher. — Force everyone to get Principia and check history. 😉
<discord-> S​ir Mortimer. — @Butcher is there an API for that? 🙂
<discord-> e​gg. — What I suggest is that you don't compute shadow periods
<discord-> e​gg. — Just shadow rates
<discord-> e​gg. — Though I guess here in your correlated case the rate will drift annoyingly
<discord-> e​gg. — Hmmm.
<discord-> S​ir Mortimer. — > At every frame, don't do smart stuff, see if you're in the dark
<discord-> S​ir Mortimer. —
<discord-> S​ir Mortimer. — same problem. when the above constellation happens at the time when I *begin* looking at the craft and taking averages.
<discord-> e​gg. — Yeah you need to keep error bars
<discord-> e​gg. — So you're doing no checking initially
<discord-> e​gg. — Hm
<discord-> e​gg. — This gets dirty
<discord-> S​ir Mortimer. — it can be. as said, I don't need the stretches of darkness, and it can be a rough estimation.
<discord-> e​gg. — Meeting now, back in an hour
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
<discord-> B​utcher. — @Sir Mortimer No idea.
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 200 seconds]
egg|cell|egg has joined #principia
<discord-> S​ir Mortimer. — *thinking about uranus axial tilt*
<discord-> D​amien. — imagine uranus being tilted
<discord-> S​ir Mortimer. — The horror!
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 202 seconds]
egg|cell|egg has joined #principia
mofh_ has quit [Ping timeout: 190 seconds]
mofh_ has joined #principia
Iskierka has quit [Ping timeout: 204 seconds]
Iskierka has joined #principia
<discord-> D​RVeyl. — I can chat more about it tonight. But outside of principia, you have access to the Orbit object. Why make assumptions, you can step through it at whatever time resolution you require. (Don't care if the vessel spends less than 5% of time in darkness? Step 1/20th of orbit period). Test 20 points per frame.
<discord-> D​RVeyl. —
<discord-> D​RVeyl. — With principia, you still have predicted path, correct? Can you use the new mean elements to help here? Can you also determine a required sampling rate?
<discord-> D​RVeyl. — Does it help to break the problem into 3 cases: warp step << period, warp step >> period, warp step ~= period?
<discord-> D​amien. — is there that much of a difference in shadow time when comparing principia to patched conic orbits?
egg|cell|egg has quit [Ping timeout: 202 seconds]
egg|cell|egg has joined #principia
<discord-> e​gg. — @DRVeyl I mean, in the Keplerian case, there might also be an analytic solution which would feel cleaner than stepping along the orbit
<discord-> e​gg. — but it would be really nice if one could devise a Principia-agnostic solution
<discord-> e​gg. — but then you can't depend on the vessel being on the trajectory described by the Orbit, which makes things tricky
<discord-> S​ir Mortimer. — stepping is a lot more cpu intensive, tho.
<discord-> S​ir Mortimer. — but that doesn't really matter all that much, because we don't have to do that every frame. when we need the info, do it only once, store the result for a while. and then do it again, maybe when the planet did 1/10th of its orbit around the sun.
<discord-> S​ir Mortimer. — I like that idea.
<discord-> e​gg. — @Sir Mortimer but then you're back to weird discretization effects, from the choice of the value of 1/10
<discord-> e​gg. — and you still have to special-case Principia quite a lot, because there the orbit varies continuously
<discord-> e​gg. — and it can precess fast
<discord-> e​gg. — (see also the question of heliosynch orbits)
<discord-> S​ir Mortimer. — what's the alternative? keeping a list of past sampling points, one orbital period worth, and using that?
<discord-> e​gg. — ideally you'd want to randomize the timewarp timestep :-p
<discord-> e​gg. — that way you don't have pesky correlations
<discord-> e​gg. — but that's probably a bit too intrusive
<discord-> e​gg. — alternatively, *handwave handwave* Fourier *handwave*
<discord-> S​ir Mortimer. — ```
<discord-> S​ir Mortimer. — if(samples is empty) samples = 30 points during orbit period, taken from the keplarian orbit;
<discord-> S​ir Mortimer. — if(not on ridiculous timewarp) samples.add(sun visible from where I am now? yes : no)
<discord-> S​ir Mortimer. — sunFactor = count of yes / total samples;
<discord-> S​ir Mortimer. — ```
<discord-> e​gg. — @Sir Mortimer you can't do anything with sampling if you don't somehow control the error bars though...
<discord-> D​amien. — my cat has learned to push the esc button with his head to be annoying
<discord-> S​ir Mortimer. — @egg yeah. time warp will mess it up.
<discord-> s​iimav. — Soon it will learn how to alt+f4
<discord-> e​gg. — well yes, this is what makes it interesting :-)
<discord-> e​gg. — without timewarp everything is trivial
<discord-> e​gg. — there is a dog in the office sleeping next to my chair
<discord-> S​ir Mortimer. — @egg am i right to assume that principia will force the KSP vessel orbit to be something close to what principia thinks is a good enough approximated keplarian orbit to the spaghetti noodle that it really should be?
<discord-> S​ir Mortimer. — that sentence is a bit mixed up
<discord-> S​ir Mortimer. — but you get the drift+
<discord-> S​ir Mortimer. — but you get the drift (edited)
<discord-> e​gg. — The KSP orbit will have the correct speed and position at the present
<discord-> S​ir Mortimer. — there's a dog sleeping in the office downstairs from mine
<discord-> e​gg. — but for the second derivative, *This International Standard imposes no constraints*
<discord-> S​ir Mortimer. — stupid mutt decided it's a good idea to jump 5m down onto a big rock.
<discord-> e​gg. — ow
<discord-> S​ir Mortimer. — so the KSP orbit will be... well. close enough™
<discord-> B​utcher. — I use the KSP orbit for some planning stuff while using Principia. It gives a reasonable approximation, as long as you don't want metre precision.
<discord-> e​gg. — it really depends how you use it and for how long
<discord-> e​gg. — @Sir Mortimer again, it's the usual issue
<discord-> e​gg. — it works if you don't warp fast
<discord-> e​gg. — but you *absolutely cannot* use it for fast warp
<discord-> B​utcher. — I can hit the Moon to within a quarter radius or so using Keplerian elements, so that's close enough for me. 😉
<discord-> e​gg. — that is a very short trajectory
<discord-> e​gg. — long-term orbits precess
<discord-> B​utcher. — True!
<discord-> e​gg. — and then you have weakly bound orbits
<discord-> e​gg. — with Principia I see only two options: talk to Principia, or figure out a way to do sampling
<discord-> e​gg. — maybe a third one if you want to develop your own analytic model but then you're reinventing the principia...
<discord-> B​utcher. — Is there a way to get prediction numbers out of Principia at the moment?
<discord-> e​gg. — so there really is an advantage to doing it by sampling somehow
<discord-> e​gg. — because then you kill two birds with one cat
<discord-> D​amien. — *reinventing the principia*
<discord-> D​amien. — principia competitor when
<discord-> B​utcher. — Like an API for "what is the predicted position for vessel V and time T"
<discord-> e​gg. — @Butcher API design is hard, and transmitting lots of data between the two is going to be slow and brittle
<discord-> e​gg. — if you're going to do that sort of stuff you want to have most of the work done in Principia
<discord-> e​gg. — so things like "longest time in the shade between t1 and t2"
<discord-> S​ir Mortimer. — so. let's assume a fast warp speed. with principia or without, at any given frame I take the KSP orbit, predict ~30 positions along the orbit distributed over one full orbital period, check for sun visibility at those positions and then use that value for no longer than one or two orbital periods, before I recalculate. rinse and repeat.
<discord-> S​ir Mortimer. — I think something like that should be good enough, however it is computational intensive (raytracing 30 points every frame, not fun)
<discord-> B​utcher. — @egg Yes, but I was thinking in the more general case.
<discord-> e​gg. — yes, but no; if you try to do that, you just get an API that is bad ofor everyone
<discord-> e​gg. — yes, but no; if you try to do that, you just get an API that is bad for everyone (edited)
<discord-> e​gg. — exchanging lots of data through individual calls to Principia is a really bad idea
<discord-> B​utcher. — Things like, "where will my ship be in time T" or "when is the earliest time that my orbit is within some bounds (like say within the radius of a planet).
<discord-> e​gg. — those two are not the same kind of API at all
<discord-> B​utcher. — How are they not?
<discord-> e​gg. — One of those makes Principia do the work
<discord-> e​gg. — the other one is directly evaluating a polynomial, and then you'll do *something* with it
<discord-> e​gg. — and if that *something* is nontrivial, you're not going to have a good time
<discord-> S​ir Mortimer. — maybe i can trust that value for longer than that. if the orbit doesn't precess.
<discord-> e​gg. — anyway, back to Sir Mortimer's questions
<discord-> e​gg. — @Sir Mortimer there are a lot of nasty assumptions in there
<discord-> e​gg. — orbital periods being meaningful, this timescale of 2 orbital periods, these 30 points
<discord-> e​gg. — that's going to break on precessing orbits, on WSB orbits, etc.
<discord-> S​ir Mortimer. — well, my main advantage is that the result doesn't have to be very accurate. i don't care if it is 0.43 or 0.45, i care if it is 0.3 or 0.6
<discord-> e​gg. — yeah, but precisely, given that you have this allowance for fuzziness, we should be able to use it to have a simple solution
<discord-> e​gg. — trying to get some work done now, will poke at it tonight
<discord-> S​ir Mortimer. — I don't know how I could be sampling sun visibilities any other way tbh. I have to use the KSP orbit, and I have to do it to predict about a day worth
<discord-> S​ir Mortimer. — (kerbin day, 6 hours)
<discord-> S​ir Mortimer. — otoh I don't really care if it is wrong for a day or two. it just shouldn't be wrong enough for people to notice.
<discord-> S​ir Mortimer. — and you don't notice a 2 day error when warping at 10.000x
<discord-> e​gg. — @Sir Mortimer
<discord-> e​gg. — > I have to use the KSP orbit
<discord-> e​gg. — No, that's one way to do it, but it's not the only possible way
<discord-> e​gg. — you don't really care about a continuousish 1-day interval if what you want is just an estimate of the shadow rate
<discord-> e​gg. — if you want to know the duration of the stretches in the dark, it's a different problem entirely, and there you can't escape an analytic model (or a search through each revolution, or a query to Principia, etc.).
<discord-> e​gg. — but for estimating the darkness rate, even that hypothetical sampling every 59 min on a 60 min orbit will converge; the question is how to estimate how good the approximation is
<discord-> B​utcher. — @egg So which one is the "good" kind of API?
<discord-> e​gg. — the kind that answers the ultimate question that you want to ask (provided that it's a reasonable question), doing the work within Principia; because then it can know about the Principia data structures to do its work better than you could outside, and it doesn't constrain the evolution of our API
<discord-> e​gg. — imagine an API that asks for a degree 3 polynomial that locally approximates the trajectory of the vessel, so the caller can evaluate it in a neighbourhood of where the vessel is; that would be trivial to implement right now (it's our internal representation), but really bad, because if/when we change our internal representation, we would still need to compute the old thing for that API---even though
<discord-> B​utcher. — So asking, "when does my orbit intersect the planet?" is a reasonable question then...
<discord-> e​gg. — yeah, but that one we don't know how to answer yet :-p
<discord-> e​gg. — (I can tell you that if the planet is a sphere but that's not super useful)
<discord-> B​utcher. — Ok, how about asking when does it cross the planet radius (or some specific distance from the planet centre).
<discord-> e​gg. — yeah, that sort of thing is possible
<discord-> e​gg. — note the *yet* in
<discord-> e​gg. — > we don't know how to answer yet :-p
<discord-> e​gg. — We want to do something about that eventually
<discord-> e​gg. — because showing you where you will splat is useful
<discord-> e​gg. — this has not escaped our attention
<discord-> B​utcher. — Also, time to next apside should be reasonable?
<discord-> e​gg. — time to next apsis with respect to the given body, sure
<discord-> B​utcher. — Yeah, I have noticed that the current impact markers are a little flaky.
<discord-> e​gg. — yeah they're at the periapsis
<discord-> e​gg. — if the periapsis is underground they say "that is probably bad news"
<discord-> B​utcher. — Ahh. So you just check if pe < body_radius?
<discord-> e​gg. — yeah, in the C# layer
<discord-> B​utcher. — Makes sense.
<discord-> e​gg. — I actually have a feature request to show the next apsis in a window
<discord-> B​utcher. — That's why the Earth ones are crazy when you're ascending to orbit for instance.
<discord-> e​gg. — yup
<discord-> B​utcher. — I'd like an API for some of these, so I can hook them in kOS. 😉
<discord-> B​utcher. — I just rely on Keplerian elements for things like apsis eta, which is not accurate.
<discord-> e​gg. — yeah, J2 is a thing
<discord-> e​gg. — though, beware
<discord-> e​gg. — once you have those, will they be what you want?
<discord-> e​gg. — low-eccentricity orbits have 4 apsides around Earth
<discord-> e​gg. — is that what you want :D
<discord-> B​utcher. — I just want to know when the next one is usually.
<discord-> e​gg. — (and those apsides are useless to compute a meaningful semimajor axis or eccentricity)
<discord-> B​utcher. — For simple manoeuvre planning. For anything complex I can use the flight planner.
<discord-> e​gg. — yeah true
<discord-> e​gg. — also the orbit analyser
<discord-> B​utcher. — Also that. Speaking of, min / max distance from central body would be useful in that.
<discord-> B​utcher. — A lot of contracts are "maintain Pe > D" for some D, knowing if your rbit is going to satisfy that from analyis would be handy.
<discord-> e​gg. — I am going to completely ignore any arguments from contracts :-p
<discord-> B​utcher. — 😢
<discord-> B​utcher. — So mean.
<discord-> e​gg. — the contracts are bad, and should feel bad, and have requirements that make no sense
<discord-> B​utcher. — On the subject of manoeuvres, I should probably dig out that kOS Principia API stuff.
<discord-> e​gg. — now, knowing that you won't dip into the atmosphere, or the ground, that's useful
<discord-> e​gg. — so min altitude definitely makes sense
<discord-> e​gg. — max is less obvious
<discord-> B​utcher. — Min is more useful.
<discord-> B​utcher. — Max might be useful for comms planning.
<discord-> e​gg. — yeah the thing is quickly the question becomes whether you really care about max over the whole mission, or some mean value of max
<discord-> e​gg. — @Butcher for "will I bump into something (incl. air)", what you want to see in the UI is the true minimum of your altitude; but for "what does my orbit feel like/what are observing/transmission conditions", some sort of mean peri/apo apsis *might* be more useful
<discord-> e​gg. — emphasis on might, because whereas the other elements are sufficiently abstract that you don't really care about the osculating ones, I'm afraid mean apsides might induce confusion next to the local extrema of distance
<discord-> B​utcher. — Indeed. I'm not sure there's a great way to present the info.
<discord-> e​gg. — @Sir Mortimer speaking of the orbit analyser, I'm thinking that the time spent in eclipse might be a useful datapoint there :-p
<discord-> e​gg. — (should get around to showing mean solar time first)
<discord-> e​gg. — @Sir Mortimer also re. your estimation, it is true that high frequency components are a PITA. It's still probably best to use an analytic model (so you don't have to sample the orbit, that feels morally wrong), but getting rid of the short-period stuff otherwise is messy
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
Jesin has quit [Quit: Leaving]
Jesin has joined #principia
egg|laptop|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 200 seconds]
egg|cell|egg has joined #principia
<discord-> e​gg. — hm
<discord-> e​gg. — @Sir Mortimer yeah I guess your approach should be OKish; I'd do it by interpolation once you have managed to get rid of short-period effects though (rather than discontinuously changing the estimate)
<discord-> e​gg. — that is, estimate the current 1-revolution shadow rate from the Orbit, then do so at a later point, and interpolate between the two
<discord-> e​gg. — sadly I don't think you can easily estimate the first derivative of the shadow rate
<discord-> e​gg. — the shadow rate rate
<_whitenotifier-d13c> [Principia] pleroy closed pull request #2446: Fix more Clang warnings - https://git.io/JvUT6
<_whitenotifier-d13c> [Principia] pleroy pushed 3 commits to master [+0/-0/±54] https://git.io/JvUoq
<_whitenotifier-d13c> [Principia] pleroy 806d5b1 - Fix more Clang warnings.
<_whitenotifier-d13c> [Principia] pleroy 33260d3 - Clang and MSVC disagree.
<_whitenotifier-d13c> [Principia] pleroy eb9a98d - Merge pull request #2446 from pleroy/Warnings Fix more Clang warnings
<_whitenotifier-d13c> [Principia] pleroy commented on issue #2447: i have planet texture issue with your mod. - https://git.io/JvUoG
<_whitenotifier-d13c> [Principia] pleroy commented on pull request #2438: Symmetric bilinear forms on bivectors and the anticommutator form - https://git.io/JvUoZ
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4092/
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4092/
UmbralRaptop has quit [Quit: Bye]
UmbralRaptop has joined #principia
UmbralRaptor has joined #principia
UmbralRaptop has quit [Ping timeout: 204 seconds]
raptop has joined #principia
UmbralRaptor has quit [Quit: Bye]
UmbralRaptop has joined #principia
<raptop> egg|cell|egg: https://arxiv.org/abs/1708.05513
<raptop> (idea: a test on orbits where the error is caused by the Yarkovsky effect. Probably impractical, though)
<discord-> e​gg. — raptop: wouldn't we need to have SRP first?
<raptop> No, no. Like the Mercury test
<raptop> Except with solar radiation pressure/asymmetric emission, instead of GR
<_whitenotifier-d13c> [Principia] pleroy opened pull request #2448: Last round of warning fixes - https://git.io/JvUiw
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4093/
<_whitenotifier-d13c> [Principia] pleroy reviewed pull request #2438 commit - https://git.io/JvUii
<_whitenotifier-d13c> [Principia] pleroy reviewed pull request #2438 commit - https://git.io/JvUiP
<_whitenotifier-d13c> [Principia] pleroy labeled pull request #2438: Symmetric bilinear forms on bivectors and the anticommutator form - https://git.io/Jvf6p
<_whitenotifier-d13c> [Principia] eggrobin labeled pull request #2448: Last round of warning fixes - https://git.io/JvUiw
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4093/
raptop has quit [Quit: leaving]