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

Investigate Command Mode Parameter Setting

    Details

      Description

      Investigate impact of opening up more parameters to being settable in command mode (after begin mission sequence is reached in script)

      The initial components to examine are differential corrector, Ephemeris Propagator and Orbit View. For Orbit View the parameter of interest is viewpoint vector. This may be moved to a subtask as it involves interaction with WxWidgets.

      More resources may be added to this.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            mstark Mike Stark added a comment -

            Added 12 hours for implementing 1 option of how to make parameters commandable (add command function) – probably to illustrate we need to find better way

            Show
            mstark Mike Stark added a comment - Added 12 hours for implementing 1 option of how to make parameters commandable (add command function) – probably to illustrate we need to find better way
            Hide
            mstark Mike Stark added a comment -

            In the short term , continuing to explicitly add tests on parameter ID in IsParameterCommandModeSettable() is the way to go. I’ve also discerned from reading the code that it is expected that whoever is trying to set a parameter is responsible for calling IsParameterCommandModeSettable() and only changing the value if it returns true. I didn’t see anything internal to the SetParameter() functions that was doing this.

            I have created the start of a process for determining which parameters are changeable in command mode and a template for recording decisions about each parameter. Those files were e-mailed to Darrel a while back.

            For the long term solution, there are two options, one of which is conceptually easy but entails a lot of work that must be done all at once, the second of which is a lot of work, but allows it to be done over time. In addition, it may be able to add protection against bad parameter changes, reading the GmatBase derived code alone makes it look like even if you test to see whether something is changeable there is nothing to actually prevent the change from being made. To be fair, I haven’t read the Interpreter code that would make that decision.

            Option 1 – in GMAT base, simply set the default to allow command mode parameter setting (by returning true), and continue to expect caller to check before setting parameter when in command mode. The drawback is that we need to check every parameter in the system to determine if we want to disallow command mode updates of the value. We would also need to document these decisions in the User Interface Spec document, and update that document to be consistent with the code.

            Option 2 – keep the default as is, and go through all the code to add permission to change where appropriate. This is probably more effort than Option 1, but it doesn’t have to be done all at once. We would still need to update User Interface specification to be consistent with code.

            Protecting from bad changes – have objects determine for themselves if they are in command mode to add protection against bad calls to set parameters. I am assuming that the system’s run state is kept somewhere and that GmatBase could access that “somewhere” to determine whether the system was past BeginMissionSequence. This may not be necessary, if check is already done in the Interpreter and the assumption that the check is always done is documented in the Interpreter design.

            That is the result of my investigation, which has all been done by examining EphemerisPropagator. I implemented most if not all the changes for that class. The ticket also calls out the DifferentialCorrector and OrbitView; If these are needed for our customer Voldemort my suggestion is to go ahead and do them leaving “return false” in GmatBase. IsParameterCommandModeSettable(), because there is no way we’ll get the wholesale changes made in a short time span.

            I will call this investigation ticket resolved, and we should put in 1 or more tickets for the implementation of these changes in EphemerisPropagator, DifferentialCorrector, and OrbitView, depending on whether you want me do all of them or to split the work.

            Show
            mstark Mike Stark added a comment - In the short term , continuing to explicitly add tests on parameter ID in IsParameterCommandModeSettable() is the way to go. I’ve also discerned from reading the code that it is expected that whoever is trying to set a parameter is responsible for calling IsParameterCommandModeSettable() and only changing the value if it returns true. I didn’t see anything internal to the SetParameter() functions that was doing this. I have created the start of a process for determining which parameters are changeable in command mode and a template for recording decisions about each parameter. Those files were e-mailed to Darrel a while back. For the long term solution, there are two options, one of which is conceptually easy but entails a lot of work that must be done all at once, the second of which is a lot of work, but allows it to be done over time. In addition, it may be able to add protection against bad parameter changes, reading the GmatBase derived code alone makes it look like even if you test to see whether something is changeable there is nothing to actually prevent the change from being made. To be fair, I haven’t read the Interpreter code that would make that decision. Option 1 – in GMAT base, simply set the default to allow command mode parameter setting (by returning true), and continue to expect caller to check before setting parameter when in command mode. The drawback is that we need to check every parameter in the system to determine if we want to disallow command mode updates of the value. We would also need to document these decisions in the User Interface Spec document, and update that document to be consistent with the code. Option 2 – keep the default as is, and go through all the code to add permission to change where appropriate. This is probably more effort than Option 1, but it doesn’t have to be done all at once. We would still need to update User Interface specification to be consistent with code. Protecting from bad changes – have objects determine for themselves if they are in command mode to add protection against bad calls to set parameters. I am assuming that the system’s run state is kept somewhere and that GmatBase could access that “somewhere” to determine whether the system was past BeginMissionSequence. This may not be necessary, if check is already done in the Interpreter and the assumption that the check is always done is documented in the Interpreter design. That is the result of my investigation, which has all been done by examining EphemerisPropagator. I implemented most if not all the changes for that class. The ticket also calls out the DifferentialCorrector and OrbitView; If these are needed for our customer Voldemort my suggestion is to go ahead and do them leaving “return false” in GmatBase. IsParameterCommandModeSettable(), because there is no way we’ll get the wholesale changes made in a short time span. I will call this investigation ticket resolved, and we should put in 1 or more tickets for the implementation of these changes in EphemerisPropagator, DifferentialCorrector, and OrbitView, depending on whether you want me do all of them or to split the work.
            Hide
            dcooley Steve Cooley added a comment -

            SES awaiting answer to question on whether or not this is a permanent change.

            Show
            dcooley Steve Cooley added a comment - SES awaiting answer to question on whether or not this is a permanent change.
            Hide
            dcooley Steve Cooley added a comment - - edited

            SES: I think we want this code to be permanent.
            1) How many new parameters can now be set in command mode?
            2) Can you test that the parameters that are being set in command mode do what we expect? This is usually easy to do. There are usually some tests where the same parameters are being set in mission mode. The command mode and mission mode results should be the same.

            Show
            dcooley Steve Cooley added a comment - - edited SES: I think we want this code to be permanent. 1) How many new parameters can now be set in command mode? 2) Can you test that the parameters that are being set in command mode do what we expect? This is usually easy to do. There are usually some tests where the same parameters are being set in mission mode. The command mode and mission mode results should be the same.
            Hide
            sslojkowski Steven Slojkowski added a comment -

            The affected parameters are EphemPropagator.EpochFormat and EphemPropagator.StartEpoch.

            I modified the failing test cases so that they now pass. I also changed the EphemPropagator_StartEpoch_ChangeInMission test to check that the new functionality works as expected.

            I think this ticket can probably be closed now, but I pass back to Mike for comment or final disposition.

            Show
            sslojkowski Steven Slojkowski added a comment - The affected parameters are EphemPropagator.EpochFormat and EphemPropagator.StartEpoch. I modified the failing test cases so that they now pass. I also changed the EphemPropagator_StartEpoch_ChangeInMission test to check that the new functionality works as expected. I think this ticket can probably be closed now, but I pass back to Mike for comment or final disposition.

              People

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

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 days Original Estimate - 2 days
                  2d
                  Remaining:
                  Time Spent - 1 day, 3 hours Remaining Estimate - 1 day, 1 hour
                  1d 1h
                  Logged:
                  Time Spent - 1 day, 3 hours Remaining Estimate - 1 day, 1 hour
                  1d 3h