Maxflow example problem in C++ fails

[troyrock]

What version of OR-Tools and what language are you using?
Version: stable/v9.11
Language: C++

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)
I have Gurobi installed however I'm not sure which is being used and I'm not sure how to check.

What operating system (Linux, Windows, ...) and version?
NAME="Red Hat Enterprise Linux"
VERSION="8.8 (Ootpa)"

What did you do?
I'm new and trying to get the C++ example on: https://developers.google.com/optimization/flow/maxflow to run on my machine. I saved the code from that page to the file test-max-flow.cpp. Following the directions at: https://github.com/google/or-tools/blob/stable/cmake/README.md#consuming-or-tools-in-a-cmake-project I created my cmake file:

cmake_minimum_required(VERSION 3.14)
project(test-maximum-flow VERSION 1.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ggdb")

# Build OR-tools dependencies.
set(BUILD_DEPS ON)

find_package(ortools CONFIG REQUIRED)

add_executable(test-maximum-flow.exe test-maximum-flow.cpp)
target_link_libraries(test-maximum-flow.exe ortools::ortools)

I have a build directory where I execute the following:
$ cmake ../source/
-- The CXX compiler identification is GNU 11.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /apps/spack/linux-rhel8-zen/gcc-8.5.0/gcc-11.2.0-xiaeky3yguq32ddvvibp2o5n4gexejc2/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found re2: /somedirectory/lib64/cmake/re2/re2Config.cmake (found version "11.0.0")
-- Found Clp: /somedirectory/lib64/cmake/Clp/ClpConfig.cmake (found version "1.17.7")
-- Found Cbc: /somedirectory/lib64/cmake/Cbc/CbcConfig.cmake (found version "2.10.7")
-- Found Eigen3: /usr/share/eigen3/Eigen3Config.cmake (found version "3.3.4")
-- Found SCIP: /somedirectory/lib64/cmake/scip/scip-config.cmake (found version "9.0.0")
-- Configuring done
-- Generating done
-- Build files have been written to: /somedirectory/test-max-flow/build

Then I build the source:
$ cmake --build .
[ 50%] Building CXX object /somedirectory/test-max-flow/build/CMakeFiles/test-maximum-flow.exe.dir/test-maximum-flow.cpp.o
[100%] Linking CXX executable /somedirectory/test-max-flow/build/test-maximum-flow.exe
[100%] Built target test-maximum-flow.exe

When I execute, I get the following:
$ ./test-maximum-flow.exe
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1736624976.345230 1646102 test-maximum-flow.cpp:37] Solving the max flow problem failed. Solver status: 0

I'm sure that I'm doing something simple incorrectly. Any suggestions? Thank you.

What did you expect to see
I was hoping that the example problem would be solved.

What did you see instead?
When I execute, I get the following:
$ ./test-maximum-flow.exe
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1736624976.345230 1646102 test-maximum-flow.cpp:37] Solving the max flow problem failed. Solver status: 0

Make sure you include information that can help us debug (full error message, model Proto).
Let me know if there is anything else that I can provide to help resolve this problem.

Anything else we should know about your project / environment
I have an academic license of Gurobi installed but I'm not sure the build process found it and I'm not sure how to check. This is the first thing that I've tried since I installed. I also posted this same thing to the OR-Tools discussion group on January 11 but haven't received any responses.

[lperron]

Max flow does not use a MIP solver.

[troyrock]

ok, I'm unsure who I should talk to in order to get this example to work. Is this the wrong place?

[sschnug]

Your build looks fine (although /apps/spack/linux-rhel8-zen/gcc-8.5.0/gcc-11.2.0-xiaeky3yguq32ddvvibp2o5n4gexejc2/bin/g++ looks funny).

I observe the same issue with a bazel-based ubuntu-targeting build:

user@pc:~/Tmp/or-tools$ git status
HEAD detached at v9.11

user@pc:~/Tmp/or-tools$ bazelisk run //ortools/graph/samples:simple_max_flow_program_cc
INFO: Analyzed target //ortools/graph/samples:simple_max_flow_program_cc (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //ortools/graph/samples:simple_max_flow_program_cc up-to-date:
  bazel-bin/ortools/graph/samples/simple_max_flow_program_cc
INFO: Elapsed time: 2.003s, Critical Path: 1.84s
INFO: 3 processes: 1 internal, 2 linux-sandbox.
INFO: Build completed successfully, 3 total actions
INFO: Running command line: bazel-bin/ortools/graph/samples/simple_max_flow_program_cc
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
I0000 00:00:1738015479.280739  145752 simple_max_flow_program.cc:66] Solving the max flow problem failed. Solver status: 0

The solver actually solves fine. status 0 is often the OK status and it's also the case here as seen in the enum design.

But there seems to be an issue with the status enums vs. inheritance/templated stuff happening... such that we ask about status OPTIMAL and get the anwer "no" despite it being OPTIMAL (but an incompatible enum).

@lperron This somewhat looks like a bug?

@troyrock For what it's worth: you can fix !this example! with this change:

if (status == MaxFlow::OPTIMAL)
->
if (status == SimpleMaxFlow::OPTIMAL)

which also matches the earlier constructor. Yes... the code is probably designed such that one should NOT need to pick the enum within the more specialized type, but hey...

user@pc:~/Tmp/or-tools$ bazelisk run //ortools/graph/samples:simple_max_flow_program_cc
I0000 00:00:1738015665.140935  148174 simple_max_flow_program.cc:55] Max flow: 60
I0000 00:00:1738015665.141028  148174 simple_max_flow_program.cc:56]
I0000 00:00:1738015665.141037  148174 simple_max_flow_program.cc:57]   Arc    Flow / Capacity
I0000 00:00:1738015665.141043  148174 simple_max_flow_program.cc:59] 0 -> 1  20  / 20
I0000 00:00:1738015665.141053  148174 simple_max_flow_program.cc:59] 0 -> 2  30  / 30
I0000 00:00:1738015665.141061  148174 simple_max_flow_program.cc:59] 0 -> 3  10  / 10
I0000 00:00:1738015665.141070  148174 simple_max_flow_program.cc:59] 1 -> 2  0  / 40
I0000 00:00:1738015665.141078  148174 simple_max_flow_program.cc:59] 1 -> 4  20  / 30
I0000 00:00:1738015665.141087  148174 simple_max_flow_program.cc:59] 2 -> 3  10  / 10
I0000 00:00:1738015665.141095  148174 simple_max_flow_program.cc:59] 2 -> 4  20  / 20
I0000 00:00:1738015665.141104  148174 simple_max_flow_program.cc:59] 3 -> 2  0  / 5
I0000 00:00:1738015665.141112  148174 simple_max_flow_program.cc:59] 3 -> 4  20  / 20

[troyrock]

Great! Making this change does indeed fix the problem. Thanks for the tip. Too bad it doesn't work "out of the box." In terms of the location of g++, this is actually running on a cluster and I am loading a module in order to use the latest version of gcc instead of the outdated one that comes with the cluster install.

[lperron]

We rewrote all the flow/graph code for 9.12. And indeed we changed the class of the enum in that example. So, this is a bug, and it is fixed on main. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le mar. 28 janv. 2025 à 00:08, Troy Rockwood ***@***.***> a écrit :

…

Great! Making this change does indeed fix the problem. Thanks for the tip. Too bad it doesn't work "out of the box." — Reply to this email directly, view it on GitHub <#4524 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3OSW7FMODCWMZ3NQXD2M237PAVCNFSM6AAAAABV7DGCVKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJXG4ZDQNI> . You are receiving this because you were mentioned.Message ID: ***@***.***>