Uploaded image for project: 'GMAT'
  1. GMAT
  2. GMT-6777

Synchronized propagation does not display correctly

    Details

    • Sprint:
      R2019a

      Description

      The attached script propagates 3 spacecraft. All three start from the same initial state. All three propagate correctly for the first 0.1 days. All three turn on a thruster at that point. The thrusters have different thrust magnitudes, but all point in the velocity direction. At that point, the spacecraft display as no longer coplanar, even though they are physically coplanar.

      Note that when the bad plotting occurs, the center of the bad trajectories is not the center of the Earth.

      The script propagates to an RMAG value, and turns off the thruster when that value is reached. As can be seen by running the script, the final spacecraft orbits are again coplanar when all is said and done. But there is something wonky in the middle part of the propagation taht makes GMAT present invalid data.

      A screen snap is also attached. I see this behavior on Linux and Windows. Have not checked Mac.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            ravidavi Ravi Mathur added a comment -

            I tried this out in the OpenFramesInterface, with exactly the same results as OrbitView. Some details:

            Sat35 stays in its initial equatorial (or rather, near-equatorial) plane for the entire period
            Sat20 starts out in the equatorial plane, switches to an offset polar plane, then goes back to the equatorial plane
            Sat10 starts out in the equatorial plane, switches to an oscillating rectilinear orbit that intersects the Earth for a while, then switches to the same offset polar plane as Sat20, then goes back to the equatorial plane

            Each time a satellite switches between one plane and the next, it corresponds to a thruster turning on or off.

            Show
            ravidavi Ravi Mathur added a comment - I tried this out in the OpenFramesInterface, with exactly the same results as OrbitView. Some details: Sat35 stays in its initial equatorial (or rather, near-equatorial) plane for the entire period Sat20 starts out in the equatorial plane, switches to an offset polar plane, then goes back to the equatorial plane Sat10 starts out in the equatorial plane, switches to an oscillating rectilinear orbit that intersects the Earth for a while, then switches to the same offset polar plane as Sat20, then goes back to the equatorial plane Each time a satellite switches between one plane and the next, it corresponds to a thruster turning on or off.
            Hide
            djcinsb Darrel Conway added a comment - - edited

            The issue is that, during finite burns, the propagation state vector includes mass as a propagated element. That means that the published data is 7 elements long, and the concatenated vector map has more elements than the subscriber is accomodating. There is a RegisterPublishedData call to the publisher in Initialize that passes in the mapping of the state vector. That call will miss transient forces. An update should be made in PrepareToPropagate instead if the transient force map changes after initialization. Once that is set up, we also need to ensure that the subscribers respond the the remapping, of course.

            An alternative is to drop passing of the mass term to the subscribers. (I've done that locally to test the state vector mapping hypothesis, and it works for the script attached to this ticket.) That approach is likely more error prone, though, because we already have code in place to handle propagation of additional things (like the STM) in addition to the mass in the prop state vector.

            Show
            djcinsb Darrel Conway added a comment - - edited The issue is that, during finite burns, the propagation state vector includes mass as a propagated element. That means that the published data is 7 elements long, and the concatenated vector map has more elements than the subscriber is accomodating. There is a RegisterPublishedData call to the publisher in Initialize that passes in the mapping of the state vector. That call will miss transient forces. An update should be made in PrepareToPropagate instead if the transient force map changes after initialization. Once that is set up, we also need to ensure that the subscribers respond the the remapping, of course. An alternative is to drop passing of the mass term to the subscribers. (I've done that locally to test the state vector mapping hypothesis, and it works for the script attached to this ticket.) That approach is likely more error prone, though, because we already have code in place to handle propagation of additional things (like the STM) in addition to the mass in the prop state vector.

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: