Orbiter-Forum  

Go Back   Orbiter-Forum > Projects > ORBITER: 2010-P1 and newer > Bug
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

EPHEM_PARENTBARY test results for orbiter_beta_080609 Issue Tools
issueid=21 06-10-2008 05:50 AM
Beta Tester
EPHEM_PARENTBARY test results for orbiter_beta_080609
First simple tests

I'm using the method I described in another thread, where I have a celbody that reports a fixed position, and an MFD that outputs all positions to a text file. I've started working through the simple cases first, the simplest being a planet with no moons.

If my celbody reports EPHEM_PARENTBARY, I get an incorrect result, namely the planet is located relative to the true solar position and not (0,0,0) as it should:

Sun: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_BARYPOS, EPHEM_BARYVEL
Sun true: -1.06875662e+009 3.08713285e+007 -4.16590844e+008
Sun bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
Sun gpos: -1.06875662e+009 3.08713285e+007 -4.16590844e+008

celbody_4: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_PARENTBARY
celbody_4 true: 1.50000000e+011 0.00000000e+000 0.00000000e+000
celbody_4 bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
celbody_4 gpos: 1.48931319e+011 3.08713302e+007 -4.17026132e+008

Regards
Issue Details
Project ORBITER: 2010-P1 and newer
Status Fixed
Priority 5 - Medium
Affected Version 080609
Fixed Version (none)
Users able to reproduce bug 0
Users unable to reproduce bug 0
Assigned Users (none)
Tags (none)

06-10-2008 10:14 AM
Beta Tester
 
Sorry, I don't understand. If we are talking about the "true" position of a celbody. Isn't that a position relative to parent body.

However, if the ephemeris can only return a position of a body reletive to parentbary. Then we have to substract or add the position of parent relative to it's own barycenter in order to get true position.

The results are not nessecarely incorrect.

Does the vector, returned by sun's ephemeris, point from the Sun into SSB or from SSB into the Sun ?

What does:
oapiGetRelativePos(celbody_4, Sun) return ?
oapiGetBarycenter(Sun) return ?
oapiGetGlobalPos(celbody_4) return ?
oapiGetGlobalPos(Sun) return ?


I suppose oapiGetRelativePos(celbody_4, Sun) should return:

[1.51068e+011, -3.08713285e+007, 4.16590844e+008] in a case if the vector points from SSB into the Sun.
[1.48931e+011, 3.08713302e+007, -4.17026132e+008] otherwice.
Reply
06-10-2008 11:36 AM
Beta Tester
 
I presume the return values for this case should be:

oapiGetRelativePos(body_4, Sun) = [1.51068e+011, -3.08713285e+007, 4.16590844e+008]
oapiGetBarycenter(Sun) = [0,0,0] Global position of barycenter based on documentation (Not barycenter offset)
oapiGetGlobalPos(Sun) = [-1.06875662e+009, 3.08713285e+007, -4.16590844e+008]
oapiGetGlobalPos(body_4) = [1.50000000e+011, 0.00000000e+000, 0.00000000e+000]

So, If the "gpos" is a global position then we have a problem.

However, If the Orbiter places the Sun in origin:

oapiGetRelativePos(body_4, Sun) = [1.51068e+011, -3.08713285e+007, 4.16590844e+008]
oapiGetBarycenter(Sun) = [1.06875662e+009, -3.08713285e+007, 4.16590844e+008]
oapiGetGlobalPos(Sun) = [0,0,0]
oapiGetGlobalPos(body_4) = [1.51068e+011, -3.08713285e+007, 4.16590844e+008]
Reply
06-10-2008 12:51 PM
Beta Tester
 
Quote:
Originally Posted by jarmonik
 However, If the Orbiter places the Sun in origin:
Orbiter doesn't place the sun in origin.

If the barycentric offset is computed based in child positions shouldn't this make ephemeris of the Sun obsollete ?


(Tue Jun 10 17:00:05 2008 ) MJD: 51982.6808711784320000
(Tue Jun 10 17:00:05 2008 ) Sun->Jupiter = [ 1.8953581e+011, -7.2911281e+009, 7.3413328e+011 ]: 7.582405e+011
(Tue Jun 10 17:00:05 2008 ) Sun->SSB = [ 6.0339457e+008, -21170626, 7.7414882e+008 ]: 9.8175333e+008
(Tue Jun 10 17:00:05 2008 ) oapiGetBarycentre(hSun): [ 0, 0, 0 ]: 0
(Tue Jun 10 17:00:05 2008 ) oapiGetGlobalPos(hSun): [ -6.0428579e+008, 21224246, -7.7327649e+008 ]: 9.8161516e+008
(Tue Jun 10 17:00:05 2008 ) SunEphem: [ -6.0428579e+008, 21224246, -7.7327649e+008 ]: 9.8161516e+008

