IndexError during SGP A-matrix modification

[1ozturkbe]

This is breaking SPaircraft atm. Why * before the args=None?

[1ozturkbe]

oy, everything is breaking now @bqpd, even localsolve.

C:\Users\Berk\Dropbox (MIT)\MIT Graduate School\Code\SPaircraft>python3 SPaircraft.py
Starting a sequence of GP solves
 for 317 free variables
  in 136 locally-GP constraints
  and for 1208 free variables
       in 4725 posynomial inequalities.

GP Solve 1
Using solver 'mosek_cli'
 for 1208 free variables
  in 4725 posynomial inequalities.
Solving took 0.641 seconds.
Solved cost was 3.774e+40.
Traceback (most recent call last):
  File "SPaircraft.py", line 97, in <module>
    sol = test()
  File "SPaircraft.py", line 89, in test
    sol = optimize_aircraft(m, substitutions, fixedBPR, pRatOpt, mutategparg)
  File "SPaircraft.py", line 65, in optimize_aircraft
    sol = m_relax.localsolve(verbosity=2, iteration_limit=200, reltol=0.01, mutategp=mutategparg)#, x0 = x0)
  File "c:\users\berk\dropbox (mit)\mit graduate school\code\gpkit\gpkit\constraints\prog_factories.py", line 126, in solvefn
    result = progsolve(solver, verbosity=verbosity, **solveargs)
  File "c:\users\berk\dropbox (mit)\mit graduate school\code\gpkit\gpkit\constraints\sgp.py", line 151, in localsolve
    gp = self.gp(x0, cleanx0=True)
  File "c:\users\berk\dropbox (mit)\mit graduate school\code\gpkit\gpkit\constraints\sgp.py", line 232, in gp
    row_idx = a_idxs.pop()  # modify a particular A entry
IndexError: pop from empty list

[bqpd]

it passes tests! :p

[bqpd]

oops no it doesn't. Forgot it got removed from tests in gpkitmodels

[1ozturkbe]

lol yes, good catch.

[bqpd]

New commit sets the A matrix directly; looks like there's a constraint which changes its number of variables/monomials during run. Will find out which...

[1ozturkbe]

tbh, that was my fault for not fixing SPaircraft sooner.

[1ozturkbe]

Interesting... I wonder which constraint it is...

[bqpd]

it's in gpkit.SignomialInequality((π + 2·Mission.Aircraft.Fuselage.\theta_{db} + 2·Mission.Aircraft.Fuselage.\theta_{db}·(1 - Mission.Aircraft.Fuselage.\theta_{db}²/2))·Mission.Aircraft.Fuselage.R_{fuse}² + 2·Mission.Aircraft.Fuselage.\Delta R_{fuse}·Mission.Aircraft.Fuselage.R_{fuse} <= Mission.Aircraft.Fuselage.A_{fuse} that the error occurs

[bqpd]

on the second local gp

[bqpd]

for the 1st GP it's

gpkit.PosynomialInequality(2·Mission.Aircraft.Fuselage.R_{fuse}·Mission.Aircraft.Fuselage.\Delta R_{fuse} + 3.14·Mission.Aircraft.Fuselage.R_{fuse}² + 4·Mission.Aircraft.Fuselage.R_{fuse}²·Mission.Aircraft.Fuselage.\theta_{db} <= 2·Mission.Aircraft.Fuselage.A_{fuse}^0.5·Mission.Aircraft.Fuselage.R_{fuse}·Mission.Aircraft.Fuselage.\theta_{db}^1.5 for the 2nd:

gpkit.PosynomialInequality(2·Mission.Aircraft.Fuselage.R_{fuse}·Mission.Aircraft.Fuselage.\Delta R_{fuse} + 3.14·Mission.Aircraft.Fuselage.R_{fuse}² + 4·Mission.Aircraft.Fuselage.R_{fuse}²·Mission.Aircraft.Fuselage.\theta_{db} <= 1.01·Mission.Aircraft.Fuselage.A_{fuse}^1·Mission.Aircraft.Fuselage.R_{fuse}^0.0016·Mission.Aircraft.Fuselage.\theta_{db}^0.0024)

[bqpd]

It appears the problem is that R_{fuse} has no exponent in the posylt1 of the first version, because it divides out between the first two sides (lt exp: 1, gt exp: 1), but it does not divide out in the second (lt exp: 1, gt exp: 0.0016)

[1ozturkbe]

Oy, seems like a small bug. Also, I wonder why this is not a valid thing to ask GPkit.

m_gpapprox = m.gp(None)

gives me an error. Is this expected behavior?

[bqpd]

uh, that should work. MWE?

[1ozturkbe]

Sure, I'll make a new issue.

[bqpd]

fixed! will put up PR soon. SPaircraft is soooo much faster and seems to solve with mosek_conif now

[1ozturkbe]

I fixed it on Monday :P