Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Orekit
Orekit
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 57
    • Issues 57
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 6
    • Merge Requests 6
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Orekit
  • OrekitOrekit
  • Issues
  • #688

Closed
Open
Opened Jun 10, 2020 by Evan Ward@evanward1Developer

TLEPropagatorBuilder ignores fields from template

Currently in TLEPropagatorBuilder several fields of the template TLES are ignored. These fields are:

  • ephemerisType
  • meanMotionFirstDerivative
  • meanMotionSecondDerivative
  • bStar

The documentation for TLEPropagatorBuilder states the template "defines the inertial frame, the central attraction coefficient, orbit type, satellite number, classification, ....". The "..." leaves much implied. TLES don't have an "orbit type", but perhaps what is meant is "ephemeris type". If so the implementation and the documentation currently do not match.

BSTAR can be estimated, but it is always initialized to zero instead of being read from the template TLES. This creates two problems. First it is impossible to have a non-zero BSTAR that is not estimated. Can be useful to assume a nominal level of drag/SRP when there is not enough data to solve for it. Second, it is impossible to specify the initial condition for BSTAR. If the BSTAR of the object was previously known then that data should be used in the initial condition to speed convergence.

The mean motion first and second derivative are purely informational. Without a method to compute those derivatives it would be nice to be able to set them via the template.

Changing how these parameters are handled would be API compatible but change the semantics. So I think the changes should be implemented in another constructor or factory method or wait for a major release.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
11.0
Milestone
11.0
Assign milestone
Time tracking
None
Due date
None
Reference: orekit/orekit#688