Data returned by Sun ephemeris do match the data computed from child positions. So, there is no problem.
Reply
06-10-2008 04:52 PM
Beta Tester
 
Here is the code I use to generate the values:

Code:
nGbody = oapiGetGbodyCount ();
for (i=0;i<nGbody;i++)
{
Obj = oapiGetGbodyByIndex(i);
CBody = oapiGetCelbodyInterface (Obj);
oapiGetObjectName(Obj,Gbodyname,128);
time = oapiGetSimMJD();
EphemFlags = CBody->clbkEphemeris(time,EPHEM_TRUEPOS|EPHEM_TRUEVEL|EPHEM_BARYPOS|EPHEM_BARYVEL,ret);
if(EphemFlags&EPHEM_POLAR)
{
fprintf(outfile,"%s: EPHEM_POLAR", Gbodyname);
xpos = 1.49597870691e11 * ret[2]* cos(ret[1]) * cos(ret[0]);
zpos = 1.49597870691e11 * ret[2]* cos(ret[1]) * sin(ret[0]);
ypos = 1.49597870691e11 * ret[2]* sin(ret[1]); 
xposb = 1.49597870691e11 * ret[8]* cos(ret[7]) * cos(ret[6]);
zposb = 1.49597870691e11 * ret[8]* cos(ret[7]) * sin(ret[6]);
yposb = 1.49597870691e11 * ret[8]* sin(ret[7]); 
}
else
{
fprintf(outfile,"%s: ", Gbodyname);
xpos = ret[0];
ypos = ret[1];
zpos = ret[2];
xposb = ret[6];
yposb = ret[7];
zposb = ret[8];
}
if(EphemFlags&EPHEM_TRUEPOS)fprintf(outfile,", EPHEM_TRUEPOS");
if(EphemFlags&EPHEM_TRUEVEL)fprintf(outfile,", EPHEM_TRUEVEL");
if(EphemFlags&EPHEM_BARYPOS)fprintf(outfile,", EPHEM_BARYPOS");
if(EphemFlags&EPHEM_BARYVEL)fprintf(outfile,", EPHEM_BARYVEL");
if(EphemFlags&EPHEM_PARENTBARY)fprintf(outfile,", EPHEM_PARENTBARY");
if(EphemFlags&EPHEM_BARYISTRUE)fprintf(outfile,", EPHEM_BARYISTRUE");
oapiGetGlobalPos(Obj,&pos);
fprintf(outfile,"\n%s true: %15.8e %15.8e %15.8e\n",Gbodyname,xpos,ypos,zpos);
fprintf(outfile,"%s bary: %15.8e %15.8e %15.8e\n",Gbodyname,xposb,yposb,zposb);
fprintf(outfile,"%s gpos: %15.8e %15.8e %15.8e\n\n",Gbodyname,pos.x,pos.y,pos.z);
}
Regards
Reply
06-10-2008 06:22 PM
Beta Tester
 
Quote:
Originally Posted by Chode
 celbody_4: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_PARENTBARY
celbody_4 true: 1.50000000e+011 0.00000000e+000 0.00000000e+000
celbody_4 bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
celbody_4 gpos: 1.48931319e+011 3.08713302e+007 -4.17026132e+008
So, this is exactly the result it should give when the EPHEM_PARENTBARY is not defined.
Reply
06-10-2008 07:30 PM
Beta Tester
 
Yes, reporting EPHEM_PARENTBARY apparently has no effect, you get the same global position that you do when you don't report it:

celbody_1: , EPHEM_TRUEPOS, EPHEM_TRUEVEL
celbody_1 true: 1.50000000e+011 0.00000000e+000 0.00000000e+000
celbody_1 bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
celbody_1 gpos: 1.48931243e+011 3.08713285e+007 -4.16590845e+008


Regards
Reply
06-11-2008 01:14 AM
Orbiter Founder
 
Sorry for the somewhat long-winded debugging process for this issue ...

Here is the next attempt: I have attached a replacement orbiter.exe which fixes a bug in the barycentre calculation. Can you please test if this improves the results?
Reply
06-11-2008 01:41 AM
Beta Tester
 
Thanks for looking into this issue. Unfortunately, I still get the same results for this particular test.

Regards
Reply
06-11-2008 02:45 AM
Orbiter Founder
 
That is a shame. I generated a small mock solar system, consisting of Sun and Earth. The sun (mass 1e30) is fixed at position (-1e7,0,0). Earth (mass 1e26) is fixed at position (1e11,0,0). Using EPHEM_PARENTBARY for the Earth module, I get the following results with your test code:

