Re: [Orekit Developers] SOCIS 2011

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Le 02/08/2011 11:16, Alexis ROBERT a écrit :
> Hi,

Hello Alexis,

> 
> First of all thanks a lot for selecting me! I'm very happy to program
> on Orekit during my summer! :)

You're welcome.

> 
> I know I could have sent a little "hello" message as SOCIS organizers
> advertised as soon as the announcement came out, but I preferred to
> wait until I have something to discuss instead of sending an
> uninteresting plain hello mail :)
> 
> By the way, it seems that this mailing list has not a lot of traffic,
> and I hope nobody will not be annoyed but the mails about the SOCIS
> progression and hire a professional killer to make me quiet which is
> something I may find unpleasant. I've heard that some people opened a
> blog for their GSoC but that may not be as interactive as a
> mailing-list, so just tell me what do you prefer :) (or if you have
> other ideas)

I think using this mailing list as the main communication channel is the
way to go. Orekit is open-source and development tasks like this one
should be visible to everyone.

For some specific cases, we will also use direct messages (or even phone
call if needed). See later in this message for the first such case.

> 
> About source code management, I've seen you use git, and I was
> planning to open a temporary project on Gitorious, which enables to
> have multiple repositories so that I can have test repositories
> without disturbing Orekit's forge, and we could simply push the final
> repository on the Orekit forge when the progress is sufficient. Is it
> ok for you ? :)

We will set up a dedicated repository for you in our git server. So I
will ask to send directly (this is an example of private message I will
need) a public SSH key so I can set up write access for you. I will also
ask you to sign an Individual Contributor License Agreement, just in the
same spirit as the Apache Software Foundation. It is a required step for
us before we can publish the code you contribute. I'll send you the form
later this evening.

> 
> As I wrote in my proposal (available here :
> https://www.orekit.org/wws/arc/orekit-developers/2011-07/msg00005.html
> ), I'm currently starting with understanding the computations and
> making them in J2SE (because making the GUI layout without
> understanding what's required and how to do that is pretty certain to
> lead to errors), and I have some questions (the most part is just to
> see if I understood correctly -- if it's ok, I will post the J2SE app
> just to see if it's ok for you and if it's what you want the Android
> app to do).

We will send you some more info about what we think this evening, so we
will hopefully reach a consensus of what the application should do quickly.

> 
> About computing visibility from a ground station (I figured out that
> ground station visibility was in the tutorial/ folder, thanks for
> that! :) ) :
> 
> * If I understood correctly the required parameters for the final user
> would be only initial date, position, velocity (in the EM2000 frame),
> station coordinate (in terrestrial frame), maxCheck (for the event
> detector) and elevation (which triggers the event), is that right ?

Yes, it's right. There may be additional lower level data (like Earth
Orientation Parameters), but we are not sure if they should be stored
the same way in an Android application as in a desktop application (were
we simply store the IERS original files, often packed in a zip archive
like in the orekit-data.zip file).

Perhaps there are better ways to do it in Android, as the devices have
less computing power and less memory.

> * In the example, a Keplerian propagator is used, with the "(could be
> more elaborate)" mention in comments. Would you like something else ?

For such an application, Kepler could be sufficient. It could very
easily be replaced by Eckstein-Heschler though, as all Orekit
propagators implement the same interface.

> * Will the elevation check sufficient out of the tutorial usage ? (I
> really don't know about this question, just asking to be sure :) )

Yes it is sufficient. Typical values for ground stations are 5 or 10
degrees elevation above horizon. Some stations have elevation threshold
that depend on azimuth (think a station that has a mountain in the South
direction for example, or a nearby city and is not allowed to transmit
in some radio bands at low elevation near inhabited areas).

> * I've seen there is not explicit code for managing earth rotation, is
> it taken into account implicitly by saying that the Earth body is in
> the terrestrial frame ? If it's taken into account implicitly,
> shouldn't we add an other date  to specify the coordinates on earth
> (or initial earth position) ?

It is automatically handled by Earth frame (the so-called ITRF frame).
The complete model is very complex and is not a simple rotation, so it
does not end up with an initial position, an initial date and a rotation
rate ... The required data is split in thousands of fixed model
parameters (precession model, nutation model, taking into account
effects from Sun, Moon and the largest solar system planets) and also
some measured parameters which are not in the models (the Earth
Orientation Parameters published by IERS, like nutation corrections,
pole motion with respect to Earth crust, time scales offsets resulting
for Earth irregular rotation ...).

It is so complex it cannot be parameterized from a simple graphical user
interface. What users do is select the model (which in fact corresponds
to selecting a specific Earth frame, like ITRF 2005) and provide the
IERS correction files.

> 
> About orbit conversion :
> 
> If I understood correctly, it's just for instance something like that :
> 
>   KeplerianOrbit ko = // init code
>   CircularOrbit co = new CircularOrbit(ko);
> 
> am I right ?

Almost. the most interesting conversion is often between Cartesian
parameters and other parameters (Keplerian, circula, equinoctial) or
conversions to TLE (Two Line Elements) which are something rely specific
(in fact, TLE do not represent an instant state, they also imply a
dynamic model and *cannot* be used with another propagation model than
their own).

> 
> About impulse maneuver :
> 
> * If I understood correctly, the way to manage maneuver, is to use a
> Numerical Propagator and to select some forces like Gravity and an
> Impulse Maneuver force. As the impulse maneuver requires a trigger
> event, is it simply start date and end date of the maneuver ?

There are two main maneuvers models: continuous maneuvers which can be
handled only by NUmericalPropagator as they represent a perturbing force
that must be integrated, and impulse maneuvers which can be handled by
any propagators as they correspond to a reset of the state (in fact the
velocity part only) and are a simplified version. They correspond to
maneuvers whose duration is short enough to be neglectible with respect
to the natural orbit motion.

As numerical propagation is probably too computation intensive for an
android device, we will limit ourselves to impulse maneuvers only here.

> * If I understood correctly again, the parameters available for the
> final user would be initial date, initial position & velocity of the
> body (in the EM2000 frame), start time for the maneuver, end time for
> the maneuver and the velocity delta, am I right ?

Yes. The velocity increment could be expressed either in an inertial
frame (like EME2000) or in a moving local orbit frame (like LVLH, which
basically is centered on satellite and has its directions oriented along
position, velocity and orbital momentum - at least for circular orbits).

> 
> Thank you again, and have a nice day :)

Thank you and good luck
Luc

> 
> Alexis Robert
>