Open mayork opened 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.
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?