UmbralRaptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fuchs. We currently target 1.5.1, 1.6.1, 1.7.x, 1.8.1, and 1.9.1. <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
<discord->
lamont. — it looks like C# 9 may be getting "records" which are created with "data struct" which turns them into invariant pass-by-value things that subclass. which smells like a subclassable readonly struct. which may be perfect for strongly typed Vector3d-like things
<discord->
egg. — that might work, though you need to build up quite a lot of abstraction to get to Principia-level enlightenment
<discord->
egg. — that *does* change what your formulae look like
<discord->
lamont. — (if you try to do that with composition the problem is that instances of classes are heap allocated)
<discord->
egg. — because if you distinguish bivectors from vectors, there is no such thing as a cross product
<discord->
egg. — so you need to take your physics textbook, and redo all the bookkeeping to change crosses to wedges, commutators, or actions of bivectors on vectors, as appropriate
<discord->
lamont. — yeah, i'd take it to have strongly typed vectors
<discord->
egg. — [B1, B2] = B3, v1 ∧ v2 = b, B v1 = v2, v1 B = v2 are all "cross products"
<discord->
lamont. — i can't count the number of hours i've wasted from missing a xzy somewhere
<discord->
egg. — yeah that was good foresight of me to start Principia with building a framework to guard against that category of silliness
<discord->
egg. — (incidentally that is the original reason why it is in C++, not performance concerns, but the power of the type system; can’t do physical quantities in C#)
<discord->
lamont. — the other thing that has just gotten me is the formulas for euler angles and the fact that those quantities are still right handed angles, but the angle functions in unity are all left handed
<discord->
egg. — ooh, Euler angles are probably a mess yes
<discord->
egg. — (they are, after all, a form of coordinates)
<discord->
egg. — (well, they are a chart)
<discord->
lamont. — // This is the ZXZ intrinsic rotation, converting Vector3d.right (pointing at the periapsis) from the perifocal system. Thus, the
<discord->
lamont. — // order of applying the angles is backwards. However, the negative sign for the rotation angle is cancelled out by AngleAxis being
<discord->
lamont. — // a left-handed rotation, so the angles here are positive. Argh.
<kmath>
<bofh453> <@eggleroy> you should take a course on differential geometry. that's the only sane way to approach SO(3)/SU(2). ⏎ <… https://t.co/Aw3ZU3b1zq
<discord->
egg. — @lamont but defining rotations with Euler angles generally leads to at least one sign error every time; we try to mitigate that with our DefinesFrame // Constructors from Cardano angles.
<discord->
egg. — // Example: if |Aircraft| is the frame of an aircraft (x forward, y right,
<discord->
egg. — // z down), and |Ground| is a local-vertical, local-horizontal frame (x North,
<discord->
egg. — // y East, z Down), given the |heading|, |pitch|, and |roll| of the aircraft,
<discord->
egg. — @lamont there is also the fact, of course, that while astronomers do use ZXZ Euler angles, game developers use ZYX Cardano angles, and then call them Euler angles
<discord->
Acer_Saccharum. — TIL there's another type of "exchange" orbit besides the a-swapping orbits of Janus and Epimetheus, an orbit where two equal massed bodies exchange eccentricities
<raptop>
equivalent exchange orbit
egg|laptop|egg has quit [Remote host closed the connection]
<discord->
lamont. — weird, i jammed the terminal conditions from the ping lu paper together with the transversality conditions from a 3rd paper and it magically works
<discord->
lamont. — voodoo math
<discord->
lamont. — although coasts don't seem to be working so there's that
raptop has quit [Ping timeout: 190 seconds]
<discord->
lamont. — oh wait i went circular and its failing, that's the old code, that's really weird
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #principia
<_whitenotifier-d13c>
[Principia] WC12366 opened issue #2591: No "腾讯微云" link for Fuchs - https://git.io/JfV81
<_whitenotifier-d13c>
[Principia] pleroy pushed 1 commit to master [+0/-0/±1] https://git.io/JfV4J
<_whitenotifier-d13c>
[Principia] pleroy c32246e - Fix the weiyun URLs.
<discord->
egg. — @Sir Mortimer so, some more thoughts on imagers. We want to avoid part spam (and for practical purposes, the need to find lots of part models), so only the instrument characteristics that give rise a different look/size should get separate parts; that means aperture (massively affects part size: compare the 30 mm diameter of the STEREO coronagraphs to the Jumbo64-sized HST) and FoV (the super-high FoV
<discord->
egg. — otoh, there are other characteristics that are relevant to mission constraints; in particular, the wavelengths
<discord->
egg. — so I think we should have a tweakable (VAB-tweakable only, not in-flight-tweakable) for the observed bands
<discord->
egg. — (the thing that prevents you from putting sensors for all the bands on one telescope being that IR has special cooling requirements so will eat mass for nothing if you cannot satisfy those, and in the other direction that supporting UV means you cannot use Au coatings, so you must fall back to Al which has poorer reflectivity in IR)
<discord->
Sir Mortimer. — so a IR instrument would be wrapped in gold foil and have some active cooling, an UV instrument would not
<discord->
egg. — discretizing the bands to MIR/NIR/visible/NUV/EUV for practicality, we probably then need to assume that sensor technology does not change (otherwise things get too messy), define pixel size for each (which determines resolution below the diffraction limit) and temperature-dependent sensitivity
<discord->
egg. — at least a MIR
<discord->
egg. — HST does some NIR, and Spitzer warm was a thing
<discord->
Sir Mortimer. — Can aperture be a VAB tweakable? Wouldn't that entail changing size+mass of the part?
<discord->
egg. — yeah I don’t think aperture should be a tweakable
<discord->
egg. — because it so massively (ha) changes the mass and size and look
<discord->
Sir Mortimer. — so we have at least 2 sizes of the telescope, and a part variant that would change the look from gold to aluminium depending on IR/UV
<discord->
egg. — the Au/Al thing is mostly about the mirror coating
<discord->
egg. — so not very visible unless you have a large thing like JWST or LUVOIR
<discord->
Sir Mortimer. — ah, so not visible
<discord->
Sir Mortimer. — (also answers my long standing question why webber has golden mirrors)
<discord->
egg. — indeed :D
<discord->
Sir Mortimer. — or was it webb, i keep forgetting
<discord->
Sir Mortimer. — james webb, the telescope that comes with a tent
<discord->
egg. — Au is slightly better than Al at long wavelengths
<discord->
egg. — but Au is a disaster in UV
<discord->
egg. — (or visible, really, as you can see with your eyes)
<discord->
Sir Mortimer. — so, assuming we have a telescope, having that in different sizes is easy. probably want enormous (HST) and small-ish (DISCOVR)... is that enough? Do we need 3 sizes?
<discord->
Sir Mortimer. — When Got is done with the thermal stuff, I also can make an IR telescope require cooling (radiators, depending on where it is)
<discord->
egg. — @Sir Mortimer as usual this is a vaguely continuous thing, that is, as it warms up the sensor will be noisier and less useful (sometimes to the point that you simply stop using it)
<discord->
egg. — (of course modelling internal temperatures is a right mess, but maybe we can assume that the sensor stays some ΔT below the hull temperature, that staying further below requires active cooling)
<discord->
egg. — @Sir Mortimer as for sizes, @𒀯 𒄷 𒄈𒀭𒁇 was suggesting
<discord->
egg. — > example telescope sizes: 0.1 m (probe), 0.3 m (large probe, small telescope), 0.9 m (Spitzerish), 2.7 m (better HST), 5.4 m (smol JWST)
<discord->
egg. — and we may need an even tinier one for solar imaging
<discord->
egg. — (also I think @𒀯 𒄷 𒄈𒀭𒁇 meant 8.1 rather than 5.4, to keep a factor of 3 each time, so that would be LUVOIR-B-sized)
<discord->
egg. — @Sir Mortimer note that things like VIIRS etc. fit in that definition, it is just that they have a mechanically enhanced FoV thanks to scanning (VIIRS has a 19.1 cm aperture and a swath aperture of 120° or thereabouts)
<discord->
egg. — @Sir Mortimer note that things like VIIRS etc. fit in that definition, it is just that they have a mechanically enhanced FoV thanks to scanning (VIIRS has a 19.1 cm aperture and a swath width that corresponds to an FoV 120° or thereabouts) (edited)
<discord->
egg. — @Sir Mortimer note that things like VIIRS etc. fit in that definition, it is just that they have a mechanically enhanced FoV thanks to scanning (VIIRS has a 19.1 cm aperture and a swath width that corresponds to an FoV of 120° or thereabouts) (edited)
<discord->
egg. — so if you have a VIIRSish part already (I think you do?) that can work for all the scanning instruments modulo rescaling/remassing)
<discord->
egg. — so if you have a VIIRSish part already (I think you do?) that can work for all the scanning instruments modulo rescaling/remassing (edited)
<discord->
Butcher. — @egg Wouldn't Ag be better at visible wavelengths?
<discord->
Butcher. — Oh just looked at that graph, bad at UV then!
<discord->
egg. — yeah if you want IR + visible you can go for Ag
<discord->
egg. — e.g., Kepler
<discord->
Butcher. — Is there an advantage to Au over Ag for IR?
<discord->
Butcher. — Is the visible cutoff a useful property?
<discord->
Butcher. — Is the legend wrong there? Bare gold is green, right?
<discord->
egg. — yeah I cannot make sense of the legend but that would make more sense
<discord->
Butcher. — It correlates withwhat I'd expect for gold.
<discord->
Butcher. — Definitely better in the IR range, I didn;t realise Ag drops off so much.
<discord->
egg. — so I guess for KC simplification purposes, a visible-only telescope gets Ag performance, an IR-only telescope gets Au performance, and otherwise you get Al
<discord->
Butcher. — Seems like a reasonable gamification.
<discord->
egg. — hm, no, Ag is better than Al at IR, so non-UV means you get Ag, IR-only means you get Au, any UV means Al
<discord->
egg. — ah no, sufficiently long IR is still better in Al...
<discord->
egg. — reading graphs hard
<discord->
Sir Mortimer. — What would the in-game effect of that distinction look like?
<discord->
egg. — some coefficient on the amount of light gathered, which has an effect on how dim you can look
<discord->
egg. — e.g. adding UV to your telescope might degrate its near-IR light gathering ability to 80% of what it would be if it were IR-only
<discord->
Sir Mortimer. — - wave length (spectrum from IR to UV), IR requires cooling
<discord->
Sir Mortimer. —
<discord->
Sir Mortimer. — (not sure if I forgot one, but anyway that's about as far as a reasonable gamification of this should go)
<discord->
Sir Mortimer. — A sun observing probe would be a 0.1m telescope in the IR band?
<discord->
egg. — 0.1 EUV, likely
<discord->
egg. — or 30 mm or less in some flavour of visible/IR for coronagraphs/heliospheric imaging
<discord->
Sir Mortimer. — And when breaking down wave lengths, would a discrete selection of IR / visible / UV be OK?
<discord->
egg. — we probably need to distinguish NIR (still usable warm, e.g. Spitzer warm, HST, etc.) and MIR (requires cooling)
<discord->
egg. — (NIR is going to perform better colder, but won’t fall over entirely when your coolant runs out)
<discord->
egg. — and another dimension that we cannot completely avoid is field of view (though we can incorporate detector swath width into that for scanning detectors)
<discord->
egg. — where a large field of view means you can do surveys of broad areas (be that pointing down, swath width, or for sky surveys), but you don’t get very high magnifications
<discord->
egg. — e.g. MRO CTX had mapped 10% of Mars in 2010, and HiRISE 1%
<discord->
egg. — and MARCI probably had imaged the whole thing multiple times over
<discord->
Sir Mortimer. — OK, translating FOV into what I already could do in KC: a satellite in Earth (or Kerbin) orbit is always pointed towards the center of the Planet. (Probe orientation is a concept that doesn't exist in KSP, so we'll have to live with that assumption). That probe would be able to "see" a given point on the surface if the elevation of the probe above that point would be > 90° - FOV
<discord->
Sir Mortimer. — Does this make any sense?
<discord->
egg. — I think this is a reasonable model for surveying/mapping/global imaging tasks (the pointed-to-centre thing)
<discord->
egg. — for « spysat-type » contracts we probably have to relax that assumption
<discord->
egg. — because your hubble-pointing-down is never going to exactly be pointed at the right spot by change
<discord->
egg. — because your hubble-pointing-down is never going to exactly be pointed at the right spot by chance (edited)
<discord->
Sir Mortimer. — do they turn their spy sats at all?
<discord->
Sir Mortimer. — ~~do they turn their spy sats at all?~~ (edited)
<discord->
Sir Mortimer. — so, for effective spying you'd need a couple of HSTs pointed at earth with a wide FOV... which feels wrong
<discord->
Sir Mortimer. — (HST + wide FOV)
<discord->
egg. — well if they have a wide FOV they have low resolution
<discord->
egg. — so they are not HSTs nor good spy sats
<discord->
Sir Mortimer. — Or maybe they could do without a wide FOV if they're mounted on a servo platform
<discord->
Sir Mortimer. — which would make for some entertainingly wiggling probes 🙂
<discord->
egg. — it’s not just Hubble pointed down, it’s hubble pointed down, with good tracking of the surface
<discord->
egg. — so basically: for mapping/surveying/monitoring contracts, assume the instrument points to the centre of the planet, and take the FoV into account
<discord->
egg. — for targeted observation of small things (spysat contracts, but also maybe specific spots of interest on another planet), disregard the FoV (though of course it indirectly affects the resolution of the instrument), just check that you can point at sufficiently high elevation
<discord->
egg. — so that means you can’t take your spysat and effectively use it for a land use monitoring mission (because small field of view), but you can use HiRISE both for very partial high-res mapping of Mars and the occasional « look at this potential landing site here »
<discord->
Sir Mortimer. — ok. so this would effectively eliminate stupid reuses.
<discord->
egg. — yeah
<discord->
egg. — and you can still use your spysat as a space telescope and do a (very partial) deep sky survey with it
<discord->
egg. — but obviously not an all-sky-survey
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
raptop has joined #principia
<discord->
𒀯 𒄷 𒄈𒀭𒁇. — @egg @Sir Mortimer I did mean 8.1 m instead of 5.4, and those were just a rough idea instead of explicit rules in some NASA doc. There's a chance that you want en even smaller size (glorified engineering camera/star tracker/docking camera) since there are situations where those can do science
<discord->
egg. — yeah you do need a smaller size for solar imaging anyway
<discord->
𒀯 𒄷 𒄈𒀭𒁇. — So, 30 mm. we might end up with parts from specific craft
<discord->
egg. — trying to figure out what the aperture is for MARCI
<discord->
egg. — > with the exactly amount of Delta V I need
<discord->
egg. — and how do you achieve that
<discord->
Sirius. — I had 3583 m/s for the TLI, and the maneuver used all that delta V
<discord->
Sirius. — With a SRB
<discord->
egg. — that manoeuvre uses 3383.921
<discord->
egg. — that manoeuvre uses 3383.921 m/s (edited)
<discord->
egg. — not 3583 m/s
<discord->
Sirius. — Yeah, I've change the number, not on purpose, but I had 3383 m/s and the maneuver used all that delta v
<discord->
egg. — OK so then I suppose the problem that the burn is too sensitive to timing
<discord->
Sirius. — Yeah, with the GCRC, when there are a few seconds left to burning time, the throttle decrease
<discord->
Sirius. — Yeah, with the GCRC, when there are a few seconds left to burning time, the "throttle" decrease (edited)
<raptop>
So, presumably there's a need to choose transfers where errors are damped instead of amplified?
<discord->
egg. — the main issue here is that the burn is modelled inaccurately (the "instant impulse" mode does not know about your engines), so you will not get the planned results by turning on the engine at the manoeuvre; figuring out when to start that burn is going to take some trial-and-error
<discord->
Sirius. — Yeah
<discord->
Sirius. — So I have to do the TLI with a liquid fuel engine?
<discord->
Sirius. — I wanted to do like a Pioneer 4 style TLI
<discord->
egg. — > I have to do the TLI with a liquid fuel engine?
<discord->
egg. — You don’t *have to*, apparently others here have done it with SRBs; but it is certainly easier to follow the flight plan if you have liquid engines
<raptop>
I swear, Fundamentals of Astrodynamics discusses a TLI to minimize errors
<raptop>
(Also, flybys in that era often had, uh, substantial errors)
<discord->
egg. — not sure how nicely that turns into a discrete set of parts...
<discord->
egg. — not sure how nicely that turns into a small set of parts... (edited)
<discord->
egg. — not sure how nicely that turns into a small set of parts… (edited)
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord->
RurouniDonut. — I'm not sure if this is a Principia issue or not. I remember seeing that apparently proc fairings did not like Principia. Anyways, this rocket starts spinning like crazy after the fairings are gone. They get caught after release. After they eventually get uncaught. The stage that is firing or the next stage will just spin up like crazy. I do have the latest Principia.
<discord->
egg. — How much can FoV be altered at constant aperture without significantly affecting the look and mass of a telescope?
<raptop>
I think a factor of a few
Hypergolic_Skunk_ has quit [Quit: Connection closed for inactivity]
<discord->
egg. — hm.
<raptop>
This does affect the depth of the optical system, but *waves talons*
<raptop>
Nah, we're just sticking a varying amount of eleggtronics on the back
<discord->
egg. — yeah and the type of optics can change to compensate
<raptop>
I *think* it's easier with cassegrain variants
<raptop>
(probably moreso once they start meowing)
<discord->
egg. — make it a Newtonian as the field becomes wider :-p
<raptop>
aaaa
<discord->
egg. — (to keep it the same length \o/)
<raptop>
Also, as best I can tell, there's a simple evolution of Mariner 4 -> 6/7 -> 9 -> 10
<raptop>
And I'd need to double check that there's any real difference between 6/7 and 9
<discord->
egg. — So, excluding the scanning instruments/heliospheric imagers/TESS which is weird/MARCI, the FoV range in that list still spans a bit more than 2 orders of magnitude, because of Kepler
<raptop>
I wouldn't be surprised if there's idea overlap between Kepler, Dragonfly, WASP, and KELT
<raptop>
Er, wait. I saw Kepler, and read it as TESS
<raptop>
Incidentally, that 11 degrees is in line with some wide angle cams on planetary craft.
<raptop>
At least in the vidicon tube era
* raptop
is compiling things
<discord->
egg. — on the other hand, as far as looks are concerned, Kepler doesn’t look all that different from, e.g., Spitzer
<discord->
egg. — so it does not seem absurd for them to be the same part with different tweakable values
<discord->
egg. — theres actually zero difference between Spitzer & Kepler, etc.
<raptop>
Okay, added Mariners, but might be missing a Venus one?
<raptop>
Also, please enjoy the sci-hub links
<discord->
egg. — so then maybe at the lower apertures we can give more leeway on the tweakable FoV (those small things tend to be refractors where you can do silly things, up to MARCI’s fisheye)?
Jesin has joined #principia
<raptop>
Seems fair
<discord->
egg. — and TESS can be ignored because it is just four separate wide-angle refracting cameras
<discord->
egg. — (in a trenchcoat)
<discord->
egg. — (and then you need separate part for the scanning things, but that is a given)
<raptop>
That's a sun shield, not a trenchcoat
Jesin has quit [Quit: Leaving]
Jesin has joined #principia
<raptop>
Anyway, that should be all the vidicon era imagers we care about?
<discord->
egg. — hah
* raptop
ignores the Soviets. Also, if one could treat the IR and UV instruments on the Mariners/Voyagers as imagers in any way
<discord->
egg. — looks like in UV it is a plain spectrometer, not an imaging spectrometer
Webchat628 has joined #principia
Webchat628 has quit [Client Quit]
egg|laptop|egg_ has quit [Remote host closed the connection]