Linking HT with Fuse, VT, Wing

[1ozturkbe]

Still getting unknown within CFP_Fuselage_Performance_int.py in latest commit 89a465.

Added potential HT substitutions to get the model to solve. Hard to debug because even when bounded, it doesn't converge. There might still be inconsistencies in the constraint set.

@mayork I think it is best if we proceed with a baby HT model, and work our way back up. Latest working commit with CFP_Fuselage_Performance_int.py is commit 9e5793ed57224af19cf6c42098239be0911b7186 (has Fuse, VT, Wing). Perhaps we can start that tomorrow morning.

Berk out, need some sleep...

[1ozturkbe]

Crud, it also seems like master is throwing errors with duplicate variable names; last time I had run 9e5793ed57224af19cf6c42098239be0911b7186 version was with hoburg/gpkit@feasvectorized. Might have to look into that as well.

[bqpd]

@1ozturkbe, try with gpkit/backwards_init_compat, which should be merged to master soon...

[bqpd]

It is now merged! Hopefully that will resolve this.

[bqpd]

It didn't, but I'm getting that same error on vectorizedfeas...

[mayork]

I'm working on getting the simple model together (for some reason it's only solving bounded right now).

I really think the right way to go about this is to integrate just your fuselage with the flight profile and the HT first. I already got the HT, VT, and wing integrated and you got fuse/wing/VT integrated so the problem is almost certainly something in the fuselage and HT linking, whether it be CG or something else. I think once we can integrate a fuselage and HT adding the other things will be relatively straight forward.

[1ozturkbe]

arrggh it seems like a step backward, but perhaps it is the right way to go. I am really surprised that straight-up substituting for all of the HT variables is not working. Have you tried that @mayork ?

[mayork]

tried substituting the HT variables? no. but the only way I got the wing HT integration was to link the HT and wing independently which showed some bugs.

[whoburg]

agreed on using simple models first to make sure we understand the pressures.

[1ozturkbe]

Figured out the issue (or at least one issue)!! @mayork @bjarni177 Look at commit 66e5b0e5, CFP_Fuselage_Performance_int_HT.py (sorry about the verbosity of the files :P)

I was incrementally integrating basic_HT into that file, when I found the constraint that is giving trouble.

SignomialEquality(xAC/aircraft.wing['mac'],
                              self.wingP['c_{m_{w}}']/self.wingP['C_{L}'] + xCG/aircraft.wing['mac'] + \
                              aircraft.HT['V_{h}']*(self.HTP['C_{L_{h}}']/self.wingP['C_{L}'])),

I am still trying to understand why this constraint is problematic, but I think it has to do with the degrees of freedom in satisfying this equation (due to bad substitutions and ill formulated xCG and xAC constraints) Will try to fix by relaxing these.

[mayork]

so why don't integrate the basic file minus the trim constrain with the other subsytems? I'm upgrading the basic HT file to use vectorize and will try and investigate what's actually going on with this constraint. I'll also come up with a more detailed HT model that doesn't include trim, it just sizes the HT. We can integrate that into the full system after integrating the basic model

does that seem like a reasonable plan of attack @1ozturkbe ?

[1ozturkbe]

It is a good plan of attack. But I personally feel it might be best to run the sweeps with the full d8 code (CFP_int_HT), because the errors result due to some complex interaction between the wing, fuselage, and HT that we haven't seen clearly yet. It will be more insightful from an aircraft system design perspective to do it this way. I would alternatively suggest trying to debug the error with the basic_HT first with some sweeps, and then going forward with doing incremental integration within CFP, starting with the troublesome constraint. And plus, I have already written most of basic_HT in a performance format in CFP. :P

[mayork]

okay sure so just drop the trim constraint from the more complex model and see if it solves. if it does i 100% agree with you

[1ozturkbe]

Btw, for that constraint, if we relaxed it, should it be LHS >= RHS? Just want to check.

[mayork]

it's not immediately obvious. it won't tighten either way if HT down force isn't in the lift summation.

[mayork]

since its not immediately obvious I advocate just dropping the constraint now since its useless. this woulda also the dropping of all the constraints that set the HT lift. I think the first pass solution is to size the HT properly and just know we're being optimistic by neglecting HT downforce. I don't think its going to radically change our answer.

[1ozturkbe]

