Remove requirement that engines compute max thrust and other values

[jkirk5]

Summary

Maximum thrust at a given flight condition is required to compute excess specific power for mission. Previously, EngineModels were required to output max thrust, which is a large overhead for users and difficult to clearly communicate through documentation and the API.

The propulsion subsystem was upgraded to check if an EngineModel provides max values (via a new flag, self.compute_max_values, defaulted to False), and if not creates a duplicate copy of the mission components that are fed a throttle & hybrid throttle of 1 instead. No outputs are promoted from this duplicate engine to avoid promotion/connection issues. Thrust outputted by the duplicate engine is directly connected to the engine mux component's max thrust input.

Cleaned up some pieces of propulsion code including formatting, bugfixes, TODO's, etc. as I found them and was able to resolve on the spot.

Disclosure: Generative AI was used to draft coding approaches to handle the parallel engine groups, I ended up not using its suggestions but I did keep a few minor fixes it tried. Code in propulsion_mission.py: lines 6 and 49 (plus indenting the lines I already wrote immediately following that line) were added by AI. The Cursor IDE was used, which does not disclose which LLM models it uses.

Related Issues

• Resolves Automate handling of max thrust computation in propulsion #493

Backwards incompatibilities

EngineModels that already compute max thrust can continue to do so as long as they add the compute_max_values flag as True in their models. If they don't, their component will get duplicated, which theoretically shouldn't break anything but will be very inefficient.

New Dependencies

None

[jkirk5]

I am currently testing out removing max value computation from the turboprop model. This is pretty tricky and may have exposed some broken edge cases in the current implementation. Please do not merge yet!!

[jkirk5]

I am currently testing out removing max value computation from the turboprop model. This is pretty tricky and may have exposed some broken edge cases in the current implementation. Please do not merge yet!!

This task is now complete! There is still additional cleanup and other small improvements that could be made (mostly within the turboprop component itself), but the core concept works

[Kenneth-T-Moore]

Would like to hear more about this bug to understand what is going on.

[jkirk5]

In phase_info you currently pass all model options for the turboprop in a single dict, which gets offered to each subcomponent of the turboprop:
{'turboprop_name': {'option_1': 'val', 'option_2': 'val'}}

Let's say both the motor and the propeller both need option_1, but want different values - the current code doesn't support that. A potential solution is to add support for nested kwargs for turboprop, so:
{'turboprop_name': {'motor_name': {'option_1': 'val_1'}, 'propeller_name': {'option_1': 'val_2'}, 'option_2': 'val'}}

[Kenneth-T-Moore]

This definitely needs some cleanup to remove all the commented-out code. Github history preserves these, so we don't need to keep it in the code.

[Kenneth-T-Moore]

A few TODOs on the code that needs to be uncommented in the future update.