Fixing goal programming issues.

[1ozturkbe]

No description provided.

[1ozturkbe]

This is almost ready to merge, but unfortunately the diffs do not match in test_methods.
I saved solution files on my personal machine and uploaded to git, but these do not match the solutions in the remote machines as I would like. I cannot recreate and upload the solution files required to get test_methods to not fail. @bqpd how does one get around this?

[1ozturkbe]

@bqpd bump!

[bqpd]

You have to figure out a way to either make those tests cross-machine deterministic (what gpkit does with sorts in various places) or set a seed, set thresholds for closeness and have them occasionally fail when the random number generator implementation changes (what gpfit does).

[bqpd]

For this one, does just increasing reltol not work?

[1ozturkbe]

I think the issue is with the printouts, not with the actual solutions.

[bqpd]

According to the test results it was failing at an assertAlmostEqual...

[1ozturkbe]

It's sol.almost_equal that the test is failing. I am digging rn, since I would like to avoid doing machine specific things if possible.

[bqpd]

oh derp, egg on my face. try setting sens_abstol a bit higher too? (or maybe just to 10-ish to not test sensitivity closeness at all??)

Maybe the first thing to do is print out the sol.diff, so you can tell just what the differences are; if they make sense, set the tolerances accordingly, but if they don't then something else is up

[1ozturkbe]

I figured the tolerances were high enough, there shouldn't be a significant difference between machines. But I will keep turning the knobs until it freaking works.

[1ozturkbe]

(and start actually printing the solutions on the machines if it doesn't...)

[bqpd]

yeah I wonder if there's some configuration difference (different solver? different library version?) that's causing non-trivial changes to the result.

[bqpd]

OH it might also be a reltol problem, if there's variables that you or jenkins solve as "exactly zero"...

[bqpd]

but the diff will show all that, if you print it. Probably good for debugging purposes too.

[1ozturkbe]

Won’t the diff just print a bunch of unnecessary stuff? I know that for diffs that are zero it’s still has a print out, and that I don’t like.

On Mon, Nov 25, 2019 at 5:47 PM Ned Burnell ***@***.***> wrote: but the diff will show all that, if you print it. Probably good for debugging purposes too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=ADXVEX37RPR7MO7ZNN2JZMLQVRIW3A5CNFSM4JMJ3HWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFECCUA#issuecomment-558375248>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXVEX6NIDKLBBPY3PKR453QVRIW3ANCNFSM4JMJ3HWA> .

-- Berk Ozturk PhD Candidate, Aeronautics and Astronautics Massachusetts Institute of Technology bozturk@mit.edu

[bqpd]

that's true, and we can make a no-printing option! but for now it seems like the best way to debug this?

…

On Mon, Nov 25, 2019, 14:50 Berk Ozturk ***@***.***> wrote: Won’t the diff just print a bunch of unnecessary stuff? I know that for diffs that are zero it’s still has a print out, and that I don’t like. On Mon, Nov 25, 2019 at 5:47 PM Ned Burnell ***@***.***> wrote: > but the diff will show all that, if you print it. Probably good for > debugging purposes too. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #49?email_source=notifications&email_token=ADXVEX37RPR7MO7ZNN2JZMLQVRIW3A5CNFSM4JMJ3HWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFECCUA#issuecomment-558375248 >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ADXVEX6NIDKLBBPY3PKR453QVRIW3ANCNFSM4JMJ3HWA > > . > -- Berk Ozturk PhD Candidate, Aeronautics and Astronautics Massachusetts Institute of Technology ***@***.*** — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=AALKAGD2XW5LK2S544NSBKLQVRJB7A5CNFSM4JMJ3HWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFECJWA#issuecomment-558376152>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALKAGF2OKA3S546OWXZ4ZDQVRJB7ANCNFSM4JMJ3HWA> .

[1ozturkbe]

Alright, I've detected two issues through the diffs.
One, on the other machines the Boyd model is infeasible...
Two, the auto-generated variable names do not match between the two models.

[bqpd]

Huh, for Two I wonder if you should name those variables?

[bqpd]

Also possible to make the variable numbering resettable

[bqpd]

Having it be specific to a particular model environment might also work, but I'm leary of adding complexity to what is basically an old grandfathered hack (unnamed variables) anyway.

[1ozturkbe]

I decided that the issues with using diffs were too annoying, and decided to go with assertAlmostEqual over all original variables.

[1ozturkbe]

Yaaas, merging!!