Report File and STM printing

Spacecraft, Thruster, Tank, Propagator, CoordinateSystem, etc.

Re: Report File and STM printing

Postby shughes » Sat Jul 14, 2012 2:53 am

marchand wrote:Thanks Steve. Here's some related questions, with some code attached.

(1) Just to clarify, when you say the propagation is always done relative to Mean J2000 Equator axes centered at the body, do you mean the Earth Mean Equator and Equinox of J2000? Let me pose the question in a specific context. When I do a propagation, outside of GMAT, I will often do so in a body centered frame, where the reference axes are consistent with those of the Earth Mean Equator and Equinox of J2000 (the reference frame for the DE405 ephemeris). Is that consistent with how GMAT does the propagation?

That is correct except that the DE405 ephemerides are not in Earth Mean Equator and Equinox of J2000 they are in the GCRF. J2000 and GCRF/ICRF agree to a few microarcseconds though. We are currently ignoring that difference in the equations of motion.

marchand wrote:(2) Following that train of thought, is it safe to say then that it is currently not possible for GMAT to perform a numerical integration in terms of rotating coordinate systems then? For instance, in multi-body systems, a synodic rotating frame is often the frame of integration, not just the frame in which the data is displayed. This approach is often desirable due to the dynamically sensitive nature of the problem. Just want to confirm, once again, that this is not a capability currently supported.

That is correct. We've flown weak stability lunar libration missions using inertial reference frames to integrate the equations of motion without any trouble.

marchand wrote:(3) The attached script includes some lines after the EndTarget line which store the spacecraft state and state transition matrix at the end of the propagated trajectory segment. Since the trajectory spans over seven segments, the arrays have seven rows. The patchState array is of dimension 7x6, each of the six columns represents one state: X, Y, Z, VX, VY, VZ. The patchSTMs array is of dimension 7x36, and each column consists of one element of the STM. The patchSTMs array was filled in column order format. I'd also like to store the time at the end of each propagated segment. In a trial and error first attempt, I added line #275 to the script, which is currently commented out because it causes an error during execution. Apparently, I am unable to access the Epoch field, even though that is listed as one of the spacecraft object fields in Spacecraft.cpp. Is there a way to procure that information within the GMAT scripting environment?

See spec (which i think has been moved to user's guide) here: ... Cs6s/edit#

marchand wrote:(4) I noticed, by looking at the output files generated by the script, that the elements of the STM continue to grow with each propagation. Thus, I'm inclined to think that the STM is not "Reset" each time the propagator is called in this example. I had noted, earlier on, that there is a method in the Spacecraft.cpp class called TakeAction, and one of the actions listed is ResetSTM. However, a recursive grep search through the entire source tree reveals that this action is never referenced by any classes, which confirms my suspicion that the STM is never reset during the propagation. I'd still like confirmation, if you can, that this is the case.

Thanks :-)

You are correct. The STM is not reset. One way you can reset is to reassign the spacecraft object back to its initial conditions

Code: Select all
InitSat = DefaultSC;
Propagate DefaultProp(DefaultSC,'STM') {DefaultSC.ElapsedSecs = 12000.0};
Report rf DefaultSC.OrbitSTM
DefaultSC = InitSat;
Propagate DefaultProp(DefaultSC,'STM') {DefaultSC.ElapsedSecs = 12000.0};
Report rf DefaultSC.OrbitSTM
Posts: 443
Joined: Mon Jun 09, 2008 6:27 pm


Return to GMAT Resources

Who is online

Users browsing this forum: No registered users and 1 guest