PK Journal

[mayork]

@pgkirsch @1ozturkbe I'm starting my attempt at pulling apart the full model to an updated PK journal model. Will keep you posted on progress.

[pgkirsch]

Or, more, why is it necessary?

[mayork]

Try removing and see if it solves....artifact from D8 where it is required. I'll send you a write up on it in a few hours.

[mayork]

It was required to converge the full aircraft model

[pgkirsch]

Gotcha. Is there a reason both simple_ac_imports_no_engine.py and stand_alone_simple_profile.py both need to exist? There seems to be a lot of duplication between them.

[mayork]

They can be removed, no longer needed. They were used for full aircraft integration debugging

[pgkirsch]

Both SP_aircraft.py and spajoa.py (renamed pk_SP_aircraft.py) get pretty sad when I delete them and the classes being imported from both of them seem to be used in several places so I'm going to leave them alone for now.

[pgkirsch]

Any recollection why taper is fixed in the horizontal tail wingbox model but not fixed in the others?

[pgkirsch]

Was the varkey 'I_{capprint s} a typo in the wing.py version of WingBox?

@pgkirsch i would guess yes...prob just supposed to be I_{cap}

[pgkirsch]

N_{lift} seems to have been left out of the wing's wingbox model. Any recollection why, other than the fact it is nominally set to 1?

@pgkirsch look at aircraft.py line 149. The relevant constraint is now Ltow*self.wing['L_{max}'] >= self.wing['N_{lift}'] * W_total + self.HT['L_{h_{max}}'],....this does a few things not seen in the previous model namely account for HT down force and allow for the total lift generated by the wing to be reduced by the factor Ltow. This accounts for the fact some lift is generated by the fuselage.

[pgkirsch]

PK: @1ozturkbe I just realized that the wingbox fit you were talking about being erroneous (eqn 40 in the original paper) was taken straight from @whoburg's paper (eqn 65/fig 9 in the AIAA journal paper). It looks like a pretty good fit to me in that plot - are you sure it was doing the wrong thing?

MY: @pgkirsch going to answer with what i know since berk is still in Turkey...yes we are sure it was doing the wrong thing in certain conditions. the new fit was pretty rigorously verified. @1ozturkbe feel free to add to this

PK: Ok, fair enough. This seems fairly concerning though, because the conventional wisdom on GP fitting has been that if the surrogate fit is accurate (which we see from @whoburg's paper that it is) then it is appropriate to use it. I'm curious to hear in what sense it was doing the wrong thing. Was it because the constraint wasn't tight? If so, how does the new constraint address that?

BO: That is really odd, because I literally plotted the output from that fit and it didn't give the right physical result. The fit was saying that, as the wing tapers more, with a given wing area and loading, the structural mass increases, which is the inverse of what we would expect. So I went ahead and redid it, and confirmed that it does indeed give the right trend. If you have doubts, you are welcome to dig it up, and I would be happy to have someone double-check the results!

[pgkirsch]

Also, are you sure we need 8 decimal places on that fit? ;)

[pgkirsch]

Any recollection why Mr >= Lmax*AR*p/24 is commented out for the wing's wingbox?

@pgkirsch yes see line 248 of aircraft.py...we added a much more advanced constraint that has load relief due to the engine and fuel

# Wing root moment constraint, with wing and engine weight load relief
                    TCS([self.wing['M_r']*self.wing['c_{root}'] >= (self.wing['L_{max}'] - self.wing['N_{lift}']*(Wwing+f_wingfuel*W_ftotal)) * \
                        (1./6.*self.wing['A_{tri}']/self.wing['S']*self.wing['b'] + \
                                1./4.*self.wing['A_{rect}']/self.wing['S']*self.wing['b']) - \
                                        self.wing['N_{lift}']*Wengsys*self.VT['y_{eng}']]), #[SP]

[mayork]

@pgkirsch does this branch run for you right now? I pulled and ran spajoa.py and it is unknown

[pgkirsch]

Hmmm yeah, it runs for me

[mayork]

@pgkirsch can you push exactly what you are running right now?

[mayork]

@pgkirsch inline comments are found above to your questions.

[mayork]

@pgkirsch nevermind. I think i had somehow made a local change that messed it up. running for me now.

[pgkirsch]

Good to know, and thanks for the responses. One response to the fitting comment above.

[mayork]

@pgkirsch i emailed you regarding the relaxed constants method. Have you made the manuscript updates for the wing and VT?

If so that should just leave fuselage and HT since LG wasn't changed, correct?

[pgkirsch]

I have made many of the VT updates but not yet wing manuscript updates. I want to finish the wingbox stuff before I do that.

Btw @mayork many of the landing gear variables seem to be wrong (i.e. very small). Was it like this when you originally integrated them?

[mayork]

which variables?

[mayork]

oh yeah some of this looks messed up...i'll take a look at it right now and see what i can figure out

[mayork]

@pgkirsch i fixed the issue and now everything looks good. Note that I had to flip the inequaltiy in this constraint

TCS([aircraft['\\Delta x_m'] + cruise['x_{CG}'][0] <= aircraft['x_m']]),

which is on line 872 of aircraft.py

[mayork]

sorry for not catching that error, i previously only inspected what i thought were the ~4 key variables. I checked everything just now and didn't see anything anomalous.

[pgkirsch]

@mayork No worries, thanks for fixing it!

[1ozturkbe]

Hey guys, I will be back in the US tonight, so will be much better accessible. But it seems like we are doing ok so far. Philippe, I will be in touch about integrating the CG, moment of inertia, HT structure and fuselage bending bits in your paper.

[pgkirsch]

