SpaceX Falcon 9/Dragon COTS Demo (C2+) GENERAL DISCUSSION

[baldusi]

When doing econometrics (and statistics in general), I've found out you have to get a good understanding of everything. You can get away witht eh epsilon problem and iterative formulas, but you have to demonstrate that your matrices are stable, for example. You might use Monte Carlo integration, but when working on an "infinite" set and using something like 1/random() to sample, you don't get a uniform function, you have to correct, etc.
At the same time, doing straight matrix multiplication without doing some reductions is criminal. And ordering your data to avoid cache trashing is fundamental.
That's why the best open source econometric software, is made by an econometrist that learned to program. But he did got a lot of help from academy in correcting its model, and from programmers in optimizing the code path. In my experience, the optimization have a lot more to do with correct data alignment, good use of indices, correct understanding of the limitation of your data types, good judgment on balancing the overflow risk with the quantification losses and above all, robust error checking. I guess that's sort of applicable to any scientific code.

[Lurker Steve]

Companies that develop technical software tend to learn the hard way that they shouldn't hire electrical engineers to write software. They should hire software developers to write software, just as they have to hire technical writers to write manuals, not electrical engineers. Cross-training is possible / valuable / important, but pretending one professional can do another professional's job without training is ridiculous.

+1000

The problem is that real time SW development is difficult. Most people don't know what it is.

Also, the software guys usually are the last ones to see the real hardware, and have to adjust for any changes that mechanical and electrical made in their designs. The most difficult part of the process is trying to anticipate when the hardware is going to break, or be slightly out of spec, and then decide how you are going to handle the exceptions.

[Jorge]

More precisely, the NASA software folks working MCC interfaces don't know C++. They don't need to; it's all C and Fortran.

FORTRAN? Whoa! Do they still use those 5 inch floppies too?

There have been various proposals to re-engineer the remaining FORTRAN code in C++. In the past, they've all failed because it's always turned out to be much cheaper to rehost the FORTRAN code to new platforms as long as the platforms support the compilers (and with the platform being Linux, one can always just install the GNU gfortran package even if the distro stops including it). Much easier to test and validate. GUI front-ends are straightforward to develop. And the workforce knows FORTRAN well.

The current re-engineering effort (MCC21) seems likely to go through, if only because it's NASA's last chance to do it before the FORTRAN-savvy workforce retires. New CS graduates don't learn a lot of FORTRAN these days.

[Oberon_Command]

No C++? What do they use, Ada?

A mere ten years ago, when I did some realtime system programming, C++ was considered the wrong tool for the job.. of course, the C99 standard hadn't completely smothered the C language with uncertainty and doubt yet... it was a different time.

Not to get too off-topic, but C++ has come a long way since then. Back in 2002 there weren't all that many compilers that were even moderately standards compliant, since the standard had only been released in 1998. Not only that, but a lot of compilers weren't all that great at optimizing the features they had that were standards-compliant. Modern C++ compilers are much better at that sort of thing. I wouldn't be surprised at all if a lot of shops were just starting to migrate now.

New CS graduates don't learn a lot of FORTRAN these days.

For CS students, yes, but there are still some universities that teach Fortran to their engineering students. I'm pretty sure McGill (in Canada) still does, or did a few years ago, since someone I know from high school went there and mentioned having to learn it.

[tigerade]

Q&A session today at 2PM on Twitter with Elon Musk.

#APSpaceChat

[kevin-rf]

I have a thirty something brother-inlaw who is employed full time writing in COBOL, so declaring a "modern" language like FORTRAN dead...

Of course I am very partial to Forth, it is a great embedded language for machine control.

SpaceX is writing with the tools that they feel are best for the job at hand.

[kevin-rf]

Q&A session today at 2PM on Twitter with Elon Musk.

#APSpaceChat

Can I be a cynic and wonder if this is a PR move to steal some of ULA's Atlas V thunder this afternoon?

[tigerade]

Q&A session today at 2PM on Twitter with Elon Musk.

#APSpaceChat

