in flatten_constr, TypeError: 'bool' object is not iterable about gpkit HOT 9 CLOSED

Aw, shucks, I think I know what's happening here: for general compatibility, sometimes an equality constraint will return a True or a False instead of a Constraint Object. What's the code that's causing this failure? We'll turn it into a unit test.

from gpkit.

I'm running a slightly modified version of the simple_sweep.py example.

from gpkit.

In order of method-awesomeness, could you create a pull request with your failing file as a unit test, post your modifications, or email me the whole modified file?

from gpkit.

Going with the (hopefully?) somewhat-awesome option b. Four changes:

The constants are a little different:

constants = {
    'rho': (0.38, "kg m^3", "density of air"), ##Stanford standard atm tool
    'mu': (1.4e-5, "kg/m*s", "viscosity of air"), ##Engineering tooldbox/standard atm tool
    'S_wetratio_w': (2.06, "wetted area ratio"), ##Stanford wetted area calculation (assuming S_ref ~ S_exposed)
    'S_wet_f': (356, "m^2","fuselage wetted area ratio"), ##NASAPerfEval
    'k_w': (1.45, "wing form factor"), ## Martins Paper (Torenbeek)
    'k_f': (1.09, "fuselage form factor"), ## Martins Paper (Torenbeek)
    'e': (0.875, "Oswald efficiency factor"), #???
    'W_0': (701694, "N", "aircraft weight excluding wing"), ## NASAPerfEval
    'N_ult': (2.5, "ultimate load factor"), ## keep same (FAA metric)
    'tau': (0.149, "airfoil thickness to chord ratio"), ##NASAPerfEval
    'C_Lmax': (2.5, "max CL with flaps down"), #b737.org.uk (~average of takeoff and landing Clmax for 737-500) ????
    'V_min': (73, "m/s", "takeoff speed"), #jane's (also stall speed from answers.com)
}

The addition of V to free variables

free_variables = {
    'A': "aspect ratio",
    'S': ["m^2", "total wing area"],
    'C_D': "Drag coefficient of wing",
    'C_L': "Lift coefficent of wing",
    'C_f': "skin friction coefficient",
    'Re': "Reynold's number",
    'W': ["N", "total aircraft weight"],
    'W_w': ["N", "wing weight"],
    'V' : ["m/s", "cruising speed"]
}

Drag modelling is slightly different:

C_D_fuse = k_f*C_f*S_wet_f/S 

C_D_wpar = k_w*C_f*S_wetratio_w

Lines 62-64 are how they were previously (with equality constraints)

                    W == W_0 + W_w,
                    W_w == W_w_surf + W_w_strc,
                    C_D == C_D_fuse + C_D_wpar + C_D_ind

from gpkit.

(Option B was totes awesome. Option A might be a good future policy.)

Ah. Interesting. @whoburg and I were just discussing whether the interface should allow equality constraints between monomials and posynomials; a week ago this would have worked, but now it throws this mysterious error that really means "invalid constraint".

I'll add a better error message, but I'm also curious to know how you came to use == for these constraints.

For now, shift 'em back to >= constraints, which more accurately represents the solver's state; in the future we'll need to decide whether such Mono/Posy equality 'constraints' (which will require post-solve checking, and hence aren't quite 'constraints', though mathematically there should be no problem) are acceptable.

from gpkit.

I only used == because I was using the old simple_sweep.py as the template for the example I'm working on.

I'll change them to >=

from gpkit.

Heh, sorry about that fast switch. How useful / intuitive do you think W == W_0 + W_w and such would be?

from gpkit.

Well, although it might be bending some definitions, intuitively it would be nice to have the equalities in there. Especially for things that qualitatively can be considered more like definitions as opposed to constraints (like Weight = wing_weight + fuselage_weight +... and Total drag = parasite drag + induced drag etc.).

That's not really taking into account a potential (if I'm understanding things correctly?) loss of robustness/increase in complexity though ....

from gpkit.

Moving discussion to #64.

from gpkit.