@mayork @1ozturkbe why is the shear web sizing constraint multiplied by 2 in the horizontal tail wingbox model? and why is the original version still in the model commented out? Also why do Lhtriout and Lhrectout (and their respective constraints) exist if they aren't used elsewhere?

[pgkirsch]

@mayork @1ozturkbe if possible please could you guys check to see that the wingbox refactor is working as intended?

Also, would you guys mind checking the system model result? I have been noticing a lot of variables with a final solution value of 1, and that's giving me some cause for concern....

[mayork]

@pgkirsch the 1s are expected. The relaxed_constants solution method introduces a variable for each constant that is 1 at the end

[pgkirsch]

Ah yeah, you did tell me that already. Another question: does it matter that cruise altitude is 1e-30 ft?

[mayork]

we have an option to specify some cruise parameters for matching the tasopt flight profile...the variable going to 1e-30 is a remnant of that (if you look at 'hft' its 35k, this is the relevant variable in our case)

[pgkirsch]

Also why are the number of vertical tails, number of aisles, and number of engines listed as free variables in the solution even though they are presumably fixed to their integer values?

BO: this is because some of the constraints are modified by these variables (such as fuselage width depending on numaisle etc.).

[pgkirsch]

@1ozturkbe I'm not sure I understand your answer. I can have a constraint that says wfuse >= numaisles*aislewidth + other nonsense and numaisles can be fixed to 1, and it works just fine.

BO: I didn't want to write separate constraints between aircraft that have different numbers of seats per row, engines, aisles and vertical tails. I think it is more intuitive if you just sub the number, and be done with it. Then you don't need to do any awkward constraint tweaking.

[pgkirsch]

Why is it necessary to have a Wing model that imports a WingNoStruct model and a WingBox model? Why can't you just combine Wing and WingNoStruct?

[mayork]

variable inheritance issues....it was necessary

[pgkirsch]

@mayork @1ozturkbe Can Atri and Arect be deleted from the wing model? They don't seem to appear anywhere else.

Also, why is the Afuel <= wwn*0.92*tau constraint commented out?

[pgkirsch]

Ignore my comment about Atri and Arect. grep didn't find Atri and Arect, but I didn't think to look for A_{tri} and A_{rect}.

[bqpd]

Sounds like it's hitting a Bounded bound!

On Tue, Jul 25, 2017 at 10:52 AM, pgkirsch notifications@github.com wrote:

Ah yeah, you did tell me that already. Another question: does it matter that cruise altitude is 1e-30 ft?

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

[mayork]

@pgkirsch how do we want to handle merging this branch to master? Should it live in a folder? this is just a long term planning question.

BO: (please not a folder)

[pgkirsch]

@mayork @1ozturkbe You guys will know better than me how horrific this will be, but I feel strongly that the ultimate goal should be to merge this in such a way that it is possible to run this single point design optimization, the full mission D8 design optimization problem, and everything in between, by using input arguments to the model. I think that some of the code cleanups I performed on this branch were badly needed and should be kept long term.

@pgkirsch I already accounted for the code clean ups in a different branch that will be merged to master before this. It's going to be extremely ugly to have model inputs set if you run without an engine and without a full flight profile.

[whoburg]

holy cow, this PR touches 3,325 files!? What is going on? Github won't even let me view the diff.

@whoburg a lot of stuff was renamed and rearranged (just like the other PR on this branch). The vast majority of the 3,325 files came from moving all of the wing and tail fitting files to a a different folder.

[whoburg]

I have a note to self to check on

aircraft.py line 149 -- shouldn't Nlift multiply self.HT["L_{h_{max}}"]?

(the line number may have changed by now, but point is that the loading factor should probably affect both the wing and htail, not just the wing.

@whoburg I remember having that discussion with Berk but don't remember the reason he said we shouldn't do it (I think TASOPT doesn't?). @1ozturkbe can you weigh in?

[whoburg]

@pgkirsch asked about fixed variable tables. Aren't we removing them since we aren't generating intermediate results anymore?

[pgkirsch]

@mayork @1ozturkbe Please can you guys reply in separate comments rather than editing the original question? It's hard to keep track of when questions have been addressed with the current approach, and also not clear who is responding, so it's unclear to whom any follow up should be addressed. For example, there are responses to @whoburg's questions above that he probably wouldn't be aware of unless he scrolled through the conversation to check.

[pgkirsch]

@whoburg I think it makes sense to keep fixed variable tables in each section, so they are more manageable. The difference from before is that these tables shouldn't include substitutions for variables that link with other models as they did before. Also, sorry, can you remind me when/where I commented about fixed variable tables? I don't remember saying anything so I think I'm losing my mind.

[pgkirsch]

@mayork As I think @whoburg alluded to in a previous phone call, there shouldn't exist multiple copies of the various models. It's bad practice and doubles the amount of work required to maintain code. We will need to find a way to gracefully merge things. I don't think the answer is to discard this simplified model either, because I think in the future it will be interesting to look at how the optimal design changes as you go from single-point-dumb-engine to single-point-with-engine to full-mission.

[1ozturkbe]

@whoburg for the constraint in aircraft.py, line 149, there does not need to be Nlift on tail downforce. We specify Lhmax to be the maximum tail load at Vne. Therefore the max load that the wing will experience is Nlift * MTOW + Lhmax. (In fact what we implement in the wingbox model is Nlift = 1 for tail surfaces for max load at Vne, and Nlift = 3 for the wing at MTOW).

[whoburg]

but shouldn't Lhmax scale with Nlift?

[mayork]

alright @1ozturkbe I've finally got a few hours so I want to start integrating this with master. Might need your support.

I'm going to start by add flags to remove the engine and integrate this engine model. And then I think we need to remove the flight profile and that'll be it right?

@pgkirsch

[mayork]

https://github.com/convexengineering/SPaircraft/pull/110