NASA orbit simulation software
João Gomes
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?
João Gomes
> On Thu, 14 May 2009 10:20:18 EDT, in sci.space.tech Jo�o Gomes
>
> https://post2.larc.nasa.gov/
Hey, thanks...
but this link doesn't work.. can it be because i'm trying to open it
from portugal?
Jorge R. Frank
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.
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.
João Gomes
> On Fri, 15 May 2009 07:08:53 EDT, in sci.space.tech Jo�o Gomes
>
>
>
> <joao....@gmail.com> wrote:
> >On May 14, 10:39 pm, m...@mine.net wrote:
> >> On Thu, 14 May 2009 10:20:18 EDT, in sci.space.tech Jo�o Gomes
>
> >> <joao....@gmail.com> 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?
>
> >> I believe that would be POST2:
>
> >>https://post2.larc.nasa.gov/
>
> >Hey, thanks...
>
> >but this link doesn't work.. can it be because i'm trying to open it
> >from portugal?
>
> s
> working on govt projects.
And is there any cance to get the program? or a similar one?
João Gomes
And STAMPS can be used with different vehicles?
Is there any change to purchase or to have that software for a project
my university is developing?
Pat Flannery
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.
Boy, _that_ could never lead to a problem, could it? :-D
You read that, and the Mars Polar Orbiter showing up a bit low in its
approach to the planet's atmosphere isn't that big of a surprise, is it?
Talk about potential misunderstandings cropping up as several separate
computer programs try to figure out what something is supposed to do in
detail, and all the space centers try to compare the math from _their_
individual computer program simulations.
One computer program has got to be the most accurate in figuring this
all out, and all NASA centers should use that one, so at least they
could all be on the same page at the same time.
You read something like you just wrote, and frankly you couldn't even
make that sh*t up in a Monty Python sketch.
Pat
* i
Pat Flannery
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. :-)
Pat
Fred J. McCall
:
:One computer program has got to be the most accurate in figuring this
:all out, ...
:
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.
--
"The reasonable man adapts himself to the world; the unreasonable
man persists in trying to adapt the world to himself. Therefore,
all progress depends on the unreasonable man."
--George Bernard Shaw
Mike Beede
<N_CdndJTDZlwNZLX...@posted.northdakotatelephone>,
Pat Flannery <fla...@daktel.com> wrote:
> Talk about potential misunderstandings cropping up as several separate
> computer programs try to figure out what something is supposed to do in
> detail, and all the space centers try to compare the math from _their_
> individual computer program simulations.
> One computer program has got to be the most accurate in figuring this
> all out, and all NASA centers should use that one, so at least they
> could all be on the same page at the same time.
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. If you solve for the trajectory you want and get
three different answers, then you know you have a problem
before you wreck an expensive piece of hardware.
This is similar to the old "add the numbers until you get the
same answer twice" algorithm we're familiar with from grade
school, except a given program will always (hopefully) get
the same answer given the same inputs, so you need different
programs.
I see another poster mentioned that different programs are good
at different problems. That seems reasonable too.
Mike Beede
Ken S. Tucker
> Pat Flannery <flan...@daktel.com> wrote:
>
> :
> :One computer program has got to be the most accurate in figuring this
> :all out, ...
> :
>
> 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.
Pat I think Fred's right, in my limited experience with sims.
One would need 100,000's of different variables in one overall
program.
Just as a simplistic overview...
1) Rocket pre-launch soft/ware.
2) Rocket flight s/w, earth relative navigation.
3) Orbital s/w, earth relative with solar lunar tidals.
4) If you want to extract a LM, that's a specialized
s/w sub-routine.
5) Translunar injection, to lunar orbit, is celestrial
navigation.
6) Softlanding on the moon, is lunar relative, with
thruster control s/w.
Most of those routines need to pass data to other
routines, so they end up being sub-routines, so
in that sense it could be considered as one big s/w
program.
A problem when writing s/w is remembering what
the variables stand for, for example, Pitch. Yaw,
Roll, depend on the applicable spacecraft, so
once (1) and (2) are done, we don't need those
variables in (3), nor do we need those routines.
S/w systems design and management needs to be
compartmentalized into Block Diagrams, then in
each Block is a Block Diagram and so forth.
Regards
Ken
Jorge R. Frank
> On Sat, 16 May 2009 08:19:52 EDT, "Jorge R. Frank"
> <jrf...@ibm-pc.borg> 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.
>
> 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.
Jorge R. Frank
> On May 16, 1:19 pm, "Jorge R. Frank" <jrfr...@ibm-pc.borg> 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.
Jorge R. Frank
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.
Pat Flannery
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
Pat Flannery
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
Pat Flannery
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
Greg D. Moore (Strider)
news:HL-dnVC2UPWG7IzX...@posted.northdakotatelephone...
>
>
> 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.
Greg D. Moore (Strider)
>
>
> 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 D. Moore (Strider)
>
>
> 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
>
--
kevin willoughby
> 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 kevinwi...@acm.org.invalid
It doesn't take many trips in Air Force One
to spoil you. -- Ronald Reagan
Fred J. McCall
:
:Fred J. McCall wrote::
You're not paying attention, Pat. "... and cherry picking from each
one to make a 'best' one is not a simple task."
--
Pat Flannery
OM wrote:
>
> ....Jorge, I thought Pat was really just joking with that one.
>
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 Climate 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
======================================= MODERATOR'S COMMENT:
(if anyone sees the previous message, which Pat has since cancelled, this is a correction to that message, not a duplicate.) GDM
Pat Flannery
Greg D. Moore (Strider) wrote:
>>
>> Sound German engineering?: http://en.wikipedia.org/wiki/Curta_calculator
>
> I want one of these someday!
It sure would be fun to play with one, but for God's sake don't make the
mistake of taking it apart to find out how it works...as apparently
everyone who ever did that never managed to get it back together again
correctly, as it's around as complex as a Swiss watch internally.
There's more data on them here: http://www.vcalc.net/cu.htm
Including cutaways of the inner workings and a simulator of one.
To get this back on-topic, it would be interesting to know what
timeframe the orbit simulation programs that NASA uses come from.
Are they fairly recent, or do they go back into the early days of
computing, and have now been adapted for today's computers?
You start figuring in all the variables that go into a satellite's
ascent into orbit and its expected orbital elements over a period of
time once it reaches that orbit...and it must be a real mess as far a
variables to enter into the equations go.
Drag caused be different atmospheric densities due to temperatures and
humidity variables in the atmosphere during ascent will affect it*, and
once it is on-orbit its path will be changed by passing over areas of
the Earth with subtly different gravity fields, and altitude changed by
variable drag resulting from the heating of the upper atmosphere from
solar activity.
* Minuteman III MIRVs had three different settings to select from
regarding the expected weather over their targets on their arrival, so
that they would use slightly different reentry paths in rain or in snow
than they would in clear weather.
Pat
Pat Flannery
Greg D. Moore (Strider) wrote:
>
> Umm, no. If they are using hte same software and put in the same
> inputs, they'd see the same outputs.
Ah, but that's where the fun comes in...each center has to figure out
those inputs on its own. That's how you find errors in the input data.
>
> 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.
Yeah, but Jorge seemed to imply that each center had "its" favored
program and wasn't going to use the one used by the other center(s).
So if you end up with two different outcomes from two different
programs, then you know something is obviously wrong, but what exactly
and in which program run? Was it a faulty input of information or did
the program deal with those particular inputs in a way that led to a
incorrect answer?
That's where the real mess would start, as center "a" doesn't have much
experience with the program center "b" is using and vice-versa.
>
>> 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).
It might be a very good idea to have them try to figure out the same
thing, and see if their answers agree.
Extra math work is pretty cheap compared to the cost of a spacecraft and
its booster.
A real-world example of this occurred in the Soviet space program.
The math whiz-kids back in Moscow would send the specs to Baikonur of
what launch trajectory a booster was to use and what propellant load was
needed for it to put its payload into the desired orbit.
As one launch approached, one of Korolev's assistants looked at the
incoming figures on the amount of propellant to be loaded on a specific
launch, and they didn't look right to him based on past experience with
other launches and the weight of the payload that would be carried. The
payload would not reach orbit due to too little propellants being carried.
He ran through the math several times and still kept coming up with a
different answer than what Moscow was telling them, so finally went to
The Chief Designer and told him there was a problem.
Korolev asked him if he was _completly sure_ a mistake had been made, as
one didn't question orders without a very good reason, and this could
mean delaying the launch.
The assistant stuck to his guns, and Korolev called Moscow and demanded
that they double-check their math, although headquarters was not used to
being talked back to.
The assistant felt like his head was on the chopping block as first one
and then another hour passed with no return call from headquarters.
Finally, a call came in... there had indeed been a "small" error in the
amount of propellants to be loaded and new figures were sent to
Korolev...which agreed exactly with those the assistant had found with
his math work.
Not only was the launch now saved by the assistant's hunch and boldness
in bringing it to Korolev's attention, but The Chief Designer now had
something to rub Moscow's nose in if they ever gave him trouble about
planning a mission.
The assistant got his own private dacha out of that incident.
Having two separate teams figure out the same information in two
different ways via original information inputs that they themselves had
to determine would be a great idea; but each team should be completly
conversant with the method the other team is using so they can quickly
find the problem if the two end results differ significantly.
Pat
Pat Flannery
kevin willoughby wrote:
> If two of three versions agree, that doesn't mean those two are correct.
Though in this case you do get feedback by observing where exactly the
satellite's orbit ended up in reality versus what one or more programs
predicted.
Subtle problems in a program may not manifest themselves fully until
something in the program is pushed out to the edge of its abilities.*
Tell them to figure out the launch trajectory into a orbit with a apogee
of 500 miles and a perigee of 450 miles and most all of the programs
will probably give you almost the same exact answer.
Toss one with a apogee of 1,000,000 miles and a perigee of 50 miles at
them and have them figure in the influence of the gravity of the Moon
and Sun during each orbit, as well as air drag at the perigee and that's
influence on future orbits...and I'll bet different answers start to
emerge from different programs.
* A tragic example of this was trying to use the "Crater" program to
determine the probable impact damage Columbia suffered, even though
"Crater" was never designed to deal with foam impacts of that severity.
Pat
Derek Lyons
>It might be a very good idea to have them try to figure out the same
>thing, and see if their answers agree.
>Extra math work is pretty cheap compared to the cost of a spacecraft and
>its booster.
>A real-world example of this occurred in the Soviet space program.
It's a very nice real world example, other than the niggling detail of
having exactly nothing to do with the real world and only being
relevant to the nonexistent problem you are handwaving into existence.
You seemed to have missed that the different centers have different
software _because they have different needs_. A Shuttle will never
crash because JPL neglected to check JSC's results. A Jovian probe
will never miss because JSC neglected to check JPL's results.
D.
--
Touch-twice life. Eat. Drink. Laugh.
http://derekl1963.livejournal.com/
-Resolved: To be more temperate in my postings.
Oct 5th, 2004 JDL
Ken S. Tucker
> kevin willoughby wrote:
> > If two of three versions agree, that doesn't mean those two are correct.
>
> Though in this case you do get feedback by observing where exactly the
> satellite's orbit ended up in reality versus what one or more programs
> predicted.
> Subtle problems in a program may not manifest themselves fully until
> something in the program is pushed out to the edge of its abilities.*
> Tell them to figure out the launch trajectory into a orbit with a apogee
> of 500 miles and a perigee of 450 miles and most all of the programs
> will probably give you almost the same exact answer.
> Toss one with a apogee of 1,000,000 miles and a perigee of 50 miles at
> them and have them figure in the influence of the gravity of the Moon
> and Sun during each orbit, as well as air drag at the perigee and that's
> influence on future orbits...and I'll bet different answers start to
> emerge from different programs.
The physics of the scenario is pretty much known, and
programmable, to levels of accuracy depending on including
tinier and tinier factors being placed into the program.
Also, skirting the atmosphere has a degree of randomness
such as a Bell curve between error bars because the
atmosphere fluctuates unpredicatably, but that is why
course corrections are expected.
Even small things like a change in the mass of polar
ice will affect Ballistic trajectories, which I think is referred
to in mil-speak as CEP for ICBM's.
A famous NASA unprogrammed anomaly is this one,
http://en.wikipedia.org/wiki/Pioneer_anomaly
where s/c navigation is concerned, involving a high speed
hyperbolic orbit.
Regards
Ken S. Tucker
Fred J. McCall
:
:Having two separate teams figure out the same information in two
:to determine would be a great idea; but each team should be completly
:conversant with the method the other team is using so they can quickly
:find the problem if the two end results differ significantly.
No, this is pretty much what you do NOT want, since if Team A is
intimately familiar with Approach X that is going to condition their
approach. You want the teams TOTALLY independent if you're trying to
do something other than have someone 'check the math'. The latter can
be done without having two groups and two approaches, but won't find
some classes of errors.
--
"It's always different. It's always complex. But at some point,
somebody has to draw the line. And that somebody is always me....
I am the law."
-- Buffy, The Vampire Slayer
Pat Flannery
Derek Lyons wrote:
> It's a very nice real world example, other than the niggling detail of
> having exactly nothing to do with the real world and only being
> relevant to the nonexistent problem you are handwaving into existence.
>
Jorge R. Frank wrote:
> 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.
So the various centers have workforces that know their particular
software very well indeed.
But like I said, this means that there is a real problem with exchanging
data between the centers as the people at the other center aren't going
to know how the data was arrived at if it was derived from software that
they are unfamiliar with.
Back when the Constellation program first got started, we had someone
working on it at NASA contact sci.space.history and ask us where he
could find data on the Apollo and Mercury Launch Escape Systems. He
wasn't having any luck looking for detailed information on them, as all
of the mass of paperwork that NASA generated during those programs was
piled away in vast numbers of boxes with almost no indexing.
NASA has a real problem with doing the simple, non-flashy stuff if it
cuts even a little way into their budgets for The Big Plan.
For a couple of million dollars all that data could be converted into
pdf's and indexed. For a few million more, standardized computer
programs could be written for all the space centers that would allow
each of them to be able to do any sort of trajectory simulation they
desired and be on the same page when it came to exchanging
information...but "meat and potatoes" type projects like that don't
generate the big headlines that the PAO wants. So even though they would
be very useful down the line, they don't get funded - and things go
along as they always have, using 50 year old non-standardized trajectory
programs while mice nibble away a little more Apollo paperwork by the day.
Pat
kevin willoughby
>
>
> kevin willoughby wrote:
>> If two of three versions agree, that doesn't mean those two are correct.
>
> Though in this case you do get feedback by observing where exactly the
> satellite's orbit ended up in reality versus what one or more programs
> predicted.
That works, but it can be a *very* expensive way to debug a program...
Derek Lyons
>So the various centers have workforces that know their particular
>software very well indeed.
>But like I said, this means that there is a real problem with exchanging
>data between the centers as the people at the other center aren't going
>to know how the data was arrived at if it was derived from software that
>they are unfamiliar with.
Orbital parameters have a fixed format - how they were arrived at is
irrelevant.
<long irrelevant anecdote snipped.>
kevin willoughby
> Pat Flannery <fla...@daktel.com> wrote:
>> So the various centers have workforces that know their particular
>> software very well indeed.
>> But like I said, this means that there is a real problem with exchanging
>> data between the centers as the people at the other center aren't going
>> to know how the data was arrived at if it was derived from software that
>> they are unfamiliar with.
>
> Orbital parameters have a fixed format - how they were arrived at is
> irrelevant.
References, please?
My own experiences in various software systems suggest that while there
may be an abstract "fixed format", a dozen different programs will have
at least ten different formats.
In the early days, for any kind of data set, it isn't at all clear what
the best fixed-format should be. Build a dozen different programs,
compare the results, and you know enough to kill-off half the formats.
Build another dozen different programs and you begin to see
commonalities. Build another dozen programs and it begins to make sense
to talk about standards. Build another dozen and it begins to make sense
to enlist a standards organization (IEEE, ANSI, etc.) to start creating
standard. After a few years, it becomes clear how to build gateways
between formats. After another few years, folks standardize on a single
format.
An on-topic example, what's the best launch configuration? Single Stage
to Orbit has lots of advantages -- it's just not easy to build. Multiple
stages? History now demonstrate that works, but there are complications
like staging. Parallel launch? The Sputnik launchers demonstrate this
works, but as payloads increase this gets complex. Hybrid parallel like
the Space Shuttle -- that works most of the time, but we have to
acknowledge the final flights of Challenger and Columbia. Serial stages
(e.g., Saturn V) work, but with much complexity for "staging".
Summary: the idea that there is an initially obvious "fixed format" is
flawed. The fixed format will become evident only as we try a bunch of
different things.
> <long irrelevant anecdote snipped.>
yah, well, this is Usenet...
Pat Flannery
kevin willoughby wrote:
>
>
> An on-topic example, what's the best launch configuration? Single
> Stage to Orbit has lots of advantages -- it's just not easy to build.
> Multiple stages? History now demonstrate that works, but there are
> complications like staging. Parallel launch? The Sputnik launchers
> demonstrate this works, but as payloads increase this gets complex.
> Hybrid parallel like the Space Shuttle -- that works most of the time,
> but we have to acknowledge the final flights of Challenger and
> Columbia. Serial stages (e.g., Saturn V) work, but with much
> complexity for "staging".
There are so many variables... not regarding pound-to-orbit efficiency
via a specific system approach... but rather the overall _cost_ of
pound-to-orbit over the long run. That you can't really predict that in
advance without trying out various systems over a period of years or
decades and actually seeing what happens in regards to costs.
The Soviet/Russian R-7 based launch vehicles are real technological
clunkers by today's standards... but they have so much experience
building them that they are very reliable, and mass production has
greatly lowered the cost of the individual booster, technological
dinosaur that it may be.
Pat
Jan Vorbrüggen
Well, given the small number of examples that used this approach
thoroughly, I'd say that's difficult to say for sure. Whether it is
cost-effective - in particular when compared to other QA/QC methods - is
another matter.
> 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.
I think the problem is more on the conceptual level, i.e., in writing
requirements and specifications, and the likely reliance on common data
(e.g., formula collections, textbooks, numerical/measurement data). You
avoid the tool/programming language errors by making them diverse (cf.
Airbus avionics).
> The actual value of n-version programming has been studied in depth by
> Nancy Levenson. You might want to look up her papers.
Seconded. Also look for Peter Ladkin's publications.
Jan
Derek Lyons
>Derek Lyons wrote:
>> Pat Flannery <fla...@daktel.com> wrote:
>>> So the various centers have workforces that know their particular
>>> software very well indeed.
>>> But like I said, this means that there is a real problem with exchanging
>>> data between the centers as the people at the other center aren't going
>>> to know how the data was arrived at if it was derived from software that
>>> they are unfamiliar with.
>>
>> Orbital parameters have a fixed format - how they were arrived at is
>> irrelevant.
>
>References, please?
Ever set of orbital parameters I've ever seen is in the same format.
>My own experiences in various software systems suggest that while there
>may be an abstract "fixed format", a dozen different programs will have
>at least ten different formats.
But mathematical equations are much more well defined that computer
algorithms.
>An on-topic example, what's the best launch configuration? Single Stage
>to Orbit has lots of advantages -- it's just not easy to build. Multiple
>stages? History now demonstrate that works, but there are complications
>like staging. Parallel launch? The Sputnik launchers demonstrate this
>works, but as payloads increase this gets complex. Hybrid parallel like
>the Space Shuttle -- that works most of the time, but we have to
>acknowledge the final flights of Challenger and Columbia. Serial stages
>(e.g., Saturn V) work, but with much complexity for "staging".
So what? There isn't a dozen different kinds of orbits with this one
doing a loop-de-loop and that one doing a corkscrew.
Dr J R Stockton
>, Wed, 20 May 2009 23:50:28, kevin willoughby <kevinwi...@acm.org.
invalid> posted:
>Pat Flannery wrote:
>> kevin willoughby wrote:
>>> If two of three versions agree, that doesn't mean those two are correct.
>> Though in this case you do get feedback by observing where exactly
>>the satellite's orbit ended up in reality versus what one or more
>>programs predicted.
>
>That works, but it can be a *very* expensive way to debug a program...
Not necessarily expensive; it depends on the brightness of the satellite
and the magnitude of the error.
There is, for example, clearly a bug in ISS - it is visibly misbehaving,
yesterday arriving an hour later than scheduled for this location by
<http://spaceweather.com/flybys/state.php?country=UK>, the proprietor of
which has the same name as the production editor of science@NASA. It
should be told to get a move on and keep to Dr. P's timetable.
Heavens-Above is clearly copying ISS's errors.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Ken S. Tucker
> kevin willoughby <kevinwilloug...@acm.org.invalid> wrote:
> >Derek Lyons wrote:
Orbital dynamics was proven by Voyager 2 , Jupiter, Saturn
Uranus, Neptune flyby's,
http://en.wikipedia.org/wiki/Voyager_2
awesome.
Neptune was discovered based on celestrial mechanics,
http://en.wikipedia.org/wiki/Neptune_(planet)
more awesome.
Those examples are things a guy like I could do now-
adays with brute computer power, since the algorithms
are straightforward from good old Newton.
The really hard part (IMO) is the software controlling the
satellite, I find the Rover's very impressive,
http://en.wikipedia.org/wiki/Mars_Exploration_Rover
because it's difficult to foresee everything, but the ability
to repair and upgrade software is very cool.
Our most recent accomplishment was writing software
for thruster control for a soft landing on the moon, from
lunar orbit. As it turned out it only needs a few lines,
we only do that as a hobby.
> http://derekl1963.livejournal.com/
Cheers
Ken
Pat Flannery
Dr J R Stockton wrote:
> There is, for example, clearly a bug in ISS - it is visibly misbehaving,
> yesterday arriving an hour later than scheduled for this location by
> <http://spaceweather.com/flybys/state.php?country=UK>, the proprietor of
> which has the same name as the production editor of science@NASA. It
> should be told to get a move on and keep to Dr. P's timetable.
>
> Heavens-Above is clearly copying ISS's errors.
>
Daylight Savings Time conversion problem?
Pat
Pat Flannery
Ken S. Tucker wrote:
> Our most recent accomplishment was writing software
> for thruster control for a soft landing on the moon, from
> lunar orbit. As it turned out it only needs a few lines,
> we only do that as a hobby.
>
>
Don't make the mistake the Soviets did with Luna 15, where the descent
path happened to pass through a mountain on the way down. :-D
Did you figure in the gravitational influence of the Mascons during
descent BTW?
That should run to more than a few lines of code.
Pat
Ken S. Tucker
Yo Pat, our study was originally focused on the USSR
Luna series to try to get some understanding of the
challenges of photographing the far-side of the moon,
using 1950's technology.
Later, with refinement we sim'd launch to soft landing
(1"/sec at touchdown) by compressing a 5 day mission
into 5 minutes (adjustable dt), but it's highly idealized,
by using spherical Earth and Moon.
For each stage we have an adjustable Isp, booster
mass and fuel load.
It's all auto-sequenced, push spacebar and it starts.
Written qBasic, I can email it to you or post it here,
if you want.
Ken
kevin willoughby
>> , Wed, 20 May 2009 23:50:28, kevin willoughby <kevinwi...@acm.org.
> invalid> posted:
>> Pat Flannery wrote:
>>> kevin willoughby wrote:
>>>> If two of three versions agree, that doesn't mean those two are correct.
>>> Though in this case you do get feedback by observing where exactly
>>> the satellite's orbit ended up in reality versus what one or more
>>> programs predicted.
>> That works, but it can be a *very* expensive way to debug a program...
>
>
> Not necessarily expensive; it depends on the brightness of the satellite
> and the magnitude of the error.
I'll stand by my statement. The test plan for a moderately complex
program will specify several hundred test cases, minimum. Launching
several hundred satellites. Until the cheap-access-to-space miracle
occurs, we're talking a significant chunk of a gigabuck.
Pat Flannery
kevin willoughby wrote:
>
> I'll stand by my statement. The test plan for a moderately complex
> program will specify several hundred test cases, minimum. Launching
> several hundred satellites. Until the cheap-access-to-space miracle
> occurs, we're talking a significant chunk of a gigabuck
Ah, but there is something slick we can do here...we don't need to use
satellites that are _going_ to be launched; we can backtrack and use
ones that were _already_ launched.
Unfortunately, we probably can't get our hands on all the detailed data
for all that thousand or so Soviet optical and Signit recon satellites
that were launched, but with some digging we certainly can come up with
the details on the hundreds of satellites the US has launched since
1958, and enter those into the programs to see how accurately they
predicted what would happen to them versus what really did.
In the case of the numerous Corona satellites, they never did end up in
exactly the intended orbits in the early days, and had to have their
event clocks reset once on-orbit to tell them when to photograph things
and when to release their film return capsules.
Pat
kevin willoughby
> kevin willoughby wrote:
>>
>> I'll stand by my statement. The test plan for a moderately complex
>> program will specify several hundred test cases, minimum. Launching
>> occurs -- we're talking a significant chunk of a gigabuck
> Ah, but there is something slick we can do here...we don't need to use
> satellites that are _going_ to be launched; we can backtrack and use
> ones that were _already_ launched.
That would certainly be useful. But it wouldn't come close to filling in
all the required test cases for a universal-orbit-calculator program.
You'd need custom launches into extreme and/or weird orbits to complete
the test plan. Perhaps the trickiest would be placing a satellite in
(not orbiting) each of the Lagrange points. As far as I know, no one has
ever done a sun-synchronous polar orbit around the moon. Buzz Aldrin
hypothesized a cyclic traveler orbit between Earth and Mars. So I still
say: we're talking a significant chunk of a gigabuck.
> Unfortunately, we probably can't get our hands on all the detailed data
> for all that thousand or so Soviet optical and Signit recon satellites
> that were launched,
It wouldn't surprise me if that information was available. Perhaps the
former USSR would be willing to sell that data. Or may NORAD could be
convinced to declassify the data.
But again, that doesn't eliminate the need to lots of launches to
validate the software. The Soviet launches were all from high latitudes,
and flew into a limited number of orbital planes.