raptop changed the topic of #kspacademia to: https://gist.github.com/pdn4kd/164b9b85435d87afbec0c3a7e69d3e6d | Dogs are cats. Spiders are cat interferometers. | Космизм сегодня! | Document well, for tomorrow you may get mauled by a ネコバス. | <UmbralRaptor> egg|nomz|egg: generally if your eyes are dewing over, that's not the weather. | <ferram4> I shall beat my problems to death with an engineer. | We can haz pdf
<egg|zzz|egg>
bofh: the old fullrate format is, um, something ftp://cddis.gsfc.nasa.gov/pub/slr/data/fr/lageos1/1980/lageos1_c.8001
<egg|zzz|egg>
bofh: purely numeric fromat on 69 columns with checksums modulo 100
<egg|zzz|egg>
bofh: no, but its number of columns make it a Nice format
<egg|zzz|egg>
s/make/makes/
<galois>
egg|zzz|egg meant to say: bofh: no, but its number of columns makes it a Nice format
<egg|zzz|egg>
bofh: also files start with the record 99999 for some reason
<bofh>
I was about to jokingly comment that "did they *seriously* use the Luhn checksum", but no, that one's mod10, not mod100.
<egg|zzz|egg>
bofh: actually it's 54 columns, only the engineering records go to 69, so it's not even that nice
egg|zzz|egg has left #kspacademia [#kspacademia]
egg|zzz|egg has joined #kspacademia
<egg|zzz|egg>
bofh: oh of course the first entry of the header record, 7501001, itself parses as 75␟010␟01, which encodes the COSPAR ID 1975-010A in a purely numeric form
<egg|zzz|egg>
bofh: see, the NPT CRD format is fine :-p
<egg|zzz|egg>
the old NPT format is the true madness
<bofh>
oh gods that's not even Hollerith, it's some custom abomination
<egg|zzz|egg>
bofh: where would there be hollerith
<egg|zzz|egg>
it's all fixed-form!
<egg|zzz|egg>
no need for hollering
UmbralRaptop has quit [Remote host closed the connection]
<bofh>
Ahh, right.
UmbralRaptop has joined #kspacademia
<egg|zzz|egg>
'On this same line, columns 10-12 hold the Time System Indicator. In order to remove any ambiguity with respect to which time system is being used in mixed files, this field specifies the time system used in each SP3-c file: use "GPS" to identify GPS Time, "GLO" to identify the GLONASS UTC time system, "GAL" to identify Galileo system time, "TAI" to identify International Atomic Time, "UTC" to identify Coordinat
<egg|zzz|egg>
ed Universal Time, or "QZS" to identify QZSS Time. No default value is implied; either "GPS", "GLO", "GAL", "TAI, "UTC", or "QZS" must be specified.'
<bofh>
QZSS?
<galois>
QZSS: Quasi-Zenith Satellite System
<bofh>
Ahh.
<egg|zzz|egg>
!acr -add:GST Galileo System Time
<galois>
Definition added!
<egg|zzz|egg>
'The GST start epoch is 00:00 UT on Sunday 22nd August 1999 (midnight between 21st and 22nd August). At the start epoch, GST was ahead of UTC by 13 leap seconds.'
<egg|zzz|egg>
wait what happened to BeiDou system time
<egg|zzz|egg>
bofh: so GPS time = GST?
<egg|zzz|egg>
and ГЛОНАСС time = UTC?
<egg|zzz|egg>
but what is QZSS time
* egg|zzz|egg
stares at the 91 in columns 5-6 of SP3 Line Three
<egg|zzz|egg>
oh, I need to parse SP3-d
<egg|zzz|egg>
bofh: hah:
<egg|zzz|egg>
/* GNSS RESEARCH CENTER, WUHAN UNIVERSITY (WHU), P. R. CHINA
<egg|zzz|egg>
/* POSITION AND NAVIGATION DATA ANALYST (PANDA) SOFTWARE
<egg|zzz|egg>
!acr -add:PANDA Position And Navication Data Analyst
<bofh>
Yep, Glonass has leap-seconds in the fucking GNSS.
<bofh>
Only one to do that.
<egg|zzz|egg>
bofh: that's less annoying than having some silly arbitrary offset tbh
<egg|zzz|egg>
bofh: now I need to implement yet another timescale, because they didn't pick one of TT, TAI, UTC for GPS
<egg|zzz|egg>
bofh: they planned to have GST=TAI but then changed their mind for interoperability and made GST=GPS time
<bofh>
GPS should just be TAI plus an offset.
<egg|zzz|egg>
bofh: yes, that's still a separate thing to implement
<egg|zzz|egg>
and an offset whose sign I need to get right
* egg|zzz|egg
slaps GPS time with a trout
<egg|zzz|egg>
"IRNSS (Indian Regional Navigational Satellite System) Time is still under consideration."
<bofh>
LOL
<egg|zzz|egg>
however have you considered: timescales
<bofh>
not nearly enough, it would seem. :P
<egg|zzz|egg>
however have you considered: TNI, international catgirl time
<bofh>
what's the conversion between TNI and bofhtime, anyhow?
<egg|zzz|egg>
bofh: refer to IERS Conventions (2010), Chapter 10: General relativistic models for space-time coordinates and equations of motion
<bofh>
egg|zzz|egg: thanks, I just fell off my chair laughing.
<egg|zzz|egg>
bofh: tbh the silly thing with глонасс time isn't so much following UTC as it is the trolly +3h :-p
<bofh>
egg|zzz|egg: one's an affine shift, the other requires corrections to be periodically beamed up to an entire MEO sat constellation and stored in their memory and synced and whatnot.
<bofh>
:p
<egg|zzz|egg>
yeah, I mean, it's a weird design decision
<egg|zzz|egg>
(otoh I guess it gives you bulletin C from the skies, so that's nice :-p)
<egg|zzz|egg>
the 3 h is just silly
<bofh>
I mean yes, it's silly and pointless and I have no idée why they did that.
<egg|zzz|egg>
bofh: next trolliest things after interchanging broadcasts in ГОСТ 10859, and slightly more practical?
<egg|zzz|egg>
bofh: btw, ⏨ is a nice character
<egg|zzz|egg>
we should use it more
<bofh>
wait, isn't 10859 a *punchcard* standard?!
<egg|zzz|egg>
bofh: yes
<egg|zzz|egg>
bofh: I'm just trying to come up with trolly things
<egg|zzz|egg>
bofh: ГОСТ 10859 would be very trolly
<bofh>
I mean okay I guess you could try to use punchcards for interchanging teletext
<egg|zzz|egg>
bofh: I mean ГОСТ 10859 is just a character encoding at the end of the day
<bofh>
...actually first let me check how much data can you fit into VBI
<egg|zzz|egg>
bofh: so you could have your satellite interchange data encoded in that
<egg|zzz|egg>
it would be silly
<bofh>
you're looking at 11 VBI lines and ~45 7-bit chars/line, so 495 chars
<bofh>
That'd handily fit on a punchcard
<bofh>
So yes, you could use ГОСТ 10859 for teletext interchange, tho you'd need to print about 30 punchcards for each second of video
<bofh>
if you're doing EIA-608 you're only looking at 1 VBI line (line 21), so in theory you should be able to fit about a second of closed captions on a typical-size punchcard assuming each frame uses all characters (which is very rarely the case, usually the character density is far lower).
<bofh>
and yeah you can just use 10859 as a custom encoding in a Level 3 Teletext system over-the-air
<bofh>
...this actually isn't that trolly, I guess.
<egg|zzz|egg>
bofh: well if you are interchanging text in this encoding today, it is trolly
<egg|zzz|egg>
also impractical
<bofh>
I mean I'm talking about using ГОСТ 10859 in ETSI 300 706 Level 3
<bofh>
This is not a sane idée, and that's assuming using 300 706 makes sense to begin with (a lot of TVs nowadays can't do analog teletext demodulation iirc).
<bofh>
egg|zzz|egg: rofl why the hell is it chartreuse
<egg|zzz|egg>
it's not
<egg|zzz|egg>
bgcolor="#00FF00"
<bofh>
Ahh, it's pure green and my monitor's red channel is miscalibrated. >_<
<egg|zzz|egg>
bofh: I think the html name of that colour is eye-searing lime
<bofh>
fun fact: I have multiple shirts in #7FFF00 colour
<bofh>
ACCURATE
<bofh>
(the reason for this is they're volunteer tshirts for scicomm events, and that colour is very visible in a crowd)
<bofh>
(very visible at night, too, lol. but horrendous)
* egg|zzz|egg
slaps bofh with a colourimetric trout
<bofh>
"The web color named "lime" actually corresponds to the green primary of an RGB display: it has a different HTML color code (#00FF00)."
<bofh>
holy shit you're right
<egg|zzz|egg>
bofh: your shirt isn't a calibrated screen, you're going to have to specify your colour better than that
<bofh>
look, I'm not going to specify colourspace and standard illuminant for the colour of a shirt, lol.
<bofh>
Not sure I even have a properly calibrated sensor here, even.
<egg|zzz|egg>
bofh: clearly you need a gretag mcbeth shirt
<egg|zzz|egg>
s/mc/mac/
<galois>
egg|zzz|egg meant to say: bofh: clearly you need a gretag macbeth shirt
<bofh>
That reminds me, I need to head back to Electrolab and calibrate the one of the *three* spectrophotometers I found on a shelf there.
<egg|zzz|egg>
bofh: hm, I have ParseTT, ParseTAI, ParseUTC, ParseUT1; should I call the new function ParseGPS, ParseGST, ParseGalileoGPS, or something else?
<bofh>
well 'GST' is technically the time reference name, not 'GPS', I think, so ParseGST makes the most sense?
<kmath>
<bofh453> @eggleroy <@eggleroy> see, the NPT CRD format is fine :-p ⏎ <@bofh453> …you and I have *very* different definitions o… https://t.co/1kWpBbAlIP
<egg|zzz|egg>
bofh: the one with 54 columns of decimal digits is the old NPT format
<egg|zzz|egg>
bofh: NPT CRD is like this ftp://edc.dgfi.tum.de/pub/slr/data/npt_crd/glonass120/2019/glonass120_20190101.npt
<egg|zzz|egg>
bofh: I guess I can use GST and pretend GPS doesn't exist :-p
<bofh>
AAAAAAAA
<bofh>
Yeah, I thought BST was for BeiDou as well (also British Summer Time, b/c acronym overloading).
<egg|zzz|egg>
!acr -add:BST 北斗 System Time
<galois>
Definition added!
<bofh>
f/win 20
<egg>
hm, in SP3-d they do support BST
<egg>
use "GPS" to identify GPS Time, "GLO" to identify the GLONASS UTC time system, "GAL" to identify Galileo system time, “BDT” to identify BeiDou system time, "TAI" to identify International Atomic Time, "UTC" to identify Coordinated Universal Time, “IRN” to identify IRNSS Time, or "QZS" to identify QZSS Time. No default value is implied; either "GPS", "GLO", "GAL", “BDT”, "TAI”, "UTC", “IRN”, or "QZS" must b
<bofh>
a 2-electron integral codebase that the computational chemistry suite I worked in used to depend on before I axed about a third of it and then the remaining 2/3rds were finally replaced.
<bofh>
note that literally *everything* in a compchem algorithm depends on the correctness and precision of your 2e integrals, and so being able to make sure that you're getting sensible values from it is extremely important
<egg|zzz|egg>
so... they use capitalization to indicate the line number mod 2 or what
<bofh>
I think it's generational, all non-capital lines are written by not-the-original-author and post... 1986? I think.
<egg|zzz|egg>
ah
<bofh>
Note that the initial codebase is from 1971.
<egg|zzz|egg>
hm, the continuation column in some of those data blocks is fun too
<egg|zzz|egg>
123456789O
<bofh>
This is literally the worst code I've ever worked with.
<egg|zzz|egg>
yes that's the letter O
<egg|zzz|egg>
then 1s
<bofh>
Like, nothing else I can think of comes close.
<egg|zzz|egg>
c Hemal Varambhia end of de-bug
<egg|zzz|egg>
c Write state 12th March 2007:
<egg|zzz|egg>
! Hemal write statement 12th April
<egg|zzz|egg>
okay what the hell, does that compile?! " ! write(6,*) 'nrco(kmax)=',nuco(kmax)"
<egg|zzz|egg>
there's an exclamation mark in a label column
<bofh>
For example, I was responsible for rewriting subroutines ONEL and ONELH. First off, ONEL is entirely redundant against ONELH, as your kinetic energy integral evaluation is literally your overlap integral + 2 forward differences + 2 backward differences, so this is all duplicated for no reason.
<bofh>
Yes, Fortran90 comment style
<egg|zzz|egg>
bofh: sure, the !
<egg|zzz|egg>
bofh: but it's not in column 1!
<bofh>
This particular version of it requires a compiler supporting "free format" instead of "fixed format".
<bofh>
actually wait what the fuck
<egg|zzz|egg>
bofh: wait, that program is free format, not fixed format!?
<egg|zzz|egg>
bofh: but then the continuation column will get interpreted, that makes no sense
<bofh>
you can't mix [cC] and [!] comments, and the latter I'm pretty sure aren't allowed in F77, and certainly not if they're not in column 1.
<bofh>
...I'm going to say this one is fixed and an nbsp got in there or SOMETHING.
<egg|zzz|egg>
bofh: ! in column one is a common style, I can perfectly imagine compilers interpreting *anything* in col 1 as a comment
<bofh>
The one I have diverged from this anyway and has a lot of additions to READIN.
<egg|zzz|egg>
since that's the only thing the comment does anyway
<egg|zzz|egg>
s/comment/column/
<galois>
egg|zzz|egg meant to say: since that's the only thing the column does anyway
<bofh>
Yeah, that's indeed the case for most F77 fixed format compilers.
<egg|zzz|egg>
bofh: so ! is fine
<bofh>
Like LAPACK uses * instead of [cC]
<egg|zzz|egg>
but ! in a label column!?!
<bofh>
Yeah I have no idée, that wouldn't work, I'm going to blame that on gremlins and it's not supposed to be in that column.
<egg|zzz|egg>
okay wtf
<egg|zzz|egg>
after C RETRIANGULARIZE
<egg|zzz|egg>
1004 NUM=-MRAF
<bofh>
Anyway to continue, after way too much time I figured out what about half the variables in ONELH were and then reimplemented overlap /kinetic energy / nuclear attraction integrals from scratch.
<egg|zzz|egg>
no leading space
<egg|zzz|egg>
that's a 1004 with the 1 in the comment column
<egg|zzz|egg>
so it's not a label, it's a comment!?
<bofh>
I think indentation might be a bit fucked on this.
<bofh>
that should definetly be a label, it is in my codebase.
<bofh>
Also in a wonderful example of "clear as mud", MRAF is the total number of contracted orbital functions being evaluated.
<bofh>
(i.e. each atom has for its numeric quantum number a total number of orbital functions, and each of these decomposes into primitive orbital functions. for instance, for a d orbital, NRCO would be 5, and then assuming a 6-31G** basis, NUCO would be 6 iirc).
<bofh>
all of the variable names are like this.
<bofh>
function names too -- TSFSTA gives you Clebsch-Gordan coefficients, for instance.
<bofh>
er
<bofh>
s/TSFSTA/EXCOEF/
<galois>
bofh meant to say: function names too -- EXCOEF gives you Clebsch-Gordan coefficients, for instance.
<bofh>
The Cartesian-to-Spherical transformation there is incorrect for H orbitals, but mercifully those are very rarely used. OTOH, I suspect this is how that fact managed to escape detection for, nearest I can tell, 4 decades?
<egg|zzz|egg>
bofh: EGNPCDOF
<bofh>
Anyway that's the level of ""kwality"" academic code can sink to. Most isn't quite *that* bad, but I've run into codebases that came scarily close at times.
<egg|zzz|egg>
clearly Principia needs a FORTRAN 66 interface
<bofh>
egg|zzz|egg: I mean you actually explain what EGNPCDOF means ("ExternalGetNearestPlannedCoastDegreesOfFreedom")
<egg|zzz|egg>
EGNPCDOF is eggsactly 8 characters too
<bofh>
also I'm not sure why the fuck they named it EXCOEF
<egg|zzz|egg>
EGGSCOEF
<bofh>
COEF, sure, those are coefficients in front of the Gaussian integrals themselves that determine multiplicity
<bofh>
but like, they're essentially sums of binomial coefficients, and all the literature denotes them as I_{x,y,z} in their algorithm descriptions.
<bofh>
...I'm scared to ask what EGGSCOEF does :P
<bofh>
how would one apply Clebsch-Gordan coefficients to an egg, anyhow?
<bofh>
...yeah, it uses the Racah recursion relations to compute said coefficients. I hate how that function took me two days to understand only to realize it just does *that* and a one-line comment would've saved me all that time.
<bofh>
Doesn't help it also does some irrelevant crap, some of which is only used in some invocations of it and some COMPLETELY UNUSED that you have to excise first b/c it otherwise makes everything needlessly confusing.
<bofh>
I swear to Azathoth a genetic algorithm would prolly have produced more readable & comprehensible code.
<bofh>
...actually wait, EGGSCOEF clearly just precomputes Zonal Harmonics. :P
<bofh>
since that's basically the relevant concept here.
<egg|zzz|egg>
meow
dx has quit [Ping timeout: 180 seconds]
dx has joined #kspacademia
<egg|zzz|egg>
bofh: huh, TT(BIPM17) = TAI + 32.184 s + 27661.0 ns at the end of 2017
<egg|work|egg>
but it has reached 27.6 microseconds
<bofh>
"errors of TAI"? from what source?
<bofh>
like it *does* seem to be stabilizing, at least.
<egg|work|egg>
bofh: https://www.bipm.org/en/CGPM/db/26/2/ CGPM 26, resolution 2: TAI [...] is a realization of TT as defined by IAU Resolution B1.9 (2000)
<egg|work|egg>
bofh: any realization of TT will have errors
<egg|work|egg>
one that has to be broadcast in real time is likely to be fairly clunky
<egg|work|egg>
a posteriori, you can make a better realization of TT
<egg|work|egg>
TT(BIPMyy) is an example of such a realization
<egg|work|egg>
"Physical realizations of UTC – named UTC(k) – are maintained in national metrology institutes or observatories, which contribute to UTC by sending their clock data to the BIPM. These time laboratories then use UTC to steer their clocks. Values of [UTC – UTC(k)] at five-day intervals are published in the monthly BIPM Circular T, which gives officia
<egg|work|egg>
l traceability to UTC to its representations UTC(k)."
<egg|work|egg>
bofh: TT(TAI) (which is TT(UTC), because UTC is TAI with an offset by definition) is based on the solution given in Circular T
<egg|work|egg>
bofh: "TT(BIPM) is a realization of Terrestrial Time as defined by the International Astronomical Union (IAU). It is computed in deferred time, each January, based on a weighted average of the evaluations of the frequency of TAI by the primary and secondary frequency standards. It is mostly used in scientific applications requiring long-term freque
<egg|work|egg>
ncy stability and high frequency accuracy."
<egg|work|egg>
bofh: does that make sense
<bofh>
yes, yes it does.
<egg|work|egg>
bofh: and in that sense, this means that you shouldn't treat TAI as "the actual time at the geoid for realz"
<egg|work|egg>
like GPS time, GST, 北斗时, IRNWT, etc., it is just a realization of TT; one of the more accurate realizations, but still just one
<egg|work|egg>
bofh: much like if you want to be correct in treating ECEF coordinates, you can't say that ITRF2008 is the real deal, because it differs from ITRF2014 or ITRF2000
<egg|work|egg>
none of those are "the ICRS"
<egg|work|egg>
well
<egg|work|egg>
none of those are "the ITRS", more interestingly :-p
<bofh>
well in a sense yes, but from what I'm gathering, TT(BIPM) is TAI plus an affine shift plus *a posteriori corrections*
<egg|work|egg>
bofh: no, there's no affine shift here
<bofh>
i.e. once you publish a value of TAI, you can't correct it
<bofh>
er, so what's the 32.184 seconds then? :P
<egg|work|egg>
ah
<egg|work|egg>
yes, I read "TAI" as "TT(TAI)"
<egg|work|egg>
otherwise this gets too silly
<egg|work|egg>
bofh: and yes, it is one realization of TT, if you could correct it it would become a family of realizations and you would lose traceability
<egg|work|egg>
bofh: much like once you publish a value of UTC(SU) you cannot correct it, or when you publish a value of UTC(bofh's desk)
<bofh>
Yes, I'm not saying that doesn't make sense, it *does* make sense. :P
<egg|work|egg>
bofh: it does mean, though, that you should not use TAI as your representation of actual time; you should convert to TT as appropriate for your usage, and operate in TT
<egg|work|egg>
bofh: this applies conceptually, and thus, even where you do not care about inaccuracies like those of TT(TAI), you should still operate in TT, not in TAI
<egg|work|egg>
(and then if you start to care, you can refine your conversions and improve your traceability as needed)
UmbralRaptop is now known as RelativisticRaptor
<RelativisticRaptor>
Oh, good. Finally 4-vectors
<RelativisticRaptor>
But apparently we need to introduce Einstein notation
<egg|work|egg>
Einstein notation is nice
<egg|work|egg>
[insert angry bofh here]
<RelativisticRaptor>
Also the idea of a vector containing time is new and shocking
<egg|work|egg>
hah
<RelativisticRaptor>
apparently this is 1919 instead of 2019?
egg|work|egg has quit [Quit: webchat.esper.net]
egg|work|egg has joined #kspacademia
<RelativisticRaptor>
less philosophy, more eggsamples of how to do calculations, plz
<RelativisticRaptor>
establishing orthogonality in vector components… is this a stealth QM class?
<RelativisticRaptor>
"I'll be honest, I've always been confused about what the term 'outer product' means" -- the teacher
<RelativisticRaptor>
am I doomed?
<egg|work|egg>
I've always been confused about what the term 'outer product' means << same
<egg|work|egg>
it's something separate from the exterior product iirc? what are words
<egg|work|egg>
ah it's just the tensor product for people who love matrices and have an implicit inner product lurking at every corner
<RelativisticRaptor>
metaphorical corner, or is that a mathematical term?
<egg|work|egg>
it probably is a mathematical term, but not here
<RelativisticRaptor>
. o O (corners of an apartment)
RelativisticRaptor has quit [Quit: Bye]
UmbralRaptop has joined #kspacademia
<UmbralRaptop>
"light is the only thing that doesn't move at the speed of light"
UmbralRaptop has quit [Read error: Connection reset by peer]
UmbralRaptor has joined #kspacademia
UmbralRaptop has joined #kspacademia
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #kspacademia
Raptop has joined #kspacademia
Raptop has quit [Remote host closed the connection]
<UmbralRaptop>
"Although the scientific community supported SIRTF, it was anxious to get a new infrared instrument up and running to follow up on the findings of the COBE and IRAS missions of the 1980s. No one knew if or when SIRTF would fly. SOFIA and Edison provided a way to hedge one’s bets."
<UmbralRaptop>
lolsob
<bofh>
eggstremely lolsob
UmbralRaptor has joined #kspacademia
UmbralRaptop has quit [Ping timeout: 202 seconds]
<egg|cell|egg>
SIRTF?
<galois>
SIRTF: Space InfraRed Telescope Facility (became Spitzer)
<egg|cell|egg>
SOFIA?
<UmbralRaptor>
!acr -add:SOFIA Stratospheric Observatory for Infrared Astronomy
<galois>
[WIKIPEDIA] Porkchop plot | "A porkchop plot (also pork-chop plot) is a chart that shows contours of equal characteristic energy (C3) against combinations of launch date and arrival date for a particular interplanetary flight.By examining the results of the porkchop plot, engineers can determine when launch opportunities exist ..."
<B787_300>
yeah
<B787_300>
i also hate how they are in C3 instead of just dV over Escappe
<_whitenotifier>
[Principia] pleroy opened pull request #2081: Next release is Fano - https://git.io/fhdLb
<bofh>
wait, why would dV/Escape be more useful than C3 (or at least the specific orbital energy)?
<B787_300>
i mean the dV over escape is just C3^0.5 (if you ignore the fact that all this is done in the orbit of much bigger bodies)
<B787_300>
it is just an easier and faster (at least for me) way of seeing how much rocket you need
<B787_300>
the other reason is it would have helped up win my senior design project
<bofh>
ahh, yeah that makes sense.
<B787_300>
the person who was doing the orbit stuff miss calculated it and said we needed 2x the amount of dV to get to mars which meant that in the early stages we thought we needed 2 launches
<B787_300>
we figured out the mstake a couple months later, but we were invested in the design so instead of 2 launches we went to a dual-manifest launch. we could have saved like 500 kg and a couple hundred mill by redoing to design
<B787_300>
and the comments we got back from the competition were A) why didnt you use any newer technology like ISRU (this was a mars sample return), B) why didnt you recombine the two spacecraft into one
<B787_300>
and i was so mad that the reviewer even said A because of the other constraints in the competiiton description (had the meet up with the Mars2020 rover which is doing the sampling within 90 sols of it landing) which meant that we had to launch in the same xfer window which meant that this thing would have to start being built NOW (this was the 2015-2016 school year) which means there is no time for the development of new stuff
Raptop has joined #kspacademia
<B787_300>
the top 2 designs both used an unproven and unbuilt ISRU unit and said their entire mission including operations costs would be like 500 or 750 MILLION
<B787_300>
still drives me bonkers thinking about it if you cant tell
<B787_300>
where as our mission used all TRL9 tech (except for one part) and was estimated at 4 Bn foir the entire mission
<B787_300>
s/one/a couple
<galois>
B787_300 meant to say: where as our mission used all TRL9 tech (except for a couple part) and was estimated at 4 Bn foir the entire mission
<B787_300>
the parts that werent TRL9 were a couple linear actuators for the legs of the lander (to level the platform) and the rocket raising mechanism, and a slight modification to the engine to allow throttling which the engine manufacturer had dont on other engines of the same class as what we needed
<Raptop>
o_O
* Raptop
stabs things, and guesses that the linux install on urvogel is partially broken
<B787_300>
oh raptop how did the observations go?
<Raptop>
...poorly
<B787_300>
weather?
<Raptop>
Nah, telescope issues.
<B787_300>
i can commiserate
<Raptop>
First it was tracking oddly. Then not at all. Then attempting to restart it caused the software to lose all its configuration info.
<Raptop>
(Note that between the second and third events, I had called the relevant higher up people, and was following their troubleshooting instructions)
<Raptop>
And by lose all configuration info, I mean so much so that the software stopped being able to talk to the telescope, and I got to learn how to close the dome and turn off the telescope manually.