Programming library for orbital calculations

[cjp]

I have an idea for something that could be really useful to me and to other add-on developers. I hope this already exists; in that case, could somebody point me to it? If it doesn't I think it would be a great idea to create it.

The idea is as follows:

For a lot of Orbiter-related programming (e.g. the custom Cruithne asteroid dll I tried to make, but also for MFDs), you need to do orbital calculations. For instance, you have the orbital elements, but you need to have the orbital state vector in terms of position and velocity. Or you have the orbital state vector, and you want to know position and velocity at some time in the future. Or you want to get the shape of the orbit (e.g. approximated with a polyline) to display it on an MFD. Or you want to calculate the line of intersection between two orbital planes. Et cetera.

Many of these things are very straightforward if you know how to do it, but if people have to implement them again and again, a lot of time is wasted in searching on the internet for formulas, converting them to source code, etc.. So my idea is to make a simple open source, C language library for orbital calculations. Right now I can think of the following functionality:

• Basic vector calculus
• Geometric calculation tools
• From orbital state vectors to Keplerian elements and vice versa
• Partial derivatives of the same
• From orbital state vectors at time=t1 to time=t2 (with given accuracy, assuming 2-body system)
• Transformation between various useful coordinate systems (solar centered, planet-centered non-rotating, planet-centered rotating, composition of velocity change in forward/outward/ch.plane etc.)
• State vector prediction using numerical integration of various distortion forces ( >=3 body gravitation, solar wind, continuous thrust, atmospheric drag, who knows what)

Edit:
I'd like it to be a generic library that has no dependencies on anything but the C language itself, so that it can be used in any project outside Orbiter.

 

[Urwumpe]

Nice Idea, but I would say being able to use the datatypes of Orbiter would be a good feature, maybe you can do some preprocessor magic for it defining them internally, when OrbiterAPI is not loaded.

 

[agentgonzo]

So my idea is to make a simple open source, C language library for orbital calculations.

How many people in the orbiter community use raw C rather than C++? Given that it's all compiled with MSVS, it could compile the C++ code fine. And C++ gives you a lot of advantages that can be advantageous. eg, operator overloading for vectors/matrices.

 

[cjp]

Nice Idea, but I would say being able to use the datatypes of Orbiter would be a good feature, maybe you can do some preprocessor magic for it defining them internally, when OrbiterAPI is not loaded.

I could make the types "accidentally" the same, whenever Orbiter uses basic C types. For instance, this could be done when "real numbers" are used as 'double', or 3D vectors as 'double[3]'.

Otherwise, I could make some basic types "abstract", where the higher-level functions access them through a basic API only, and remain agnostic about the actual contents of the types. This API could then be implemented in a default way in the library, or be replaced by the user if the user wants to use other data types.

Otherwise, I could make simple conversion functions between Orbiter types and my library's types, whenever needed.

So we need to think about doing the following steps:

