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

Setting Partial State in Assignment Mode Changes Independent State Values

    Details

      Description

      Created an attachment (id=1470)
      StateSetBug.script

      22 Dec. 2011 build

      In the attached script I create and set only the following lines on a spacecraft:

      Create Spacecraft Sc;
      Sc.RadApo = 9000
      Sc.RadPer = 6500

      The resulting report data should therefore have default values for INC, RAAN, AOP, and TA. However, they are not the default values.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              gmat_wcs Wendy Shoan added a comment -

              Please specify the text for the error message.

              From last email exchange:

              That is basically what I was doing yesterday except that the Spacecraft code does not store the state in the UserCoordinateSystem; it stores it in the internalCoordSystem (which is, as far as I can tell, always the same as MJ2000Eq). The calculation does use the mu from the UserCoordinateSystem. (If the origin is not a CelestialBody, the originMu remains at 0.0; that doesn't seem to be what we want ... or is it?).

              Using the attached script, everything goes fine until the LunaMJ2000Eq is set on EquinocSat. The default cartesian is converted to that coordinate system fine (Algorithm Step 1). But when it tries to do the cartesian-to-equinoctial part (Algorithm Step 2), it throws an exception:

              Spacecraft::SetRefObject() 'EquinocSat', coordinateSystem=InternalEarthMJ2000Eq<0x2594bd30>, cs=LunaMJ2000Eq<0x25960eb0>
              About to convert to new CS 'LunaMJ2000Eq'
              Spacecraft::SetRefObject() calling TakeAction - ApplyCoordinateSystem
              Spacecraft::TakeAction() Converting cartesian default to state type Equinoctial
              coordinateSystem = LunaMJ2000Eq
              originMu = 4902.8005821478
              ->default cartesian is: 7100 0 1300 0 7.35 1
              and current input state is: 14052.5735936245 0.0000000000 -0.0000000000 -0.0000000000 -0.0000000000 282.6122956505
              Spacecraft::GetStateInRepresentation(string): Constructing Equinoctial state
              Spacecraft::GetStateInRepresentation(string): using defaultCartesian = true
              Spacecraft::GetStateInRepresentation(string): Using inState = 7100 0 1300 0 7.35 1
              Spacecraft::GetStateInRepresentation(string): Now converting the inState from InternalEarthMJ2000Eq to LunaMJ2000Eq
              inState successfully converted from InternalEarthMJ2000Eq to LunaMJ2000Eq
              Spacecraft::GetStateInRepresentation(string): state in LunaMJ2000Eq = 363759.3141965024 79490.72726233194 72772.48979236792 -0.2211684811121277 8.28910099240807 1.422928442890082
              Spacecraft::GetStateInRepresentation(string): type is Equinoctial, so calling StateConversionUtil to convert
              Spacecraft::GetStateInRepresentation(string): Using originMu = 4902.8005821478
              Exception thrown: 'SpaceObject Exception Thrown: Error applying coordinate system due to errors in spacecraft state. Utility Exception: Cannot convert from Cartesian to Equinoctial - the orbit is either parabolic or hyperbolic.

              ', so setting back to old CS
              Spacecraft::SetRefObject() 'EquinocSat', coordinateSystem=InternalEarthMJ2000Eq<0x2594bd30>, cs=EarthMJ2000Eq<0x2594c3c0>
              1: **** ERROR **** Interpreter Exception: The Spacecraft "EquinocSat" failed to set CoordinateSystem: SpaceObject Exception Thrown: Error applying coordinate system due to errors in spacecraft state. Utility Exception: Cannot convert from Cartesian to Equinoctial - the orbit is either parabolic or hyperbolic.

              So,
              1) is that exception what you would expect in this case? (This type of code causes the test system to fail a lot of tests).
              2) I am assuming that if the user has entered all 6 elements, I can ignore Algorithm steps 1, 2 and 3, and assume that the input state is in the coordinate system that the user intended/set. Is that correct? If so, then this issue only comes up when the user has set only a partial state (so the current tests will pass; but future partial-state tests may not).

              Wendy

              On Jan 10, 2012, at 1:26 AM, Hughes, Steven P. (GSFC-5950) wrote:

              The algorithm below should automatically take care of mu. Hopefully this response isn’t overkill!

              Definitions
              userStateType: State type of the elements set by user.
              userCoordinateSystem: Coordinate system defined by user.
              userEpoch: Epoch defined by user.
              internalState: The state vector stored on the spacecraft in Cartesian state type w/r/t to userCoordinateSystem.
              defaultState: The default state vector if the user does not set state elements: [7100 0 1300 0 7.35 1] in EarthMJ2000Eq.

              Algorithm
              1) Convert defaultState from EarthMJ2000Eq to userCoordinateSystem
              2) Convert results from step 1 to userStateType represented in userCoordinateSystem. If mu is required, use mu from userCoordinateSystem. (what happens here if the state type is Keplerian and the Coordinate system does not have a celestial body at the origin?)
              3) Replace appropriate elements of the vector from step 2 with the user defined state elements.
              4) Convert results of step 4 back to the cartesian state type and set those elements on the s/c. This will result in setting Cartesian state type in userCoordinateSystem. If mu is required, use mu from userCoordinateSystem.

              Errors/Warnings
              If a user sets userEpoch twice in Assignment mode, throw the following warning: "Warning: you have set the epoch for Spacecraft InsertSatNameHere more than once in assignment mode (i.e. before the BeginMissionSequence command). This may have unintended consequences and you should perform these operations in command mode (i.e. after the BeginMissionSequence command).

              If a user sets userCoordinateSystem twice in Assignment mode, throw the following warning: same as above but replace "epoch" with Coordinate System.

              If a user sets state elements in Assignment mode that are not contained in a single state type throw the following error: "Error: you have set state elements Blah1, and Blah2 and these elements are not contained in the same state type and this is only allowed after the BeginMissionSequence command".

              Show
              gmat_wcs Wendy Shoan added a comment - Please specify the text for the error message. From last email exchange: That is basically what I was doing yesterday except that the Spacecraft code does not store the state in the UserCoordinateSystem; it stores it in the internalCoordSystem (which is, as far as I can tell, always the same as MJ2000Eq). The calculation does use the mu from the UserCoordinateSystem. (If the origin is not a CelestialBody, the originMu remains at 0.0; that doesn't seem to be what we want ... or is it?). Using the attached script, everything goes fine until the LunaMJ2000Eq is set on EquinocSat. The default cartesian is converted to that coordinate system fine (Algorithm Step 1). But when it tries to do the cartesian-to-equinoctial part (Algorithm Step 2), it throws an exception: Spacecraft::SetRefObject() 'EquinocSat', coordinateSystem=InternalEarthMJ2000Eq<0x2594bd30>, cs=LunaMJ2000Eq<0x25960eb0> About to convert to new CS 'LunaMJ2000Eq' Spacecraft::SetRefObject() calling TakeAction - ApplyCoordinateSystem Spacecraft::TakeAction() Converting cartesian default to state type Equinoctial coordinateSystem = LunaMJ2000Eq originMu = 4902.8005821478 ->default cartesian is: 7100 0 1300 0 7.35 1 and current input state is: 14052.5735936245 0.0000000000 -0.0000000000 -0.0000000000 -0.0000000000 282.6122956505 Spacecraft::GetStateInRepresentation(string): Constructing Equinoctial state Spacecraft::GetStateInRepresentation(string): using defaultCartesian = true Spacecraft::GetStateInRepresentation(string): Using inState = 7100 0 1300 0 7.35 1 Spacecraft::GetStateInRepresentation(string): Now converting the inState from InternalEarthMJ2000Eq to LunaMJ2000Eq inState successfully converted from InternalEarthMJ2000Eq to LunaMJ2000Eq Spacecraft::GetStateInRepresentation(string): state in LunaMJ2000Eq = 363759.3141965024 79490.72726233194 72772.48979236792 -0.2211684811121277 8.28910099240807 1.422928442890082 Spacecraft::GetStateInRepresentation(string): type is Equinoctial, so calling StateConversionUtil to convert Spacecraft::GetStateInRepresentation(string): Using originMu = 4902.8005821478 Exception thrown: 'SpaceObject Exception Thrown: Error applying coordinate system due to errors in spacecraft state. Utility Exception: Cannot convert from Cartesian to Equinoctial - the orbit is either parabolic or hyperbolic. ', so setting back to old CS Spacecraft::SetRefObject() 'EquinocSat', coordinateSystem=InternalEarthMJ2000Eq<0x2594bd30>, cs=EarthMJ2000Eq<0x2594c3c0> 1: **** ERROR **** Interpreter Exception: The Spacecraft "EquinocSat" failed to set CoordinateSystem: SpaceObject Exception Thrown: Error applying coordinate system due to errors in spacecraft state. Utility Exception: Cannot convert from Cartesian to Equinoctial - the orbit is either parabolic or hyperbolic. So, 1) is that exception what you would expect in this case? (This type of code causes the test system to fail a lot of tests). 2) I am assuming that if the user has entered all 6 elements, I can ignore Algorithm steps 1, 2 and 3, and assume that the input state is in the coordinate system that the user intended/set. Is that correct? If so, then this issue only comes up when the user has set only a partial state (so the current tests will pass; but future partial-state tests may not). Wendy On Jan 10, 2012, at 1:26 AM, Hughes, Steven P. (GSFC-5950) wrote: The algorithm below should automatically take care of mu. Hopefully this response isn’t overkill! Definitions userStateType: State type of the elements set by user. userCoordinateSystem: Coordinate system defined by user. userEpoch: Epoch defined by user. internalState: The state vector stored on the spacecraft in Cartesian state type w/r/t to userCoordinateSystem. defaultState: The default state vector if the user does not set state elements: [7100 0 1300 0 7.35 1] in EarthMJ2000Eq. Algorithm 1) Convert defaultState from EarthMJ2000Eq to userCoordinateSystem 2) Convert results from step 1 to userStateType represented in userCoordinateSystem. If mu is required, use mu from userCoordinateSystem. (what happens here if the state type is Keplerian and the Coordinate system does not have a celestial body at the origin?) 3) Replace appropriate elements of the vector from step 2 with the user defined state elements. 4) Convert results of step 4 back to the cartesian state type and set those elements on the s/c. This will result in setting Cartesian state type in userCoordinateSystem. If mu is required, use mu from userCoordinateSystem. Errors/Warnings If a user sets userEpoch twice in Assignment mode, throw the following warning: "Warning: you have set the epoch for Spacecraft InsertSatNameHere more than once in assignment mode (i.e. before the BeginMissionSequence command). This may have unintended consequences and you should perform these operations in command mode (i.e. after the BeginMissionSequence command). If a user sets userCoordinateSystem twice in Assignment mode, throw the following warning: same as above but replace "epoch" with Coordinate System. If a user sets state elements in Assignment mode that are not contained in a single state type throw the following error: "Error: you have set state elements Blah1, and Blah2 and these elements are not contained in the same state type and this is only allowed after the BeginMissionSequence command".
              Hide
              jjkparker Joel Parker added a comment -

              Reopening then resolving to fix the empty Resolution field.

              Show
              jjkparker Joel Parker added a comment - Reopening then resolving to fix the empty Resolution field.
              Hide
              jjkparker Joel Parker added a comment -

              Treating this as the master bug again.

              The last comment on GMT-79 is:

              Reassigning to Steve for review of recent email exchange, and specification of appropriate error message.

              Steve, what was this recent email exchange? I need that in order to address this issue.

              Show
              jjkparker Joel Parker added a comment - Treating this as the master bug again. The last comment on GMT-79 is: Reassigning to Steve for review of recent email exchange, and specification of appropriate error message. Steve, what was this recent email exchange? I need that in order to address this issue.
              Hide
              shughes Steven Hughes added a comment -

              CCB: P1 2013a.

              Show
              shughes Steven Hughes added a comment - CCB: P1 2013a.
              Hide
              shughes Steven Hughes added a comment -

              I committed tests for this issue and they all pass.

              Show
              shughes Steven Hughes added a comment - I committed tests for this issue and they all pass.

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: