solved_2dof treating time as distance

[EdoAlvarezR]

Hi Aviary Team!

I noticed that TwoDOFPhase defines time as having units of ft and the level 2 detail TOL examples do the same thing. Rather than a bug, I imagine this is consistent with what is mentioned in the tutorial regarding the distance being the integration variable, but I'm still struggling to wrap my head around that: I see in the example that time inputs under user_options are treated as a distance, but initial time guesses are still in time units.

Could you guys provide more guidance on when to treat time as distance and when not?

-Ed Alvarez

[jkirk5]

The intent is for users to not have to worry about that swapping, but it looks like that isn't fully implemented in phase_info. Ideally all user-facing API that refers to "time" would point to the actual mission time regardless of any aliasing that happens under the hood to trick dymos. I don't have a great answer for which specific options currently do/do not take the swapping into account, but you should probably get a mismatched units error if you use the wrong one. I will make a new issue for this! I believe the only phases where the time/distance flip happens is 2DOF takeoff/landing and cruise (which is a breguet range cruise).

[jkirk5]

#856

[EdoAlvarezR]

Great, thanks Jason! @jkirk5

In the meantime I ended up moving on to do a FwGm formulation of the aircraft and mission that I'm trying to optimize. I'm still in the process of migrating from Fm to Gm, so I haven't gotten to test GASP's 2DOF yet.

In your experience, how do Fm and Gm compare? Are Gm optimizations as robust as Fm? In what scenarios would you recommend using Fm over Gm?

[jkirk5]

Height-Energy (FLOPS) will typically be more robust, as the flight physics are simpler for the optimizer to solve. It's a point-mass approximation, which is often sufficient for low-fidelity analysis. If you care about angle of attack in any way you'll want to use the 2DOF (GASP) mission. 2DOF missions are currently less flexible as GASP had very specific assumptions about phase name, order, and how subsystem analysis needs to change per phase that still persist in Aviary's code. TLDR I'd recommend copying the existing default phase_info for 2DOF and modify that. Be aware that changing phase order, name, or number of phases might break things, but you'll probably get very obvious errors if it does