Payload weight not tight in multi-mission

[mayork]

@1ozturkbe when running multimission solve with different numbers of passengers (see https://github.com/hoburg/d8/commit/bf553a20036eeb2b4aebebc137140a7ca989a629) payload weight is only tight for n_{pax} = 180 (i.e. the highest payload weight). It's possible this has something to do with breguet range wanting a heavier aircraft...not sure. Anyways, I think you should either find a way to make that constraint tight or develop a good explanation for why it isn't (if there's a good reason for why it isn't this means the aircraft should always be designed for the max payload case - an interesting result).

[1ozturkbe]

This is a really odd phenomenon. Would not expect this for a fuel objective, but a similar thing was happening for when I was running a PRFC optimization for a single-point mission. Don't think it has to do with breguet range, because to me an aircraft carrying less payload must necessarily burn less fuel... I will try and figure out what is going on.

[mayork]

Oddly enough breguet range does apply an upward pressure on weight. I did a write up on this, can send over in a bit.

[1ozturkbe]

It makes zero sense... Will investigate.

[1ozturkbe]

This definitely has to do with the way we use vectorized variables in constraints. It is a discussion of when a variable is used in a constraint, whether we care about the value of that variable for the segment, or we care about its min or max. Eg for:

aircraft['PRFC'] == aircraft['W_{f_{primary}}']/g*aircraft.engine['h_{f}']/(ReqRng*aircraft['W_{payload}']

We care that we create 3 of this constraint, vectorizing for the different missions. Whereas for:

Ltow*self.wing['L_{max}'] >= self.wing['N_{lift}'] * W_total + self.HT['L_{h_{max}}']

We want three constraints, only vectorizing for Wtotal, since the rest of the variables are static variables. This means that we care about max(W{total) in this specific case. @bqpd what is the right nomenclature so we can make sure these constraints are being generated properly? I'm not clear on this. For example, is this the right implementation for the above constraint?

Ltow*self.wing['L_{max}'] >= self.wing['N_{lift}'] * W_total[:] + self.HT['L_{h_{max}}']

[1ozturkbe]

The reason I suspect this is the issue is because, not only do the payload weights match up, but so do the total aircraft weights, for different flight ranges. That definitely should not happen.

[1ozturkbe]

@bqpd bumping this. Let us know if you have an idea.

[bqpd]

Ltow*self.wing['L_{max}'] >= self.wing['N_{lift}'] * W_total + self.HT['L_{h_{max}}']

should work just fine; are you adding the [:] for readability?

[bqpd]

To be clear, is the bug here that you only want one of the N constraints generated, the one with the largest W_total, to be tight?

Berk: We want all N constraints generated just in case, knowing all well that only one will be tight.

[1ozturkbe]

I just want to make sure that there isn't something going wrong combinatorially when we have multiple vector variables in a single equation. Eg. if we have 2 vector variables, that it only generates n constraints, not n^2. Because the results we have been getting suggest otherwise.

[bqpd]

yup, only n. You'd have to explicitly call .outer if you wanted n^2.

[1ozturkbe]

Hmm ok, then it doesn't seem like our current implementation is error-prone. Thanks @bqpd, must be something else.

[bqpd]

:))

On Wed, Jul 12, 2017 at 2:47 PM, Berk Ozturk notifications@github.com wrote:

Hmm ok, then it doesn't seem like our current implementation is error-prone. Thanks @bqpd https://github.com/bqpd, must be something else.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hoburg/SPaircraft/issues/82#issuecomment-314861538, or mute the thread https://github.com/notifications/unsubscribe-auth/ABagGFNxIdX_j6u0LzFxA_IaDgraJyySks5sNRSrgaJpZM4NpNGU .

[bqpd]

Actually, just noticed that your current code doesn't seem to work on master...maybe there's a bug in nomialmaps and getting it to work on master will fix whatever issues you're seeing? (or maybe there's a bug in master, yikes)