• Give the thing a name
• Give the thing a license (I'm thinking about LGPL)
• Make a summary of the functions we need
• Make a summary of the data types
• Create some initial header file, and post it on the forum
• Discuss the API

-----Posted Added-----

How many people in the orbiter community use raw C rather than C++? Given that it's all compiled with MSVS, it could compile the C++ code fine. And C++ gives you a lot of advantages that can be advantageous. eg, operator overloading for vectors/matrices.

Software is more useful if it can be used by more people. Therefore, I try to design this software to be useful for the largest group of people I can think of, while still making it solve my own problem in a convenient way. Currently, the group of people I have in mind is "all developers who wish to make software that involves planetary mechanics". This group includes Orbiter developers, and it includes myself.

It is required from my own position to use either C or C++, as it would be inconvenient to use other languages in Orbiter. Besides, C and C++ are widely used languages, so they shouldn't provide much trouble for a lot of developers.

Now between C and C++: C++ offers some nice features, and I use it a lot (more than I use C in fact). However, many features are not really needed, as this library will be quite simple, and doesn't include very complicated data structures. Operator overloading is an exception though. For the rest, C++ has mostly disadvantages: C can be used in C++ programs, but not the other way around, and C++ can give some nasty linking problems (e.g. when doing dynamic library loading, or linking between different compilers). Maybe I can do some nice C++ hacks to add operator overloading for C++ people when they include an extra header file.

 

[jarmonik]

I suppose most of this allready exists and the idea of such a software package is pretty old. I was working in such a project with Radu but it never got published. Also a pretty nice collection of keplerian orbit tools exists in IMFD but without export.




Also the IFP (http://orbiter-forum.com/showthread.php?t=2092) will be containing an Application Programmin Interface of some sort and that will give an access in many kind of tools like.

• Numerical orbit propagator
• Linear algabratic package to work with Matrices
• Basic keplerian orbit toolkit
• Various OrbiterAPI extensions

Many of the functions are bound into the Orbiter but some of them could be used outside the Orbiter.

I could make the types "accidentally" the same, whenever Orbiter uses basic C types. For instance, this could be done when "real numbers" are used as 'double', or 3D vectors as 'double[3]'.

Orbiter API defines a vector as:

union VECTOR3 {
double[3];
struct { double x,y,z };
}

if you define a similar structure or union with a different name the complier or linker won't accept it. There could be a simple way to solve this.. Haven't tried much sofar. Well, that was with VC6.0 maybe VC2005 is more intelligent.

 

[cjp]

I made the following proof-of-concept "combined C/C++ API" header:

#ifndef ORB_H
#define ORB_H

#ifdef __cplusplus
extern "C" {

#define orbVector3 _orbVector3_C_style

#endif

/*
C-style API:
*/

typedef struct {

    double x, y, z;

} orbVector3;

orbVector3 orbAddv3(orbVector3 v1, orbVector3 v2);

#ifdef __cplusplus
}

#undef orbVector3

/*
C++ style API:
*/

class orbVector3 : public _orbVector3_C_style
{
public:
    orbVector3()
        {}

    orbVector3(_orbVector3_C_style v)
        {x = v.x; y = v.y; z = v.z;}

    inline orbVector3 operator+(orbVector3 v)
        {return orbAddv3(*this, v);}

};

#endif

#endif

The type seems to be binary compatible with Orbiter's VECTOR3, but simply replacing the struct by a typedef that points to VECTOR3 won't work, as you can't derive a class from a union for some reason. So, I think I'd have to choose between either having operator overloading, or Orbiter type compatibility.


-----Posted Added-----

I suppose most of this already exists and the idea of such a software package is pretty old. I was working in such a project with Radu but it never got published. Also a pretty nice collection of keplerian orbit tools exists in IMFD but without export.

Also the IFP (http://orbiter-forum.com/showthread.php?t=2092) will be containing an Application Programming Interface of some sort [..]

That IFP looks pretty amazing! But how do I get the relevant code out of IMFD or IFP? I mean, the pieces of code that someone might statically link into his own plugin, and that can be used outside Orbiter. Without the GUI of those systems, without IMFD- or IFP-specific code etc..

Or would it be easier to make the whole thing from scratch? Maybe make the API from scratch, but have a look at e.g. the IMFD source code for some of the algorithms?

 

[jarmonik]

That IFP looks pretty amazing! But how do I get the relevant code out of IMFD or IFP? I mean, the pieces of code that someone might statically link into his own plugin, and that can be used outside Orbiter. Without the GUI of those systems, without IMFD- or IFP-specific code etc..

If there is a need to run these things outside the Orbiter in that case it might be easier to do it from scratch. Of course, something like linear algebra is not bound into the Orbiter but many other algorithms do require a physical parameters of the celestial objects and planets as well as orbital information, space craft properties, thrust properties and so on...


-----Posted Added-----

The type seems to be binary compatible with Orbiter's VECTOR3, but simply replacing the struct by a typedef that points to VECTOR3 won't work, as you can't derive a class from a union for some reason. So, I think I'd have to choose between either having operator overloading, or Orbiter type compatibility.

...for some reason, Yes. But what reason ? I suppose this is a major issue to be solved.

I once tried something like this.

#ifdef __ORBITER_API
#define Vector VECTOR3
#else
struct Vector {
    double x,y,z;
}
#endif

but this just moves the problem from compile stage into a linking stage.

Of course, if the Vector would be rebuild exactly with the same name "VECTOR3" it should work.

 

[Hielor]

The type seems to be binary compatible with Orbiter's VECTOR3, but simply replacing the struct by a typedef that points to VECTOR3 won't work, as you can't derive a class from a union for some reason. So, I think I'd have to choose between either having operator overloading, or Orbiter type compatibility.

Structs in C++ can overload operators:

http://msdn.microsoft.com/en-us/library/5tk49fh2(VS.80).aspx

 

[tblaxland]

Structs in C++ can overload operators:

http://msdn.microsoft.com/en-us/library/5tk49fh2(VS.80).aspx

That is because structs and classes in C++ are equivalent except for struct members being public by default. What you can do in a class, you can do in a struct and vice-versa.

 

[cjp]

Structs in C++ can overload operators:

http://msdn.microsoft.com/en-us/library/5tk49fh2(VS.80).aspx

I know that. It's just that you can't derive a class or a struct from a union. And Orbiter's VECTOR3 is a union.

For the vector and matrix types, we have the conflicting demands:

1. Compatibility with Orbiter types. The alternative: using type conversion functions.
2. Having operator overloading (C++ only).
3. Having a C-style API for people who don't (want to) use C++ (maybe there's no forum-wide consensus about this one).
4. Being independent from Orbiter. We need our own data types here.

The following combinations are possible:

• 1+3: Orbiter's types are basically C-style.
• 1+4: Using some preprocessor switches. Requires re-compilation of the library for use in Orbiter (not a big deal).
• 1+3+4: No additional problems.
• 2+3: We could make a C-API with C++ extensions for operator overloading (see the header file in an earlier post), but it is slightly inefficient (copying on data conversion in the C++ style API)
• 2+4: No problem.
• 2+3+4: No additional problems.

So, only 1+2 is a real problem, and 2+3 is slightly inefficient. Maybe the best solution is the 1+3+4 approach, with additional C++ classes for those people who really want operator overloading, and don't mind about inefficiencies. Then, the primary vector datatype would be C-style VECTOR3-compatible. Actually using VECTOR3 for this would be possible if you change some defines and recompile the library. The additional C++ style class with operator overloading would contain to-and-from conversions for this primary datatype. All functions that require a 3D vector use the primary type, so people who use the C++ class would have to do a type conversion at each call (implicit or explicit).

I'm planning the same for MATRIX3 and Orbiter's struct for Keplerian elements.

Does this sound acceptable?


-----Posted Added-----

I suppose most of this already exists and the idea of such a software package is pretty old. I was working in such a project with Radu but it never got published. Also a pretty nice collection of keplerian orbit tools exists in IMFD but without export.

So where can I find the source code of IMFD? I'd like to have it as a backup reference, for all those cases where Wikipedia fails . BTW, do you mind if I read things in your code and release them under the LGPL?

I'm about to release a 'zeroth' version, with only a very basic code layout, and only implementations of the most trivial functions. I named the thing "KOST" (Kepler Orbit Simulation Toolkit), but it will cost you nothing. I'll make a new thread in the Addon development forum once I'm ready.


Edit:
Initial version release happened here:
http://orbiter-forum.com/showthread.php?t=4605
I suggest continuing the discussion there.