Can I be a cynic and wonder if this is a PR move to steal some of ULA's Atlas V thunder this afternoon?

The answer is probably no because most people outside of NSF are unaware that there is a Atlas V launch this afternoon.

[mmeijeri]

There have been various proposals to re-engineer the remaining FORTRAN code in C++. In the past, they've all failed because it's always turned out to be much cheaper to rehost the FORTRAN code to new platforms as long as the platforms support the compilers (and with the platform being Linux, one can always just install the GNU gfortran package even if the distro stops including it).

Heh, I once worked on the redesign of a multi-phase flow simulator that had originally been written in Fortran, had then been run through f2c, had then been fixed up a bit by hand, and had then had some features added to it for a couple of years. It took a lot of work to convert this to more or less idiomatic C++, but it can be done.

[oldAtlas_Eguy]

There have been various proposals to re-engineer the remaining FORTRAN code in C++. In the past, they've all failed because it's always turned out to be much cheaper to rehost the FORTRAN code to new platforms as long as the platforms support the compilers (and with the platform being Linux, one can always just install the GNU gfortran package even if the distro stops including it).

Heh, I once worked on the redesign of a multi-phase flow simulator that had originally been written in Fortran, had then been run through f2c, had then been fixed up a bit by hand, and had then had some features added to it for a couple of years. It took a lot of work to convert this to more or less idiomatic C++, but it can be done.

Its a matter of no funds, not that it can't be done.

[mmeijeri]

Its a matter of no funds, not that it can't be done.

Yeah, just sharing a war story.

[Prober]

Moved a couple of posts into the General Discussion thread.

I think when we get a new launch date we might need a new thread for pre-launch updates. Amazing amount of interest in this mission, with mega long threads and such! It's like shuttle days (huzzah!)

It's currently NET May 10, by nature, but that's not yet set until they have their next meetings (tonight and/or tomorrow I'm told). I'll give it a new article when they do.

Totally unofficial, but the calculated next launch date that they would announce would probably be around May 19-20th based on the pace of their previous launch date slips.  But I'd still expect all this to slip to July 4th... No technical/programmatic issues are known, just a pure analysis of slippage of this launch over time.

Forget about July 4th.  Remember the HTV flies on the 21st of July.

[Jorge]

There have been various proposals to re-engineer the remaining FORTRAN code in C++. In the past, they've all failed because it's always turned out to be much cheaper to rehost the FORTRAN code to new platforms as long as the platforms support the compilers (and with the platform being Linux, one can always just install the GNU gfortran package even if the distro stops including it).

Heh, I once worked on the redesign of a multi-phase flow simulator that had originally been written in Fortran, had then been run through f2c, had then been fixed up a bit by hand, and had then had some features added to it for a couple of years. It took a lot of work to convert this to more or less idiomatic C++, but it can be done.

Its a matter of no funds, not that it can't be done.

Exactly. And machine-translated code is a bitch to maintain in the long run.

[Airlock]

Sure is, I worked on mainframe to C# machine-converted code at Kennedy, what a pain!

[Antares]

1) Don't forget about the dedicated SpaceX software thread http://forum.nasaspaceflight.com/index.php?topic=28611.msg893373#msg893373

2) The hard part in most software writing is bridging the gap between the hardware engineers who own the parts that the software is controlling and the coders.  The coder can build perfect code that doesn't do what the valve engineer really wanted.

3) IMO, one of the hardest parts of aerospace management is that some of its skills are common to many other fields, which often pay better.  Coders and good analysts in all areas (thermal, structural dynamics, stress, even RF/EMI) and avionics engineers can get paid better in other industries.  Aerospace either gets those passionate about aerospace or the middle-round picks not the lottery picks.  Even hiring ENOUGH qualified people, let alone high performers, can sometimes be hard.

[Robotbeat]

It should also be pointed out that quality of code >> quantity of code.

