Why NASA Needs a Programmer Fluent in Fortran and Assembly Language
popularmechanics.com
popularmechanics.com
This probably isn't practical, or sane, but I wonder what would happen if Nasa released an open source simulator for Voyager and invited the community help implement the software fixes they need. There might some really good devs who would do it just for the challenge.
Think of it as 0x10c with a purpose.
There might. There was that ISEE-3 Reboot Project last year to reconnect to the International Sun-Earth Explorer 3 probe.
Were I a manager, my concern would be to have the in-house competence to be able to review those fixes. If it costs less to hire someone to make the fixes than to be able to review external contributions for the fixes, and/or if there's less uncertainty in being able to get a result in the right time frame, then I know which way I would go.
Failure to connect to ISEE-3 doesn't have the negative risk impact of making a mistake with Voyager.
Anyway, in this case it's more than just the code. The new position requires "combing through secondary documents and correspondence", and presumably that means access to the primary literature, in an archive with unscanned materials. And while some retired engineers may have no problems with others 'picking their brains directly', it would be better to coordinate those questions instead of having a dozen different people ask the same questions.
It would be cool to have access to the source code and an emulator, but I really don't find it plausible that members of the general public could submit patches to something that's been running smoothly for 40 years, and where the risks of changes far outweigh the benefits of keeping the existing software running as-is.
It appears like they are currently working with estimates (e.g. they cite a use of 3.2 Watts but it's actually 3.0 due to margins of error in the original design. Now they want to know exactly how much power is consumed).
So maybe they don't need fixes in the traditional sense that something is broken, but fixes in that they need the spacecraft to do stuff that wasn't designed for.
Another example they cite is when they revamped the software in 1990 so they could better automate certain functions since they were preparing for the interstellar part of the journey and they needed certain automatic procedures which apparently were done manually in the past.
What they seem to need are engineers that can teach themselves quite deep domain knowledge of the voyagers to figure out how they work, reverse engineer the hardware and software that arn't documented. (and eventually do some programming, mainly on old ground based code, and certainly without bricking the probes if the flight software needs to be altered).
EDIT: should mention others have run with the idea and are actually building it https://www.reddit.com/r/techcompliant is the subreddit for the project.
This is why I like programming on the MBED platform [1] (or just AVR). Assembler, and IoT fun at the same time. Works with ethernet, serial, jtag - great fun
Now a Voyager computer itself looks like a peculiar piece of technology in itself - is it one of a kind? If so, who made an assembler and Fortran compiler for it? Unfortunately, the article (or any others I googled up) doesn't go into that. Is there a description of Voyager computer publicly available?
So far, I find it the most marvelous that a tape recorder is alive and well after 40 years of regular usage: the computer memory of the day was not nearly enough to hold scientific data, so it's being written on a 8-track tape recorder, sent to Earth and then overwritten again, in a loop. Still, even with minimial usage, I have trouble imagining how a single tape reel could last 40 years of regular use. In space.
[1] List of common microcontrollers: https://en.wikipedia.org/wiki/List_of_common_microcontroller...
STM32 F0: http://www.st.com/stm32f0
[1] https://books.google.ca/books/about/Modern_Fortran_Explained...
I always love to learn about stuff that has little to no use in real life (anymore).
I still find Hollerith constants in the code I work with some times to times :)
Also, a very important point is that the code I write will be in use for the next 20 to 30 years. If a, proven over decades, reliable solution is available, it is better.
Fortran and assembly language are key skills at every national supercomputing center in the world.
Even for the fields where it makes sense, like molecular dynamics, it's not obvious that you get more performance per dollar than with CPUs. Shameless self-plug: http://asmunder.github.io/2015/04/Inaugural-post:-on-the-ben...
12 gb ram may not be enough for some physics apps, but it's made a big difference for workloads requiring under 12gb of memory, when you get a 250 gb/s data transfers on gddr5 over the 12gb/s for ddr3
The few that are are blowing things out of the water[0].
As for the PIC code you link to: they don't mention any sort of fair benchmark anywhere, so if they are objectively "blowing things out of the water", they're rather silent about it.
I know less about Navier-Stokes solvers, but as far as I understand, it ends up as a linear system of equations that is far harder to parallelize.
Yeah, basically this. If the fluid is compressible, you get a hyperbolic system with only "local interactions", and this is fairly easy to parallelize on standard CPU clusters by using domain decomposition. People have scaled this to millions of cores, but it's not very GPU-friendly.
If the fluid is incompressible, the problem is technically a differential-algebraic equation with an index-two constraint. To solve this you use a splitting method that gives you an elliptic (Poisson) equation for the pressure. This is a major headache even with the fastest interconnects we have today (we're talking 40 Gbit/s links), since the pressure at one point depends on the pressure at all the other points in your domain in each time step. For single-phase flow, you can use Fourier transforms to speed this up, but for two-phase flow you're outta luck.
I can't get C code to behave the same from one release of the compiler to the next.
Thank goodness NASA uses Fortran.
With open specs, a simulator or emulator could be built, and anyone with interest could give it a try. A core team of NASA engineers might come up with some unit tests and acceptance tests. If these are passed, then the code is eligible for professional review.
AKA, if whoever gets the job at NASA is younger than the 50 Y/O's they are looking at, it should come with a pension, because getting the next job will be hard.
I don't understand why people have this mentality, because it's so wrong. We live in an era were kids can get jobs fresh out of high school after taking an eight-week crash course in programming an no other experience. Certainly a person capable of building robust software for NASA is capable of learning whatever platforms exist in 10 years.
I've never had two jobs with an overlap in work. I've done everything from embedded development to data science and analytics. Being an expert in many fields demonstrates that know how to become an expert.
Who the fuck is going to look at a resume with "last 10 years at NASA building shit for a MOTHERFUCKING DEEP SPACE PROBE" and go... nah, dude(tte) doesn't have node.js on his resume... NEXT!
Honestly, going from that kind of development to web development, "last 10 years" doesn't mean much -- they are essentially junior programmers again. Expect them to break things because they self-closed a script tag. Except them to break things because they forgot to set the button type to button and so some browsers POST. Heaven forbid you use tech where it doesn't default HTML and SQL escape. It's very very easy to forget the amount of extremely specific domain knowledge we all have that keeps things from imploding, and if they don't have it, their code doesn't hit production without a senior dev looking over it.
I can't speak to your current needs when hiring someone, but you're mistaken if you think I was assuming they can pick up web dev with no mistakes made.
An engineer who spent the last decade working on motherfucking space probes for NASA but can't hit the ground running with javascript today is going to be passed over for the kid right out of high school who can, in that case.
That said, if you worked for the last decade on space probes for NASA, you're probably smart enough to avoid web development altogether.
Usually, those things are seen as tools you use to solve problems. And the fun is in solving problems. Seriously the people getting all wrapped up in the node.js are just as bad as the stereotypical veterans that spent 30 years wrangling fortran on a PDP that haven't learned anything else.
I think "wrote software for a space probe while at NASA" is going to look pretty eye-catching on a resume.
We even rolled our own work balancing and coordination system based on NQS. The UNIX code was far faster due to hardware speedups and parallelizing the code but it was much more resilient as well due to our putting in checkpointing and restart and recovery logic into the work manager and code.
The project won a Silver Snoopy because we retired a Honeywell mainframe that was costing NASA $5 MM/yr in maintenance fees. I assume there was a guy or team of guys prepared to fabricate any component required at that price. :-)
Because I was a contractor working for a contractor I did not receive a Silver Snoopy. Trust me, I regularly look for those little guys on ebay because I'd love to have one. I'm still cheesed about it twenty years later.
Although it's a fun anecdote (and admittedly not nearly as cool as your example) I don't think it's garnered much more than a "that's cool" reaction from people. Probably too many other people running around Houston who've done similar things. If it would get me a job at Google I'd jump, but in a town full of ex-NASA employees it's nothing remarkable.
I really, really wish HN would be fair and go with the first post of a story, not the creatively-titled later submission.