Changes made to enable MOSEK 9 support appear to break build in a linux container

[pgkirsch]

#1454 seems to break the build pipeline for a linux-base-image docker container we use. Building at commit 667264d works fine.

I know your build testing includes a linux machine so I'm surprised this is happening, but do you have any ideas why we might be seeing floating point exceptions? No issues building (locally) on OSX.

Found the following solvers: mosek, mosek_cli, cvxopt
#     Replacing directory env
..!!! uWSGI process 9 got Floating Point Exception !!!
*** backtrace of 9 ***
uwsgi(uwsgi_backtrace+0x35) [0x55c3f632d375]
uwsgi(uwsgi_fpe+0x23) [0x55c3f632d783]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060) [0x7fe583bff060]
/root/mosek/8/tools/platform/linux64x86/bin/libmosek64.so(+0x7c12b8) [0x7fe567fba2b8]
*** end of backtrace ***
entrypoint.sh: line 9:     8 Floating point exception(core dumped) python hops-worker.py
entrypoint.sh: line 9:     9 Floating point exception(core dumped) uwsgi --ini wsgi.ini

Let me know what other information would be useful to better understand the issue.

[bqpd]

do you know if you have MOSEK 9 installed in your container?

[bqpd]

Spitballing other failure modes:

• gpkit/env/settings file now has sorted entries and ends with a single newline, not double
• verification of dual solution is slightly modified to avoid nans
• slight changes to tests

None of these seem remotely like the kind of thing that would cause a build error. But I'm not sure what exactly might trigger a Floating Point Exception !!!

[pgkirsch]

do you know if you have MOSEK 9 installed in your container?

We explicitly install mosek 8.1.0.56

Of those, the second surely seems most likely right? I'm imagining some unit tests are run which invoke the changed dual solution checking code. What's confusing is how this gets so low-level that it is OS-dependent behaviour..

[bqpd]

oh, numerical issues always find a way to be OS specific. yeah, hmm. can you try the mosek9 commit with the previous commit's gp.py? (i can make a branch with that if you need to pull a specific branch)

[pgkirsch]

Yes, will try that, thanks. (appreciate the offer -- I can do it)

[pgkirsch]

Confirmed it works at commit 6eada8e (i.e. master with previous gp.py). Somehow the addition of else 0 seems to make something sad.

[bqpd]

weirdly the whole point of that was to *reduce* divides by zero. sigh. I think we may need it to pass tests with mosek 9, but will create PR without it to confirm.

…

On Thu, Feb 20, 2020 at 10:36 AM pgkirsch ***@***.***> wrote: Confirmed it works at commit 6eada8e <6eada8e> (i.e. master with previous gp.py). Somehow the addition of else 0 seems to make something sad. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1461?email_source=notifications&email_token=AALKAGGOHGTEA54VIRZ4J73RD3ECLA5CNFSM4KX6E5T2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMPRY5Y#issuecomment-589241463>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALKAGHTWQTHPIQNRRBIJM3RD3ECLANCNFSM4KX6E5TQ> .

[pgkirsch]

Wait sorry... I was tired and not thinking straight. It's the removal of the else 0 that's the problem.

[bqpd]

went back to the old one on #1463, see if that works in the container?

[pgkirsch]

Sigh the container (and the app) still runs python 2 😔

[bqpd]

😬

[pgkirsch]

FYI @bqpd the app has been converted to python 3 and currently works swimmingly at c7efc4f.

[bqpd]

fabulous

…

On Thu, Mar 12, 2020 at 4:53 PM pgkirsch ***@***.***> wrote: FYI @bqpd <https://github.com/bqpd> the app has been converted to python 3 and currently works swimmingly at c7efc4f <c7efc4f> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALKAGHBYLY4YOUZSTK5S7DRHFDR7ANCNFSM4KX6E5TQ> .