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 54
    • Issues 54
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 7
    • Merge Requests 7
  • 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
  • #685

Closed
Open
Opened May 27, 2020 by Evan Ward@evanward1Developer

AnalyticalPropagator event RESET_STATE behavior when newState is null

The implementation of AbstractAnalyticalPropagator.acceptStep(...) has this oddity:

if (action == Action.RESET_DERIVATIVES || action == Action.RESET_STATE) {
    // some event handler has triggered changes that
    // invalidate the derivatives, we need to recompute them
    final SpacecraftState resetState = occurrence.getNewState();
    if (resetState != null) {
        resetIntermediateState(resetState, interpolator.isForward());
        return resetState;
    }
}

resetState is only null if action == Action.RESET_STATE and the event handler returned null for the new state. In this case the RESET_STATE behaves the same as Action.CONTINUE because the method does not return here. This breaks the contract for RESET_STATE which requires that other event detectors are re-checked. It also seems to be an invalid return value of resetState(...) which makes no mention of this special behavior for null. I think the correct behavior would be to throw a NPE in this case.

I'm leaning towards fixing this in 11.0 as it appears to be an undocumented "feature" from before at least 2015.

When fixing this also check that no resetState(...) methods in Orekit return null. At least RecordAndContinue needs to be updated by deleting the method override.

To upload designs, you'll need to enable LFS and have 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#685