Lines of code is a useless metric for paying someone to write avionics software (except as a very, very rough gauge of complexity... and ideally, you'd want something in fewer rather than more lines of code because unless the code becomes obfuscated by trying to make it shorter, you're less likely to make a mistake when writing and debugging a page of code versus 10 pages of code).

[IRobot]

It should also be pointed out that quality of code >> quantity of code.

Lines of code is a useless metric for paying someone to write avionics software (except as a very, very rough gauge of complexity... and ideally, you'd want something in fewer rather than more lines of code because unless the code becomes obfuscated by trying to make it shorter, you're less likely to make a mistake when writing and debugging a page of code versus 10 pages of code).

Lines of code is a terrible metric. I've used cyclomatic complexity for years, among other metrics. Doesn't matter how big it is, what matters is how risky and complex it is.

[oiorionsbelt]

1) Don't forget about the dedicated SpaceX software thread http://forum.nasaspaceflight.com/index.php?topic=28611.msg893373#msg893373

 

[Space Pete]

Totally unofficial, but the calculated next launch date that they would announce would probably be around May 19-20th based on the pace of their previous launch date slips.  ut I'd still expect all this to oslip to July 4th... No technical/programmatic issues are known, just a pure analysis of slippage of this launch over time.

Forget about July 4th.  Remember the HTV flies on the 21st of July.

July 4th would not be possible due to the fact that Soyuz TMA-03M will undock and land on July 1st, leaving only one USOS crewmember (Joe Acaba) on the ISS, while two are required for Visiting Vehicle captures.

The USOS crew won't be boosted back up to three until the arrival of Soyuz TMA-05M on July 17th - and then as Prober mentioned, HTV-3 launches only four days later, leaving insufficient time for Dragon to launch on July 18th and berth by July 20th. HTV-3 won't be captured and berthed to the ISS until July 27th, meaning Dragon wouldn't be able to launch until after then.

However, as I explained in this post, having Dragon arrive at the ISS while HTV-3 was present would present problems, since HTV-3 would occupy Dragon's berthing port (Node 2 Nadir). This means HTV-3 would need to be relocated to Node 2 Zenith prior to Dragon's arrival.

(For reference: As explained in the linked post above, neither HTV-3 nor Dragon could be berthed directly to Node 2 Zenith due to SSRMS reach issues - all Visiting Vehicles must first be berthed to Node 2 Nadir, then wait for an SSRMS base change from Node 2 to the MBS, before being relocated to Node 2 Zenith.)

So, factoring in the post-arrival HTV-3 relocation to Node 2 Zenith (which would have to occur in the days after HTV-3's berthing on 27th July) - which would be a Launch Commit Criteria for Dragon - we'd likely be looking at a very late July/early August launch for Dragon.

Now, again as explained in the linked post above, Visiting Vehicles cannot be directly released from Node 2 Zenith - they must first be relocated from Node 2 Zenith to Node 2 Nadir, wait for an SSRMS base change, then be released from Node 2 Nadir. This means HTV-3 would have to move back to Node 2 Nadir in the days prior to its planned August 27th departure - which means Dragon would have to vacate Node 2 Nadir prior to the HTV-3 relocation to there. This means, assuming a late July/early August launch date, the C2+ mission would need to be complete by NLT August 26th or thereabouths - meaning there would not be much margin for a C2+ mission extension if more on-orbit checkouts or troubleshooting were needed.

If Dragon had to wait until after HTV-3 left ISS on August 27th, the launch would likely again be delayed by the planned September 3rd departure of the ATV-3. All this means that if Dragon doesn't go off in May (looking increasingly unlikely) or June (which I think may have some beta angle cutouts), then we could potentially be looking at an early September launch date for Dragon.

This is all just speculation of course, but it's interesting to lay out all the Visiting Vehicle dates and see how Dragon could fit in - it's tight, at best. And that's without factoring in things like ISS EVAs (of which there are two in August), available launch dates, range conflicts, and beta angle cutouts.

[robertross]

Great explanation Pete. Very unfortunate set of circumstances, not only for SpaceX, but for the crews & the IP's waiting for CRS to get going.