convexengineering / SPaircraft

Models for commercial aircraft design
http://spaircraft.readthedocs.org
25 stars 17 forks source link

Advanced Debug Method #31

Open mayork opened 7 years ago

mayork commented 7 years ago

I liked the idea of writing a debug method that branches down and runs the subsystems independently. I think a big decision is how to handle surrogate models. For example, we'll need a stand in tail model to run the fuselage in debug. One option is to simply pass in the answer from the final solve as fixed values. Thoughts?

bqpd commented 7 years ago

I think there's two aspects to a subsystem-debug:

1) does it solve to the right (primal) value given some fixed values? 2) does it have the right bounded / unbounded variables (dual infeasibility) without those fixed values?

The former will have to be updated more frequently than the latter, I think: you're more likely to change the way something is bounded than to suddenly stop bounding it.

Both of these could be implemented right now. I'd suggest that (1) should be in a test_primal method, while (2) should be in a test_dual method. These methods should use assert to declare their beliefs. Then, to start, you can run the following code to test all of them:

def test_constraintset(cns, methodname, verbosity=1):
    if hasattr(cns, methodname):
        try:
            getattr(cns, methodname)()
        except e:
            if verbosity > 1:
                print e
            if verbosity > 0:
                print "FAILED: %s.%s" % (cns, methodname)
            else:
                raise e

for cns in M.flat():
    test_constraintset(cns, "test_primal")
    test_constraintset(cns, "test_dual")

once we've got this being used in practice we can add it to the proper python unit-testing scaffolds.