A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Space Science » Technology
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

NASA orbit simulation software



 
 
Thread Tools Display Modes
  #11  
Old May 18th 09, 04:29 AM posted to sci.space.tech
Jorge R. Frank
external usenet poster
 
Posts: 2,089
Default 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  
Old May 18th 09, 04:29 AM posted to sci.space.tech
Jorge R. Frank
external usenet poster
 
Posts: 2,089
Default 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  
Old May 18th 09, 04:29 AM posted to sci.space.tech
Jorge R. Frank
external usenet poster
 
Posts: 2,089
Default 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  
Old May 18th 09, 03:42 PM posted to sci.space.tech
Pat Flannery
external usenet poster
 
Posts: 18,465
Default 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  
Old May 18th 09, 04:02 PM posted to sci.space.tech
Pat Flannery
external usenet poster
 
Posts: 18,465
Default 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  
Old May 18th 09, 07:19 PM posted to sci.space.tech
Pat Flannery
external usenet poster
 
Posts: 18,465
Default 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  
Old May 19th 09, 12:11 AM posted to sci.space.tech
Greg D. Moore \(Strider\)
external usenet poster
 
Posts: 2,865
Default 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  
Old May 19th 09, 12:12 AM posted to sci.space.tech
Greg D. Moore \(Strider\)
external usenet poster
 
Posts: 2,865
Default 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  
Old May 19th 09, 12:12 AM posted to sci.space.tech
Greg D. Moore \(Strider\)
external usenet poster
 
Posts: 2,865
Default 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  
Old May 19th 09, 02:18 AM posted to sci.space.tech
Kevin Willoughby
external usenet poster
 
Posts: 220
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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 11:37 PM
NASA seeks volunteers for a spaceflight simulation Jacques van Oene Space Station 8 December 21st 05 11:37 PM
Shuttle re entry simulation software? Christopher Policy 4 October 14th 03 05:38 PM


All times are GMT +1. The time now is 12:03 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.