Code:
Sun: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_BARYPOS, EPHEM_BARYVEL
Sun true: -1.00000000e+007 0.00000000e+000 0.00000000e+000
Sun bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
Sun gpos: -1.00000000e+007 0.00000000e+000 0.00000000e+000
 
Earth: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_BARYPOS, EPHEM_BARYVEL, EPHEM_PARENTBARY, EPHEM_BARYISTRUE
Earth true: 1.00000000e+011 0.00000000e+000 0.00000000e+000
Earth bary: 1.00000000e+011 0.00000000e+000 0.00000000e+000
Earth gpos: 1.00000000e+011 0.00000000e+000 0.00000000e+000
Without the EPHEM_PARENTBARY flag, I get the following results:
Code:
Sun: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_BARYPOS, EPHEM_BARYVEL
Sun true: -1.00000000e+007 0.00000000e+000 0.00000000e+000
Sun bary: 0.00000000e+000 0.00000000e+000 0.00000000e+000
Sun gpos: -1.00000000e+007 0.00000000e+000 0.00000000e+000
 
Earth: , EPHEM_TRUEPOS, EPHEM_TRUEVEL, EPHEM_BARYPOS, EPHEM_BARYVEL, EPHEM_BARYISTRUE
Earth true: 1.00000000e+011 0.00000000e+000 0.00000000e+000
Earth bary: 1.00000000e+011 0.00000000e+000 0.00000000e+000
Earth gpos: 9.99900000e+010 0.00000000e+000 0.00000000e+000
This seems correct. Do you get different results for this case, or should I look at a different problem?
Reply
06-11-2008 04:52 AM
Beta Tester
 
Hi martin,

I am able to reproduce your result, using this exact model, so at least we agree on that point. However, if I change any of the parameters of this model, I get results that do not look right.

One thing I noticed is that this system is "perfectly balanced", that is, the ratio of the masses is exactly equal to the ratio of the distances from the barycenter (1.e4). For systems that are not "perfectly balanced", I get unexpected results.

Regards
Reply
06-11-2008 12:59 PM
Orbiter Founder
 
I guess by "not perfectly balanced" you mean a situation where the module reports both the true and barycentre position (as is the case for the Sun in the above example), and the resulting barycentre offset does not match the offset manually calculated from the child body positions. This situation could arise for example if the module calculation takes into account more objects than are actually present in the simulation.

In this case, which result should orbiter use? The module value, because it is more accurate in global terms, or the manually calculated value, because it is more self-consistent?
Reply
06-11-2008 04:20 PM
Beta Tester
 
Ah, yes, now I see what is going on. I had made the assumption that the module barycenter position (when given) would "define" it, and it would not be open to recalculation. From my perspective, this is the preferred behaviour, since it would give consistent results, independent of what planets, etc. are included or not included in the configuration. To go back to the original example, I would want Pluto's position to be the same whether or not Jupiter was included in the solar system config.

Regards
Reply
06-11-2008 04:33 PM
Orbiter Founder
 
I'll try to come up with a new version tonight. I will need to re-order my calculations a bit for the recursive barycentre determination for the case where the module provides both sets of data.

So this would be the desired behaviour:
  • If the module provides both true and barycentre positions, the offset is taken directly as the difference
  • If the module only provides true position, the barycentre position is calculated manually, by evaluating the barycentre offset from the recursively obtained child positions
  • If the module only provides barycentre position, the true position is calculated manually, by evaluating the barycentre offset from the recursively obtained child positions.
Reply
06-11-2008 05:07 PM
Beta Tester
 
Yes, that looks right. In addition, the second case only applies if one or more children give the EPHEM_PARENTBARY flag.

Regards
Reply
06-12-2008 03:19 AM
Orbiter Founder
 
I have now replaced the orbiter.zip attachment with my latest effort. This should treat the barycentre calculations according to the rules above (or so I hope ...) Please let me know what you find.
Reply
06-13-2008 02:34 AM
Beta Tester
 
Looking good.
I've tested out all possible flag combinations for a planet with a single moon (12 total), and all of them give the expected result. Is there some other test(s) someone might suggest? Otherwise, I plan to test a Pluto system ephemeris I'd been working on as a final check (which is how this whole issue got started).

Regards
Reply
06-16-2008 03:52 AM
Beta Tester
 
I've tested out my Pluto system ephemeris, and everything (positions and velocities) comes out as expected. As far as I have been able to determine, the two issues concerning EPHEM_PARENTBARY and the calculation of system barycenters have been fixed.

Regards
Reply
06-16-2008 11:19 AM
Orbiter Founder
 
Excellent - thanks for testing!
I have marked the issue as fixed. Feel free to re-open it if you spot any more problems in the future.
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT. The time now is 01:16 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.