Pushed latest version with both SM and xAC constraints. It is barely feasible, but works!

[mayork]

@1ozturkbe is the file CFP_Fuselage_Performance_int_HT.py? I was getting an error when I ran that. If that is the file, are you sure you pushed the latest code?

[1ozturkbe]

Really? wth? I definitely had pushed working code. I checked it this morning (I have been working on some sweeps in the meanwhile). I guess I'll push the code with sweeps prematurely, because I know it solves. @mayork Just pushed; try again!

[1ozturkbe]

Also, there is a really interesting error with the SignomialEquality involving static margin. The code has trouble solving when you have the substitution SM = value, but if you put in the constraint SM >= value instead, it works fine, and the constraint is tight! Some odd dynamics going on, I suggest you try it!

[1ozturkbe]

Also, currently, the constraint:

 SignomialEquality(SM + dxcg/aircraft.wing['mac'],
                              aircraft.HT['V_{h}']*aircraft.HT['m_{ratio}'] \
                    + self.wingP['c_{m_{w}}']/aircraft.wing['C_{L_{wmax}}'] + \
                              aircraft.HT['V_{h}']*aircraft.HT['C_{L_{h_{max}}}']/aircraft.wing['C_{L_{wmax}}']),

is vectorized constraint. A large majority of these are non-vectorized variables (including SM, which is really SMmin). If we don't plan on giving dxcg a vector value in the future, we should change this constraint in HT_simple_profile and CFP to be a single SigEq constraint from a set of SigEqs. Would you agree?

[mayork]

I eventually want to compute the dxcg value but it won't be a vector. The reason I put had it vectorized was due to the wing moment coefficient....but now that I think about it what we actually want there is a max/min wing moment coefficient (I'll need to think about which one it really is). So yes, I think we should move the constraint out of the vectorized environment.

[mayork]

@1ozturkbe here's the print out when i try to run the linked file. do you have local unpushed changes in D8 integration maybe? I was under the impression we also had removed all ini so I'm slightly confused.

Declaring a named Model's variables in __init__ is not recommended. For details see gpkit.rtfd.org
Declaring a named Model's variables in __init__ is not recommended. For details see gpkit.rtfd.org
Declaring a named Model's variables in __init__ is not recommended. For details see gpkit.rtfd.org
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
/Users/mayork/Documents/GpGit/d8/CFP_Fuselage_Performance_int_HT.py in <module>()
   1044     }
   1045 
-> 1046     m = Mission()
   1047     m.substitutions.update(substitutions)
   1048     m.substitutions.update({'SM_{min}' : 0.05})

/Users/mayork/Documents/GpGit/gpkit/gpkit/constraints/model.pyc in __init__(self, cost, constraints, *args, **kwargs)
     57                 start_args = [cost, constraints]
     58                 args = tuple(a for a in start_args if a is not None) + args
---> 59                 constraints = self.setup(*args, **kwargs)  # pylint: disable=no-member
     60                 from .. import NAMEDVARS, MODELS, MODELNUMS
     61                 setup_vars = NAMEDVARS[tuple(MODELS), tuple(MODELNUMS)]

/Users/mayork/Documents/GpGit/d8/CFP_Fuselage_Performance_int_HT.py in setup(self, **kwargs)
    874             # weight constraints
    875             TCS([aircraft['W_{fuse}'] + aircraft['W_{payload}'] + W_ftotal + aircraft['numeng']
--> 876                  * aircraft['W_{engine}'] + aircraft.wing.wb['W_{struct}'] + aircraft.VT.wb['W_{struct}'] + aircraft.HT['W_{htail}'] <= W_total]),
    877 
    878             cls.climbP.aircraftP['W_{start}'][0] == W_total,

/Users/mayork/Documents/GpGit/gpkit/gpkit/constraints/set.pyc in __getitem__(self, key)
     75             raise ValueError("multiple variables are called '%s'; use"
     76                              " variables_byname('%s') to see all of them"
---> 77                              % (key, key))
     78 
     79     def variables_byname(self, key):

ValueError: multiple variables are called 'W_{engine}'; use variables_byname('W_{engine}') to see all of them

[1ozturkbe]

As we discussed, you should let me know if the above doesn't work with the latest version of gpkit master.

[1ozturkbe]

As of commit a34976b, much of these issues have been fixed. Closing for now.