[Question] Convergence instability with coupled Mach/Altitude optimization in long-endurance cruise

[OscarEspinosaBarcenas]

Hi Aviary team,

I am working on a trajectory optimization for a UAV monitoring mission (15km climb/descent with an 8-hour cruise), and I have successfully converged the simulation when optimizing Mach with altitude fixed.

But when I attempt to optimize both Mach and Altitude simultaneously to open up the design space, the problem fails to converge. I tried increasing the polynomial order for both variables from 1 to 3 to add degrees of freedom, but this resulted in unrealistic altitude oscillations (dipping and rising during cruise) rather than a steady flight path (see attached image).

Therefore, could you offer recommendations on the best approach for polynomial orders in long-duration phases? I suspect the higher order might be introducing instability, so I am wondering if I should focus on segmentation instead or if I should share my full phase_info for a deeper look.

Thanks for your support,

Oscar

phase_info_optimization.py

[OscarEspinosaBarcenas]

Hello again!

I updated the phase_info based on the segmentation strategy. I increased the segments (Climb: 12, Cruise: 5, Descent: 5) and reduced the polynomial orders (Cruise: 1, Climb/Descent: 2). I also unlinked the specific initial/final Mach/Altitude constraints in Cruise to let the phases flow naturally.

The main convergence issues are solved, but I am now seeing a physical violation in the first 100s of the Climb phase. The aircraft "dives" below my initial altitude of 3,000 ft (ground level) before rotating up. It seems the optimizer is trading altitude for airspeed to meet the Mach constraints.

Therefore, what is the standard way in Aviary to prevent this initial dive, considering I am using the Height Energy EOM?

• Constraint: Would you recommend a path constraint on the altitude rate ($\dot{h} \ge 0$) or the flight path angle ($\gamma \ge 0$)? I am unsure which plays better with the Energy EOM formulation.
• Phase: Or is this a sign that I must model a distinct "rotation" phase (even though I currently lack low-speed/ground-effect aero tables)?

Thanks again,
Oscar

phase_info_optimization.py

[Kenneth-T-Moore]

Hey, Oscar

Aviary has a built-in constraint to prevent descending during climb. In the phase_info, you can set the no_descent option to True to turn it on. There is a companion no_cimb option that you can use in descent phases to prevent climbing. I've seen this happen before too, which is why we added those options. Having low-speed aero would probably be more accurate overall, but I don't think it affects convergence of a climb-cruise-descent with no landing.

Nice work on getting things to converge. It can sometimes be a challenge getting a new aircraft model working, and we are always looking for ways to communicate to the user what is happening.

[OscarEspinosaBarcenas]

Hi @jkirk5,

I am attempting to implement this locally myself.

My approach is to:

1. Define $C_L$, $C_D$, and $C_m$ as new variables using the Dynamic class and generate their metadata.
2. Update my trim component to use these standardized names (e.g., Dynamic.Vehicle.LIFT_COEFFICIENT) instead of the local internal names.
3. In the builder, I planned to expose these variables so the recorder picks them up.

I was thinking of passing them via the get_states() function in the builder, but since these are algebraic variables (no time integration/rates involved), should I be using a different method to ensure they appear in the timeseries without being treated as state variables?

Thanks,
Oscar

[Kenneth-T-Moore]

Hey, Oscar. There is a get_timeseries method that you can use to add variables to the timeseries from your custom subsystem.

[OscarEspinosaBarcenas]

Hi @Kenneth-T-Moore ,

I searched for the get_timeseries method in subsystem_builder_base.py, but I couldn't find it. I'm currently working with version 0.10-dev (commit 867efc5). Is it possible that subsystem_builder_base.py wasn't updated in this commit?

I tried to use get_outputs as a workaround. In my builder, it looks like this:

    def get_outputs(self):
        
        return [Dynamic.Vehicle.ANGLE_OF_ATTACK,
                ExtendedAircraft.Vehicle.LIFT_COEFFICIENT,
                ExtendedAircraft.Vehicle.DRAG_COEFFICIENT,
                ExtendedAircraft.Vehicle.PITCH_MOMENT_COEFFICIENT]

However, when running the mission, I get the error: 'ValueError: Unable to find the source 'angle_of_attack' in the ODE.'

I haven't pulled your latest version yet because I'm worried about breaking my current setup, specifically regarding phase_info and the engine deck definitions. I am currently doing this:

av.preprocess_propulsion(
    aviary_options=inputs,
    engine_models=[engine_1, engine_2]
)

# Load inputs and build problem
prob.load_inputs(inputs, phase_info, engine_builders=[engine_1, engine_2], verbosity=verbosity)

I can't recall if this is still the current standard or if there is a new method.

Could you confirm if an upgrade is required to get get_timeseries?

Thanks, Oscar

[OscarEspinosaBarcenas]

Hello again,

I managed to solve the issue with my custom builder! However, the solution raised a question about how Aviary/OpenMDAO handles variable promotion, and I was hoping for some clarification.

Initially, I tried to promote the outputs explicitly in my mission_outputs method like this:

def mission_outputs(self, **kwargs):
        return [
            Dynamic.Vehicle.ANGLE_OF_ATTACK,
            Dynamic.Vehicle.LIFT,
            Dynamic.Vehicle.DRAG,     
            ExtendedAircraft.Vehicle.LIFT_COEFFICIENT,
            ExtendedAircraft.Vehicle.DRAG_COEFFICIENT,
            ExtendedAircraft.Vehicle.PITCH_MOMENT_COEFFICIENT,
        ]

This resulted in promotion errors where the variables couldn't be found. However, I recalled the 'aircraft:*' pattern used in mission_inputs() in the external subsystem examples. When I switched the specific coefficients to a wildcard pattern, it worked perfectly:

def mission_outputs(self, **kwargs):
        return [
            Dynamic.Vehicle.ANGLE_OF_ATTACK,
            Dynamic.Vehicle.LIFT,
            Dynamic.Vehicle.DRAG,
            'dynamic:*',  # <--- This solved it
       ]

Why does the wildcard 'dynamic:*' succeed in promoting the coefficients (like lift_coefficient) when listing them explicitly via their metadata name failed?

Thanks,
Oscar

[Kenneth-T-Moore]

Hi @Kenneth-T-Moore ,

I searched for the get_timeseries method in subsystem_builder_base.py, but I couldn't find it. I'm currently working with version 0.10-dev (commit 867efc5). Is it possible that subsystem_builder_base.py wasn't updated in this commit?

I tried to use get_outputs as a workaround. In my builder, it looks like this:

It looks like get_outputs was renamed to get_timeseries in a commit in August, but the PR probably didn't make it in until much later. So I think that get_outputs is the right workaround for an older version of the code.