Custom 2DOF EOM with velocity/flight path angle as Dymos states. Endpoint singularity when linking flight path angle across a climb-level flight phase junction

[OscarEspinosaBarcenas]

Hi Aviary dev team,

In Aviary's own two_dof/solved_two_dof phases, the flight path angle (γ) is never a linked Dymos state. It's calculated using an inner Newton/BalanceComp trim solve, or arctan(dh/dr). Is that a design choice? Linking γ across phase boundaries can cause endpoint singularities. Would you suggest a way to keep γ as an explicit collocated state? I want to handle a climb-cruise transition smoothly.

For context, I've implemented a 2DOF EOM following the same physics as Aviary's 2DOF, but as explicit Dymos states rather than an inner trim solve::

m dV/dt         = T cos α - D - W sin γ
m V dγ/dt   = L + T sin α - W cos γ
dh/dt           = V sin γ
dx/dt           = V cos γ
dm/dt           = fuel flow

where v and γ are both Dymos states with their own rate outputs and analytic partials, integrated and collocated like any other state. I did this to get γ directly as an optimizer DOF at every node.

A climb phase feeds into a cruise phase. The level phase enforces constant altitude by settingγ ≡ 0 at every node (fixed initial value + zero-width bounds), rather than constraining altitude directly. The climb phase carries a monotonic path constraint, Dynamic.Mission.ALTITUDE_RATE >= 0 (from Aviary's own no_descent option).

If I let Dymos connect γ continuity at that junction, I then get γ_climb,final = γ_level,initial = 0 from the link. The climb phase's own ḣ ≥ 0 constraint activates at that same node, where the mission is physically leveling off. Both pin the same node to γ = 0 with proportional gradients (∂ḣ/∂γ = V cos γ ≈ V near γ=0). IPOPT's dual infeasibility spikes by 6-7 orders of magnitude at that point and the run falls into restoration and never recovers.

My current workaround is to exclude γ from the linked-variables set specifically for junctions touching a level phase, leaving the climbing phase's final γ free. I'm attaching two picture to show what I meant.

I'm happy to share the full EOM component and IPOPT log if useful, and thanks again for the help in advance.
Oscar

[OscarEspinosaBarcenas]

Hi team,

Quick update on the γ-junction issue: I bypassed the restoration-phase blow-up by unlinking γ at junctions touching a level phase. While this stopped the immediate crashes, γ still spikes near phase endpoints (specifically, at the neighboring node next to the unlinked endpoint, γ now sits pinned at its bound before dropping sharply) (see attached plot and the previous gamma vs distance above). After reviewing a separately converged run, I now suspect these spikes are genuine features of the optimal trajectory rather than numerical artifacts, though unlinking the endpoint may have just shifted the difficulty one node over.

The actual issue preventing convergence is in the descent phase of a refined mesh: IPOPT cannot fully satisfy the γ collocation defect. Mesh refinement, higher polynomial orders, and loosened constraint scaling have all failed to resolve this. Looking at the convergence trend, it may just need more iterations rather than being structurally stuck: primal infeasibility is still decreasing (slowly and noisily), dual infeasibility has settled into a constant band, and the γ defect only stopped spiking in the last 50 iterations.

My custom EOM uses a SAND formulation (collocating γ, V, h, x, m explicitly) with an inner Newton solve for elevator trim (IDF-style). This contrasts with Aviary's native approach, which derives γ from an inner trim/arctan solve.

I am benchmarking against Kaneko's SAND results. His well-initialized cases converge in 60–100 iterations to a 1e-6 tolerance. My runs take 400–600+ iterations and struggle to reach a 1e-4 tolerance, though his benchmark missions were takeoff-climb, not my 5-phase mission, which likely accounts for part of the gap.

My questions are:

Is there something about explicitly collocating γ that makes phase endpoints structurally harder to converge, especially when transitioning into or out of level flight?

Is this massive performance gap familiar, or does it point to a fundamental flaw in how my setup is structured?

I am happy to share the full EOM component, IPOPT logs, or plot data if useful.

Thanks,
Oscar

[jkirk5]

@Kenneth-T-Moore

[Kenneth-T-Moore]

Hey, Oscar. I think I would like to see the full EOM component so that I can fully understand what is going on. I do agree that you need gamma to go to zero at the end of the climb phases so that you have a smooth transition. This may mean you want to have more points at the ends of those phases, which you can get with LGL for the segment ends, but I think you are already doing that.