There's still an active community writing tight assembly code for vintage computers like the C64, and there was a ton of excitement around Notch's 0x10c, which was a virtual computer of the same class as Voyager's. There's clearly a yearning among modern programmers for the days where the entire system could be understood by one brain.
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.
"There might some really good devs who would do it just for the challenge"
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.
The concept sounds cool, but what sort of fixes could the Voyager probes possibly need? They were launched in 1977, that's almost 40 years ago. As far as I know they're waking up every once in a while and sending telemetry back.
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.
The article says that part of the need to get programmers back in the project is to be able to get exact readings on the amount of energy that's being used and the amount left.
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.
It seems being a fortran/assembly programmer is just a small part of whats needed.
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).
That's not really fair or the entire picture, he announced very early then the internet community that built up around 0x10c got really demanding and the pressure on him was pretty huge so he stepped back, I was bummed by his decision but I could see why, it did get out of hand.
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.
> There's clearly a yearning among modern programmers for the days where the entire system could be understood by one brain.
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
PopMech makes it sound more arcane thane it might be: it's not that much out of the ordinary to know (or learn) assembly and Fortran or to have to work with computers that have 64K RAM (some modern microcontrollers have less[1]) I imagine it would be as hard as it sounds if they would require a specialist with years of experience in their particular dialect of Fortran and some particular assembler, expecting them to be productive right away. But it looks to me that they just have a peculiar setup and need someone who is able and willing to learn it - that's a situation plenty of companies have.
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.
I am 36, coding 3h a day in Fortran for the oil and gas industry. I must say, even if I write a lot of Python code too, I really enjoy the way a program is "optimized" by default, that is, if your algorithm is good, you do not need to do crazy things to get good performance out of your hardware.
Care to share any references on learning modern Fortran? I've tangled with some pretty ancient code (full of Hollerith constants and tangled mazes of GOTOs) but I get the impression there's a whole other world of Fortran out there.
I've found Metcalfe, Reid, and Cohen[1] to be a fairly clear refresher on Fortran. Unfortunately, the build tools I use don't support many of the nicer features like user-defined types.
Thanks for mentioning https://en.m.wikipedia.org/wiki/Hollerith_constant. It turns out that the Mac OS language extension to write 32-bit integers for file types and creator codes as, for example, 'TEXT' or 'FNDR', was inherited from fortran :-)
I always love to learn about stuff that has little to no use in real life (anymore).
I could not figure out what the heck they were for a while. When I figured it out, I felt like I'd just caught a coelocanth in a fishing net. There it was, making perfect sense in its prehistoric context, but completely out of step with the modern world. Same thing with the weird goto-based control flow. It was very disciplined and regular, but it didn't map to anything I'm used to.
I am not using a lot of modern Fortran, so what I learnt was more small things here and there distilled over the years. This is mainly because my code in Fortran is just the hard science, the resolution of equations, and it is then used as a library from within a larger simulation software.
I still find Hollerith constants in the code I work with some times to times :)
GCC has computed goto (e.g., do some pointer arithmetic, then jump to the address located at the pointer address), but I don't think that's in standard C.
Have you tried Julia? Optimized Fortran (esp. on specialized hardware) would still beat it no question, but IMO Julia is a better value proposition for Fortran/C programmers than it is for Python/Matlab programmers at the moment.
I tried a bit. My problem with Julia at the moment is that it really wants to be the master and not be embedded, some work on the way[0] but the goal is more to become a general scientific language than a high performance language in which one can write some scientific code and hook it into something less "powerful" like Python.
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 is widely used for scientific computing and in high performance computing some knowledge of assembly language is useful in making use of vector instructions - compiler auto-vectorisation still needs a lot of help.
Fortran and assembly language are key skills at every national supercomputing center in the world.
Really ? I thought people who need super computing performance have moved onto programming for the gpu with cuda c. Are people actually writing fortran or gpu assembly for the gpu outside nvidia ?
Ah, the GPU hype. Here's something the GPU vendors don't tell you: a huge part of scientific computing doesn't get any speedup at all from GPUs. A good example is fluid dynamics research, or essentially anything that boils down to solving PDEs or doing huge sparse linear algebra problems.
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
Well, no. There are fundamental algorithmic reasons why some problems can exploit GPU power and some cannot. Look at any of the ~15 most popular molecular dynamics codes today, they all have some sort of GPU support. Look up something that solves an elliptic PDE, like incompressible Navier-Stokes, and you'll see no-one using GPUs.
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.
The time-limiting step in molecular dynamics is a gigantic 3D fourier transform of the space containing the simulated atoms. This is relatively easy to parallelize provided you have fast communication between processors to synchronize data between between the timesteps.
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.
> 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.
How much can understanding assembly be understood as a skill? Most of the skill that goes into optimization isn't very architecture dependent but CPU and algorithm dependent.
I don't get why they need to hire someone that knows Fortran already. I'm sure any competent and versatile programmer would be able to learn quickly those technologies.
That is not how we do any more. You have to have the skill. That is why you have a college degree. You should have total knowledge of everything. You must be proficient too.
Given that the Voyager probes are pushing the absolute edge of humanity's reach into the cosmos, I'd love to see NASA publish the hardware specs and open up a competition to find the best possible solution.
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.
It's going to be hard to find a person with the right set of skills regardless of their age. One of the skills required is patience and another is absolute dedication to getting it right first time. Not a job for a Scrum enthusiast.
Yah, I'm not sure the assembly is the hard part (I know a couple engineers in their 20's that do just fine with assembly), or for that matter layering fortran on said engineers. The problem is that none of them will likely be interested in working on a piece of hardware for 10 years that effectively is a dead end. Its the same decision that I looked a couple years ago with regard to mainframe development. Its a dead end and the longer you stay there the less employable you will be for your next job.
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.
> Its a dead end and the longer you stay there the less employable you will be for your next job.
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, I have spoken to and worked with some of these engineers, and if they've been ten years deep on software that has no capacity for errors at all, they can be a bit difficult. Not just "I can't use that tool, it has a garbage collector", but when they are put in front of a frontend, they end up re-inventing basic things constantly, because they have absolutely no context.
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.
You hire an extremely smart, talented individual with some ramp up time, or pass on them for someone less talented (and less smart?) with less ramp up time.
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.
Someone who wants to hire a node.js programmer and doesn't want to overpay for expertise they can't use.
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.
lol the arrogance of a lot of people here is astonishing. The programmers I do know in the aerospace industry like dicking around with all kinds of stuff. I'm pretty sure any of the ones I'm thinking of could pick up node.js in a heartbeat if they had a reason to. :)
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.
Probably most nowadays, because IT is no longer primarily made of geeks, but out of sales and marketing people who think their next ad-exchange SaaS platform for 3D-printed kitten cloud computing solutions is The Best Thing, and space probes? "Space? Yeah, there's something like that, they put it in movies sometimes, but who really cares about it?"
Possibly true if you're trying to get a job for an ad-exchange SaaS platform like you mention. But is that really where you'd go next after significant experience doing low-level, high-assurance programming at NASA? There are plenty of other parts of the tech industry whose hiring managers would appreciate that experience a lot more. For example, any kind of embedded-systems job, or even most "regular" programming jobs in more engineering-oriented industries like energy and aerospace.
I ported the Fortran and assembly code to 'C' for computing stress on orbiter (aka the space shuttle) based on winds aloft data. We received the data from a weather balloon sent up on launch day.
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.
Some computational physics courses in parts of Canada are still taught in Fortran90. I also worked in a lab (in 2005) which still used 5 1/4" floppy disks. The difference between these and NASA, of course, being choice.
Yes. A good friend of mine still uses FORTRAN regularly for scientific computing, and has worked at supercomputing centers all over the world (NCSA, ORNL, IVEC in Australia, LBNL...). She just got her PhD around 2006-2007-ish, so it's not like she's ancient, either.
crowdsource it. there are thousands of programmers
that would love to help, let alone audit the result.
and even more that would love to write the sims.
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.