TransX Accuracy of closest approach distance

[Thierry Lys]

I want to know how accurate is the distance of the closest approach shown by this MFD while you are setting a stage or planning a manoeuvre while you are in a stage centred on major body. Futhermore I have seen that after all have been set, and before the burn, this distance is oscillating with regularity when you are accelerating the time and increasing in general. As I stop to accelerate time, the distance has changed, so it isn’t just due to the time acceleration. Perhaps as we are moving, gravity attractions are responsible of that changes but it could also has no physical signification. Therefore how is it precise and what are the reasons of those oscillations ?

 

[Linguofreak]

Which MFD is "this MFD"?

 

[Hielor]

Which MFD is "this MFD"?

TransX. The thread is tagged with it.

 

[tblaxland]

I can't give you an absolute answer but I can give you some background...

The author may correct me if I am wrong, but I believe that TransX works on a patched conic model which is an approximation to the numerical integration of the flight path that Orbiter does, so inaccuracies will inevitably result. The reason for the approximation is to keep the calculation times reasonable - you can imagine how long you would have to wait for a result if the MFD had to do a full numerical integration all the way to your destination with the same accuracy as Orbiter does, and then consider that it would need to do so every time you change a variable. IMFD's Map program does a numerical integration but it still suffers from similar (although smaller) inaccuracies for the same reason - sacrificing accuracy for calculation time.

 

[flytandem]

Make sure you have the [ame="http://www.orbithangar.com/searchid.php?ID=3039"]latest version of TransX[/ame], the wobble wrt Earth is far less than previous versions.

Even so there is a fair amount of both wobble and drift. As you get better you can start to actually get a feel for the changes in cl.app. Some of the worst offenders are going from moon to moon in the Jupiter system. Saturn is a close second. Earth has a bit of binary wobble still but not very much. Venus behaves fairly well. As do Uranus and Neptune and their moons.

Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App. Then again, if there was perfect accuracy in the maneuver, it would take a lot of the fun and challenge out of it.

The good thing is that if you are at the point where the inaccuracies in Cl App are becoming a game of chase then it means you are getting pretty good at TransX. And that in itself deserves a nice high five.

 

[Zatnikitelman]

Hmm, sounds like some sort of application for the new format of Orbiter!

 

[tblaxland]

Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.

I thought I had seen that suggestion somewhere before... over one year ago actually
http://www.orbiter-forum.com/showthread.php?p=13569#post13569

 

[martins]

Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.

I had been thinking about this possibility as well, but there are disadvantages to this approach. In the inverse problems community, this would qualify as an "inverse crime": you use the same model to generate data and analyse them. It enforces self-consistency, even if orbiter's model was completely wrong. In other words, if TransX or IMFD used orbiter's model, then the fact that they work correctly would not tell anything about how good orbiter's physics actually is. Whereas an independently developed model provides more feedback about the relative validity of the two models. If they work together, then there is a good chance that the adhere to a common standard (ideally, reality).

 

[agentgonzo]

The author may correct me if I am wrong, but I believe that TransX works on a patched conic model...

Correct.

Stuff about self consistency

You're right about independent verification of the Orbiter physics model. However, from a user's POV when using TransX/IMFD, and entirely self-consistent model would be idea as the planned trajectory would match the future trajectory exactly. Though this would take some of the challenge out of it and remove the need for MCCs that make the flight more enjoyable.

Hey wouldn't it be cool if, while adjusting TransX for a maneuver, it automatically ran the Orbiter core integration in the background at rapid speed and did an update to the Cl App.

It would be cool, though it would make a change to the way that the MFD worked (especially on long trips to the outer solar system). I'm not sure how fast this could work and whether it would be limited by the time accel of the orbiter-core thread doing the numerical propagation. It would take some time for the Cl App to update following a change of burn parameters.

I also don't have the time to re-write the core engine of TransX away from the patched-conics method either, so if you want this to be done, someone else will have to take the plunge . I'm away from a computer for the whole of 2010 and don't have time to do it this year.

 

[Thierry Lys]

Thank you very much for the pertinence and the level of your answers. I know that this precision of the closest approache distance is one of the challenge of TransX because we always want to make flights as perfect as possible and with a minimum of course corrections. It takes part in the fun of Orbiter. However, because the numbers evolve with our position in space, variations could have been the consequence of the evolution of forces operating on the vessel as these variations didn’t seem totally unpredictable. Futhermore as with set a correction for a precise time that TransX has memorized and because we don’t change anything until the burn staying on the same orbit, the cloasest approach distance as no reason to change unless there are external factors. If the vessel is evolving in space, its speed and position at the time set for the burn stay the same and are memorized by the MFD. Therefore why the number is changing ?

 

[agentgonzo]

Thank you very much for the pertinence and the level of your answers. I know that this precision of the closest approache distance is one of the challenge of TransX because we always want to make flights as perfect as possible and with a minimum of course corrections. It takes part in the fun of Orbiter. However, because the numbers evolve with our position in space, variations could have been the consequence of the evolution of forces operating on the vessel as these variations didn’t seem totally unpredictable. Futhermore as with set a correction for a precise time that TransX has memorized and because we don’t change anything until the burn staying on the same orbit, the cloasest approach distance as no reason to change unless there are external factors. If the vessel is evolving in space, its speed and position at the time set for the burn stay the same and are memorized by the MFD. Therefore why the number is changing ?

TransX will remember the burn time (in MJD) and the burn direction and Delta-V. The position that the vessel is in at this burn time is not remembered and is calculated each time the MFD is updated from the current position and velocity. The same applies to all minor bodies in the current system. Therefore as the simulation progresses, the expected position of minor bodies in the system and the vessel change from the inital prediction.

 

[tblaxland]

This is how I visualise what agentgonzo put in words (see attachment).

 

[Thierry Lys]

Okay now it is clear for me. Thank you very much.

 

[Andy44]

I had been thinking about this possibility as well, but there are disadvantages to this approach. In the inverse problems community, this would qualify as an "inverse crime": you use the same model to generate data and analyse them. It enforces self-consistency, even if orbiter's model was completely wrong. In other words, if TransX or IMFD used orbiter's model, then the fact that they work correctly would not tell anything about how good orbiter's physics actually is. Whereas an independently developed model provides more feedback about the relative validity of the two models. If they work together, then there is a good chance that the adhere to a common standard (ideally, reality).

I agree. But I also think that TransX (or whatever new tool is used) could use a nicer model. Some sort of numerical model, just not the same one used by Orbiter itself, which is supposed to represent "real life".

In real life mission planners use models which are very high speed, and of course the actual mission is flown using the actual physics of creation. Since the models are pretty good, the missions are amazingly precise. TransX is good, but it doesn't allow us to recreate the precision real life mission planners can demonstrate.