OpenMDAO / Aviary

NASA's aircraft analysis, design, and optimization tool
https://openmdao.github.io/Aviary/
Other
134 stars 59 forks source link

Make initial guessing consistent in terms of (initial, final) value pairs or (initial, duration) #233

Open johnjasa opened 5 months ago

johnjasa commented 5 months ago

Desired capability or behavior.

Migrated from old repo:

"I thought that, for initial guesses on dymos phases, we provide an initial and final value. Here it looks like an initial value and a delta, which is a little inconsistent."

Originally posted by @Kenneth-T-Moore

John's response: I agree with you it's a bit inconsistent. This is true because Dymos is expecting initial-final pairs for some things and initial-duration pairs for others (like time or in this case, mass). We can remove that complexity from an Aviary user though with some quick math. I'll make an issue based on your comment for this.

This will be a breaking non-backwards-compatible change, must increment version accordingly.

Is your feature request related to a problem? Please describe.

No response

Associated Bug Report

No response

cmbenne3 commented 3 weeks ago

@Kenneth-T-Moore and I discussed this in detail, and we think that this issue could be closed with no change.

The initial guesses specified in phase info are all treated as [initial_val, end_val] except time, which requires [initial_val, duration]. Since time is the Dymos integration variable and expects the guess to be specified as initial_val, duration then I think we could simply add a description in documentation to explain why this initial guess should be specified by the user in a different way?

What do others think @jkirk5 ?

If we wanted to be completely consistent then I think we could make a small change to handle time specifed as [initial_time, end_time] and calculate duration = end_time - initial_time before sending [initial_time, duration] to dymos.

cmbenne3 commented 3 weeks ago

Update - Thanks @kaushikponnapalli & @crecine for the help. Sometimes Mass is used as the integration variable (2DOF, Cruise), and so we need to be able to handle this case. Plan is to make initial_guesses consistent with [initial, final] for all guesses in phase info, add a check from Dymos to find what the integration variable is, and for that variable calculate 'duration' to send to Dymos. All the remaining guesses are expected in the format [initial, final] so no further transformation is required.