IDAES / idaes-ext

IDAES developer repo for those building the idaes binary solvers and related tools.
Other
9 stars 11 forks source link

Add k_aug build #57

Closed eslickj closed 4 years ago

eslickj commented 4 years ago

This is an update to add the k_aug build to the IDAES solvers build. I put a simplified CMake file here that I just copy over the current k_aug Cmake file. It's not a general purpose file. It assumes you are following up on our specific Ipopt build. We'll probably want to find a more long-term solution by refining the build in setup in the k_aug repo.

I'll start building binaries now, and post them when this is approved. If any review wants to preview the binary tarball before approving, just let me know.

As usual, I still don't have the ability to do OSX builds.

eslickj commented 4 years ago

@jsiirola, thanks. Of course, now that I moved to do the real builds, Ipopt isn't building again. Every time I build these there is some new change. Hopefully I'll have the binaries in a few hours. I may need to make some tweaks in this PR to get things working right again.

eslickj commented 4 years ago

The mumps building issue appears to be this one https://bugs.gentoo.org/727356.

eslickj commented 4 years ago

@jsiirola, I seem to have a problem with the Pynumero CMake setup. It's set to compile the Pynumero HSL stuff if it finds the HSL libraries. I have the HSL libraries, but don't want to compile it. That's fine, I ignore the extra files. The problem is that there is a linking error, since we are missing "-lgfortran". This also wasn't a problem until now, because I didn't want the HSL stuff anyway. My issue now is that it is trying to link the HSL stuff before building the ASL stuff and failing and terminating before building the ASL stuff.

Is there are we can say DONT_BUILD_MA27_I_REALLY_MEAN_IT_I_DONT_CARE_IF_YOU_FOUND_HSL, or alternatively fixing the gfortran linking? I'm looking for something easy and fast where I don't have to edit the cmake file or wait for a Pyomo update.

EDIT: I don't see how the MA27 stuff could come before the ASL stuff. But there is no error related to the ASL build and I don't see how ASL_BUILD would be off. Not sure what's going on here.

jsiirola commented 4 years ago

You should be able to -DBUILD_MA27=no -DBUILD_MA57=no on the cmake / ccmake command line to disable ma27/ma57 entirely.

eslickj commented 4 years ago

@jsiirola Misread you answer. I'll give that a shot.

jsiirola commented 4 years ago

@eslickj I am not sure that my answer actually works. At least, I am still seeing that MA27 is being built even when I set it manually. Working the issue now.

jsiirola commented 4 years ago

Try the following patch, and then -DENABLE_HSL=no should prevent building ma27:

diff --git a/pyomo/contrib/pynumero/src/CMakeLists.txt b/pyomo/contrib/pynumero/src/CMakeLists.txt
index 001e131..b13bc6a 100644
--- a/pyomo/contrib/pynumero/src/CMakeLists.txt
+++ b/pyomo/contrib/pynumero/src/CMakeLists.txt
@@ -11,6 +11,7 @@ include(ExternalProject)
 OPTION(BUILD_ASL "Build the PyNumero ASL interface" ON)
 OPTION(BUILD_MA27 "Build the PyNumero ma27 interface" OFF)
 OPTION(BUILD_MA57 "Build the PyNumero ma57 interface" OFF)
+OPTION(ENABLE_HSL "Enable the HSL library interfaces" ON)

 # Dependencies that we manage / can install
 SET(AMPLMP_TAG "3.1.0" CACHE STRING
@@ -98,6 +99,12 @@ IF( MA27_LIBRARY OR MA27_OBJECT )
     set_property(CACHE BUILD_MA27 PROPERTY VALUE ON)
 ENDIF()

+#...but if the HSL interface is not enabled, do not build the MA* libraries
+IF( NOT ENABLE_HSL )
+    set_property(CACHE BUILD_MA27 PROPERTY VALUE OFF)
+    set_property(CACHE BUILD_MA57 PROPERTY VALUE OFF)
+ENDIF()
+
 # If BUILD_AMPLMP_IF_NEEDED is set and we couldn't find / weren't
 # pointed to an ASL build, then we will forcibly enable the AMPLMP build
 # to provide the ASL.
eslickj commented 4 years ago

@jsiirola Alright it seems to work. I'm adding the patching here to get it into the builds in docker containers. If it fixes things we can take it back out once the fix is in Pyomo.

jsiirola commented 4 years ago

The PR is in the Pyomo review queue (Pyomo/pyomo#1632). It should move through pretty quickly, likely merged by tonight.

eslickj commented 4 years ago

Okay, the windows build is working now. I have an odd issue with -ldl, but that should be easy to sort out.

jsiirola commented 4 years ago

The PR is in to Pyomo master.

eslickj commented 4 years ago

@jsiirola thanks, I'll pull the patch back out. I had to add a few hacky work-arounds, but everything is working again. Should have binaries soon. Just need to hash them, test them and decide on a new release number (I decided 2.2.0).