Are you planning to add JSCIPOpt to a Maven Repository?

[hklarner]

What are the reasons for not adding JSCIPOpt to a Maven repository?

[mueldgog]

I don't know. What are the reasons to put it?

[hklarner]

The installation and setup of the suite, the libraries, the paths is not trivial: Exception in thread "main" java.lang.UnsatisfiedLinkError: no jscip in java.library.path.

[mueldgog]

How would this be fixed with a Maven repository? Sorry, I never heard about this before. hklarner <notifications@github.com> schrieb am Di., 8. Okt. 2019, 15:55:

…

The installation and setup of the suite, the libraries, the paths is not trivial: Exception in thread "main" java.lang.UnsatisfiedLinkError: no jscip in java.library.path. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIKCB4JFE4JDYUPV2HCQFTQNSGMNANCNFSM4I6RADOA> .

[hklarner]

How would this be fixed with a Maven repository?

I don't know. We just installed JSCIPOpt on Ubuntu and on Windows. Each took about two hours of interpreting instructions, trial and error, downloading third party software, trying compilers and so on.

[mueldgog]

Hmm, sorry to hear that. What steps were unclear or did not work? Do you have any suggestions for improving the documentation or the building process? Feel free to create a pull request if you have any specific ideas in mind.

Regarding your request on whether to add JSCIPOpt to a Maven Repository. We first need to understand how this works and how this would improve the current setup. Any help here would be definitely be appreciated.

[hklarner]

We first need to understand how this works and how this would improve the current setup

Yes. I can't contribute because I don't have enough experience. The setup of this library is probably just intrinsically difficult, since it wraps C++ Code that needs to be compiled locally. Thanks for your quick response!

[atraplet]

In order to be able to use JSCIPOpt in corporate environments, it would be very helpful to add it to Maven Central. The artifact on Maven Central should also include the native shared library from JSCIPOpt and all the native shared libraries distributed in the SCIP optimization suite. I could help with setting up Github actions that do the work. However, before I contribute I would like to get a feedback if this is something that you would consider. E.g. you would need to register a domain as described here https://central.sonatype.org/register/namespace/ . It could be e.g. io.github.scipopt or org.scipopt.

[kkofler]

So this is the current maintainer of JSCIPOpt talking. I cannot speak for ZIB (SCIP upstream) though because I am not an employee of that institution, I only "volunteered" (actually, I am doing it on work time because we use it at work) to maintain the Java bindings (JSCIPOpt).

What we do at my employer (DAGOPT Optimization Technologies GmbH) is that we host our own internal private Maven repository for all the solvers that we use for various projects (e.g., also Ipopt, NLopt, etc.). We (i.e., usually me) build our own JNI binaries that we control, using our own build scripts. GNU/Linux binaries are built in an old CentOS chroot to make them as portable as possible. Windows binaries are usually built with cross-MinGW (though for JSCIPOpt in particular, the binary was crashing last I checked – might be because my cross-MinGW is outdated and buggy –, and, on Windows, we currently use a JSCIPOpt built with Visual C++ using the prebuilt Visual C++ build of SCIP). We do not support macOS. The build scripts also build all the dependencies as static libraries (but with -fPIC) and link everything statically, in order to get one standalone JNI .so/.dll file. (See also the next paragraph.) Doing our own builds also allows us to apply downstream patches where needed. So, to be honest, my personal interest in shipping official binaries to a public Maven repository is limited, but I am not opposed to it.

About the dependencies: My build script for JSCIPOpt builds TBB, OpenBLAS, GKlib, METIS, SPRAL, Ipopt, scipoptsuite (SoPlex, ZIMPL, PaPILO, SCIP), and JSCIPOpt. The cross-MinGW one also GMP, whereas the native GNU/Linux one links to system GMP .so files because it is widely available and the soname has been stable for a while. Both OpenBLAS and SPRAL are built in single-threaded (but thread-safe) mode. We switched from MUMPS to SPRAL as the linear solver for Ipopt because MUMPS is not thread-safe and requires a global mutex in Ipopt. SCIP is built with threading support (solveConcurrent) enabled.

I can share the build scripts that I use for JSCIPOpt if it helps you, but as I said, the cross-MinGW one does not seem to be working yet (at least for me).

[atraplet]

My idea was to use the binaries from the SCIP optimization suite similar to PySCIPOpt, e.g. here https://github.com/scipopt/PySCIPOpt/blob/master/.github/workflows/update-packages-and-documentation.yml#L41 and only build the JSCIPOpt binary from source. Do you know if these binaries include Ipopt/MUMPS or Ipopt/SPRAL?

[kkofler]

Ipopt/MUMPS, I believe.

Be warned though that those binaries, at least the GNU/Linux ones, are built for some higher minimum CPU than mine. At least last I checked, they were. (It has been a long time since I last tried them.) So they would just crash with a SIGILL Illegal Instruction on my computer. I carefully build my binaries to run on any x86_64 CPU (even if it is even older than mine). So I cannot assume anything higher than SSE2, though some packages like OpenBLAS are able to runtime-detect vector instruction sets if configured correctly.

CPU support was the first reason I started building custom SCIP binaries for my employer (DAGOPT), then OS support (old GNU/Linux distributions with ancient glibc/libstdc++, achieved by compiling in the oldest possible CentOS chroot), then the possibility to ship one statically-linked shared library that does not depend on other non-system shared libraries, then occasional local patches (though we try to upstream everything), and only recently building Ipopt with SPRAL.