[1ozturkbe]

Are you sure? The tests are passing?

[bqpd]

Maybe it's just standard_killer_plot_max_opt_eng() in kller_plots, then...

On Wed, Jul 12, 2017 at 3:26 PM, Berk Ozturk notifications@github.com wrote:

Are you sure? The tests are passing?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hoburg/SPaircraft/issues/82#issuecomment-314871705, or mute the thread https://github.com/notifications/unsubscribe-auth/ABagGNluwVtEr8FJKlZvCvVsgcBTXpfrks5sNR3TgaJpZM4NpNGU .

[mayork]

@1ozturkbe was this resolved??? we use this example in the paper for speed....this needs to work right before we can submit!

[1ozturkbe]

I think it is resolved if you use Wavgtotalpass as the payload weight substitution. I will have to check.

On Thu, Aug 31, 2017, 18:19 mayork notifications@github.com wrote:

@1ozturkbe https://github.com/1ozturkbe was this resolved??? we use this example in the paper for speed....this needs to work right before we can submit!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hoburg/SPaircraft/issues/82#issuecomment-326435808, or mute the thread https://github.com/notifications/unsubscribe-auth/AO9SX8mrRb5MxaGREx6JExakUlWwYtJ6ks5sdzGMgaJpZM4NpNGU .

[mayork]

@1ozturkbe not resolved I checked. Looking at this now...this should prob be top priority

[mayork]

@1ozturkbe I think something isn't vectorized that should be and it's forcing either the payload weight or something that depensd on payload weight to be equal everywhere

[1ozturkbe]

I know... I'm trying to figure it out as well.

[mayork]

@1ozturkbe pull. I think there was a bug in moment of inertia...didn't solve the issue but could have been part of it.

[1ozturkbe]

We are soooo stupid!!!! I know what's wrong.

[1ozturkbe]

All of the fractional weights need to be turned into inequalities! Like Wapu == Wpay*fapu... Goodness.

[1ozturkbe]

Fixing now.

[1ozturkbe]

Also, the moment of inertia stuff wasn't buggy I don't think. And now the code doesn't converge, returns UNKNOWN.

Update: nvm, I didn't check all weight fractions...

[1ozturkbe]

Hmm, have been relaxing equalities to inequalities for a while, still cannot get it to work. I will be travelling this weekend, but I will do my best to make progress on this.

[mayork]

@1ozturkbe I'm thinking this has to do with the mixing of Wpayload, which is vecotrized, into non-vectorized constraints. However, I haven't been able to isolate a singular bug either.

[mayork]

@1ozturkbe for the paper I'll run with a multimission over range. this won't be an issue.

UPDATE: @1ozturkbe range is working fine. This ins't a hold up for paper but I think still needs to be fixed. However, I think it might be a GPkit bug (see #102 )

[1ozturkbe]

@mayork I know for sure that this is because we have equality constraints that involve npass (or Wpass or Wpay) that are primal infeasible for vectorized npass. Working on fixing, but harder than anticipated.

[mayork]

Likely true but also note there appears to be a gpkit bug (https://github.com/hoburg/SPaircraft/issues/102) that will make it impossible to work...

Also can you do it on a branch?

[1ozturkbe]

That's what I was doing but I didon't commit anything. Will do when I get back.

[bqpd]

gpkit bug is not confirmed, see #102

[1ozturkbe]

Progress on this issue is happening on the branch multimissionFix.

[1ozturkbe]

so, I have gotten multimissionFix to solve sporadically with Wpay tight for different numbers of passengers. But it struggles with more than 2 mission segments. Will put the specific commits here.

[mayork]

yeah shoot i noticed the same thing. Ned wanted the mosek files to send to them. I can try and get that done soon.

[1ozturkbe]

@mayork I have resolved this issue in multimissionFix. Had to do with improper vectorization. Still having issues with more mission segments though... But tightness is good. Closing.