CelestLab

Comment from jerome caron -- January 11, 2010, 04:43:07 PM    

I have just installed the Celestlab package. I would like to know the list of constants
that are loaded with CL_init(), where do I find the information ? I checked the help but
did not find anything. I found that %CL_mu is the gravitational constant for Earth, what
are the others ?

It would be also useful to have a few examples of programmation with Celestlab, to start
with to try to code your own programs.

Many thanks for this promising package
Best regards

Jerome Caron

Answer from Alain Lamy -- January 12, 2010, 09:32:11 AM    

You probably haven't seen the CelestLab help pages : 
Call "help" and you should find the CelestLab topics on the left column. 
Regarding the constants that are defined in CelestLab, 'help CL_init' should
give the information you want. 
Examples are given in each help page and also in the 'demo' files (more
examples are coming soon). 
Hope its answers your questions. 
A. Lamy

Answer -- March 19, 2010, 02:38:35 AM    

This answer has been deleted.

Comment from cyrille tourneur -- January 27, 2010, 10:47:52 PM    

Very very useful and powerful library - many thanks to CNES for this good initiative
Some possible improvements below:
- Models: Earth magnetic field model vs sat altitude & position would be helpful,
especially for missions on exotic/non classical SSO orbits
- Utilities: Coordinates of intersection of a vector defined in the orbital local frame (or
other) with Earth surface (Example: Local solar time vs latitude or pso for min and max
roll values of an optical observation mission like Spot 5)
- The TNW local orbital frame is a bit confusing vs the classical navigation frame (X
towards motion, Y normal to orbit palne and Z towards Earth) - but we can live with this

Many thanks again
 C. Tourneur
   

Answer from Alain Lamy -- February 5, 2010, 09:20:22 AM    

This answer has been deleted.

Answer from Alain Lamy -- February 5, 2010, 09:20:54 AM    

First of all, thanks for the comments, and thanks for supporting CelestLab. 

We have noted all your suggestions! 

At the moment we are preparing a new version, that, we hope, will be available shortly.
(The extended features that you have proposed may not be available in the next version
though). 

One additional comment: 
The definition of the TNW local orbital frame is the same in CelestLab as it is in some
reference books (e.g. "Trajectoires Spatiales" by O. Zarrouati or CCSDS "Navigation
Data—Definitions and Conventions", 500.0-G-2). The "classical navigation frame" you are
referring to seems to be LVLH, which is also in CelestLab (LVLH is like QSW but with
different axes name conventions). But we'll keep this topic in mind for future versions of
CelestLab.     

Thanks again. 
A. Lamy

Comment from cyrille tourneur -- February 4, 2010, 10:55:15 PM    

Maybe a bug in CL_op_searchRepeatOrbits on params(:,10): longitude gap between 2 closest
ascending nodes [rad] = 2*%pi/(N*Q+P)

If you run the example in the help file
smaMin = 7000.0 * 1000;
smaMax = 7050.0 * 1000;
QMin = 2;
QMax = 6;
ecc = 0.0001;
sso = 1;
[params]=CL_op_searchRepeatOrbits(smaMin,smaMax,QMin,QMax,ecc,sso)

you get:
 params  =
 
    7044098.7    0.0001    1.7112917    14.    2.    3.    44.    5890.9091    3.   
8.1818182    0.         
    7017485.7    0.0001    1.7094306    14.    3.    4.    59.    5857.6271    4.   
6.1016949    0.         
    7001637.8    0.0001    1.7083309    14.    4.    5.    74.    5837.8378    5.   
4.8648649  - 1.599D-13

For params(:,10) of the first line,  0,142799666072263 (=2*pi/44) would be expected instead
of 8.1818182
Regards

Answer from Alain Lamy -- February 5, 2010, 09:47:21 AM    

This answer has been deleted.

Answer from Alain Lamy -- February 5, 2010, 10:03:21 AM    

That's true! 

The problem was in fact that the result was expressed in degrees rather than in radians.
This had already been corrected in the new version of CelestLab (that should be released
soon). 
By the way, another anomaly has also been corrected (in the 'CL_op_repeat2smaInc' function
actually), whose effect was to prevent the algorithms from converging in some situations. 

A final comment: 
I think you should preferably use "bugzilla" rather than this discussion list if you detect
other anomalies. 

Thanks for the remark. 
A. Lamy