|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
NASA orbit simulation software
OM wrote:
On Sat, 16 May 2009 08:19:52 EDT, "Jorge R. Frank" wrote: There's no one answer to the first question; every NASA center has its own trajectory analysis software. NASA does use POST quite a bit but it is not the only program used. ....Is there a specific reason for this, such as a NIH prejudice, God/Yahweh/Roddenberry forbid? Or is it a case as with different State agencies, some of which use Word, others still use WordPerfect 20 years after it was clusterfracked? Neither. There are several factors involved. The most important is that a true "simulator" must simulate not just the trajectory, but the vehicle's interaction with the trajectory. That in turn means that the simulator must include models specific to the vehicle being simulated. A shuttle sim must include, for example, at least a rudimentary representation of the shuttle's guidance, navigation, and control system. Higher fidelity sims require higher fidelity representations. STAMPS, for example, has a full implementation of the shuttle's GNC software, machine-translated from HAL/S to C. For that reason, STAMPS cannot be exported outside of NASA and its contractor community (the shuttle's flight software is ITAR-restricted). Next, even for the environmental models, consider that each center has different requirements for those models. JPL does a lot of interplanetary work so their simulators have very high-accuracy planetary ephemerides, for example. JSC does a lot of work close to Earth so they really don't care about the planets, but their simulators have very high-fidelity Earth atmosphere models that JPL doesn't need since their spacecraft don't spend any time in the Earth's atmosphere once they're released from the launch vehicle. You might respond that the answer is for NASA to create some kind of "super-sim" that meets all the centers' requirements. But consider that NASA has been doing this work for five decades and most of NASA's sims consist of legacy code going back 3-4 decades, largely coded in languages that don't facilitate modular re-use. At the time they were coded, there was no alternative to this. Each center came to have a workforce with expertise in the particular sims they were using. Today, there are computer languages that facilitate modular reuse, but the existing sims would have to be completely re-engineered from the ground up in those languages. While this would yield downstream benefits in code maintenance and reusability, the upfront cost of re-engineering the existing sims from the ground up - and then validating them - in order to take advantage of these languages would be colossal. And NASA operates in an annual-budget constrained environment. It is therefore always cheaper to update the legacy code - especially since each center has people who know that legacy code intimately and can update it in a relatively efficient fashion - rather than start over from square one. The only opportunities for making the leap to newer software architectures come at program boundaries, which are fairly infrequent. While JSC would never consider tearing apart its existing shuttle sims so close to the end of the program, they do intend to use JPL's planetary ephemerides in its Constellation sims. |
#12
|
|||
|
|||
NASA orbit simulation software
Joćo Gomes wrote:
On May 16, 1:19 pm, "Jorge R. Frank" wrote: Joćo Gomes wrote: Hey.. Does anyone knows what programs does NASA use to simulate and predict the orbit of a spacecraft? and for simulate the reentry phase of the shutle and from now on orion? There's no one answer to the first question; every NASA center has its own trajectory analysis software. NASA does use POST quite a bit but i t is not the only program used. Regarding the second question, NASA/JSC uses the Descent Design System (DDS) and Spacecraft Trajectory and Mission Planning Simulator (STAMPS ) to simulate space shuttle entries. And STAMPS can be used with different vehicles? No. It is shuttle-specific. Is there any change to purchase or to have that software for a project my university is developing? No. STAMPS contains a HAL-to-C translation of the shuttle's onboard flight software, which is restricted by ITAR. |
#13
|
|||
|
|||
NASA orbit simulation software
Pat Flannery wrote:
OM wrote: ....Is there a specific reason for this, such as a NIH prejudice, God/Yahweh/Roddenberry forbid? Or is it a case as with different State agencies, some of which use Word, others still use WordPerfect 20 years after it was clusterfracked? Boy, you got me on that one also. Jorge seems to think this is all rational and normal somehow. I guess after you work for NASA for enough years, just about anything and everything would seem "rational" and "normal", or at least "SNAFU". ;-) Now, if they all standardized on "Buzz Aldrin's Race Into Space" for figuring these things out, a lot of confusion could be removed between the various space centers. :-) Congratulations, Pat. You're the first person I've killfiled on s.s.tech. I had intended to keep the killfile clear, figuring that any post of yours that got past the moderators couldn't be too stupid. Guess I was wrong. Bye now. |
#14
|
|||
|
|||
NASA orbit simulation software
Fred J. McCall wrote:: Not necessarily, Pat. There are lots and lots of different factors involved and different simulations may be better in different areas, so that sometimes one simulation works better and sometimes another does. So there may be no 'best' one and cherry picking from each one to make a 'best' one is not a simple task. Well, one obvious way to check would to have each of the programs predict exactly where a satellite will end up given its input data before it is launched, then compare that to what actually happens after it is launched. Do that for several launches, and you should be able to figure out which program gives the best data. If they are each predicting some aspect of its orbit better than the others...then it's time to write a new program that incorporates the best aspects of each of the competing programs and standardize on it. Pat |
#15
|
|||
|
|||
NASA orbit simulation software
OM wrote: ....Jorge, I thought Pat was really just joking with that one. Would it do any good to ask if you'd give him a second chance? No, I was not joking, and here's why: If each of the NASA space centers were using multiple programs to determine how a satellite's orbit would end up... and they were all using the _same_ programs, that would be great; as they could spot something suspicious in the the solution one program showed if it varied from the rest, and look into that aspect in more detail. But having different space centers using different programs to try to figure out the same thing is bound to cause communications problems if one program comes up with a different solution than the others, and they want to figure out _why_ that occurred. Then people at two or more different NASA centers have to discuss matters in regards to two or more different programs that they each are not familiar with, as it's not the one they use at "their" space center. At the very least that is going to cause inconvenience...at worst, it could cause misunderstandings between the two centers that could cause a mission to get screwed up...in much the way the Mars Polar Orbiter mission did as two separate teams had two different understandings of where the spacecraft was and where it was going in relation to the atmosphere of Mars. Pat |
#16
|
|||
|
|||
NASA orbit simulation software
OM wrote: ....Agreed. Which begs the question as to what ESA is using to compute the same orbital data. Sound German engineering?: http://en.wikipedia.org/wiki/Curta_calculator (Cut to image of ESA headquarters...a dull grinding noise fills the air as hundreds of French mathematicians crank their Curtas like so many pepper mills, after training at the Cordon Bleu to develop the arm strength needed for hours of steady computation.) ;-) I think we can safely assume the Chinese use something stolen from one of NASA's "secure" websites. Pat |
#17
|
|||
|
|||
NASA orbit simulation software
"Pat Flannery" wrote in message
lephone... Fred J. McCall wrote:: Not necessarily, Pat. There are lots and lots of different factors involved and different simulations may be better in different areas, so that sometimes one simulation works better and sometimes another does. So there may be no 'best' one and cherry picking from each one to make a 'best' one is not a simple task. Well, one obvious way to check would to have each of the programs predict exactly where a satellite will end up given its input data before it is launched, then compare that to what actually happens after it is launched. That assumes they're all used for the same thing. Something used for Earth orbit simulation is probably very different from one used to for launching to a Lagrange point. Heck, I could see a sim used for a LEO sat would need to be different than a sim for a GEO sat. Do that for several launches, and you should be able to figure out which program gives the best data. If they are each predicting some aspect of its orbit better than the others...then it's time to write a new program that incorporates the best aspects of each of the competing programs and standardize on it. But to what real advantage. Now if you change the app to improve one area, you need ot confirm it in all areas. Sometimes having separate programs IS the best approach. Pat -- Greg Moore Ask me about lily, an RPI based CMC. |
#18
|
|||
|
|||
NASA orbit simulation software
"Pat Flannery" wrote in message
dakotatelephone... OM wrote: ....Agreed. Which begs the question as to what ESA is using to compute the same orbital data. Sound German engineering?: http://en.wikipedia.org/wiki/Curta_calculator I want one of these someday! (Cut to image of ESA headquarters...a dull grinding noise fills the air as hundreds of French mathematicians crank their Curtas like so many pepper mills, after training at the Cordon Bleu to develop the arm strength needed for hours of steady computation.) ;-) I think we can safely assume the Chinese use something stolen from one of NASA's "secure" websites. Pat -- Greg Moore Ask me about lily, an RPI based CMC. |
#19
|
|||
|
|||
NASA orbit simulation software
"Pat Flannery" wrote in message
dakotatelephone... OM wrote: ....Jorge, I thought Pat was really just joking with that one. Would it do any good to ask if you'd give him a second chance? No, I was not joking, and here's why: If each of the NASA space centers were using multiple programs to determine how a satellite's orbit would end up... and they were all using the _same_ programs, that would be great; as they could spot something suspicious in the the solution one program showed if it varied from the rest, and look into that aspect in more detail. Umm, no. If they are using hte same software and put in the same inputs, they'd see the same outputs. Software is very deterministic that way. If they DO see something different, it's a hardware issue, not a software issue. If you really want to test the answer, you calculate it two DIFFERENT ways. But having different space centers using different programs to try to figure out the same thing is bound to cause communications problems if one program comes up with a different solution than the others, and they want to figure out _why_ that occurred. You're assuming that they are trying to figure out the same thing. (which given NASA is a bureaucracy may be true, but is not generaly the goal). Then people at two or more different NASA centers have to discuss matters in regards to two or more different programs that they each are not familiar with, as it's not the one they use at "their" space center. At the very least that is going to cause inconvenience...at worst, it could cause misunderstandings between the two centers that could cause a mission to get screwed up...in much the way the Mars Polar Orbiter mission did as two separate teams had two different understandings of where the spacecraft was and where it was going in relation to the atmosphere of Mars. Pat -- Greg Moore Ask me about lily, an RPI based CMC. |
#20
|
|||
|
|||
NASA orbit simulation software
Mike Beede wrote:
On problem with solving something like this is that you have to test the results to see if they're correct. A good--though expensive--way to do that is to have multiple versions of the program each developed independently, and compare their results. That works much less well that you'd think. It would be facile to say that different development teams all make the same mistakes, but this happens surprisingly often. Every good QA engineer knows about "buffer overruns", "off-by-ones", "numeric overflow", "unverified user input", "deadlocks" and a dozen other mistakes often made by programmers. The topic has been seriously studied. To make n-version programming have any value, you have insure the various teams have very different types of people, different management philosophies, and significantly different specifications. (NASA did this with the primary and backup Shuttle flight control software.) After all of this, we come back to your point about then having to test the various versions and when they disagree, figure out which one (if any) is correct. If two of three versions agree, that doesn't mean those two are correct. The actual value of n-version programming has been studied in depth by Nancy Levenson. You might want to look up her papers. -- Kevin Willoughby lid It doesn't take many trips in Air Force One to spoil you. -- Ronald Reagan |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
NASA orbit simulation software | Joćo Gomes | Space Shuttle | 0 | May 14th 09 02:45 PM |
NASA seeks volunteers for a spaceflight simulation | Jacques van Oene | Space Shuttle | 8 | December 21st 05 10:37 PM |
NASA seeks volunteers for a spaceflight simulation | Jacques van Oene | Space Station | 8 | December 21st 05 10:37 PM |
Shuttle re entry simulation software? | Christopher | Policy | 4 | October 14th 03 05:38 PM |