Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execution error #530

Closed
bkaangorur opened this issue Oct 29, 2021 · 5 comments
Closed

Execution error #530

bkaangorur opened this issue Oct 29, 2021 · 5 comments

Comments

@bkaangorur
Copy link

bkaangorur commented Oct 29, 2021

Hello all,

I tried to install IPOPT in Windows under Msys2. Although everything was compiled without any problems, I am getting following error during the execution.

$ ./tutorial.exe
******************************************************************************
This program contains Ipopt, a library for large-scale nonlinear optimization.
 Ipopt is released as open source code under the Eclipse Public License (EPL).
		 For more information visit https://github.com/coin-or/Ipopt
******************************************************************************

This is Ipopt version 3.14.5, running with linear solver spral.

Number of nonzeros in equality constraint Jacobian...:      294
Number of nonzeros in inequality constraint Jacobian.:        0
Number of nonzeros in Lagrangian Hessian.............:      198

terminate called after throwing an instance of 'std::bad_alloc'
terminate called recusively

The code that I compiled is the tutorial code and Cpp_example in IPOPT source code. I also tried to debug Cpp_example and show that the error pops up in this line

  status=app->OptimizeTNLP(mynlp);

And, here is how I compiled sample codes (for example tutorial):

g++ -o tutorial.exe -std=c++0x TutorialCpp_main.cpp TutorialCpp_nlp.cpp -I/D/workspace/extern/ipopt/include -I/D/workspace/extern/ipopt/include/coin-or -I/D/workspace/extern/ipopt/include/coin-or/metis -L/D/workspace/extern/ipopt/lib -lcoinmetis -lhwloc -lsipopt -lipopt -lspral -lblas_win64_MT -llapack_win64_MT

I installed IPOPT with SPRAL. So, I also built dependencies of SPRAL, which are hwloc and metis. And here is how I installed everything:

  1. I downloaded hwloc-2.5.0 from Open-Mpi web site and installed it by usual process:
./configure --prefix=/D:/workspace/extern/ipopt
make
make install
  1. I downloaded ThirdParty-Metis-stable-2.0 from coin-or repositories. Then I downloaded metis code by running ./get.Metis. It downloaded metis-4.0. After that I installed it by following:
./configure --prefix=/D:/workspace/extern/ipopt
make
make install
  1. I downloaded SPRAL from ralna/spral repository. Since I could not run autogen.sh in Windows, I ran it in an Ubuntu OS as in this SPRAL issue. Then I moved generated files to Windows.

    During the SPRAL's compilation, it could not find gfortran. Therefore, I ran

     export PATH=/mingw64/bin:$PATH
    

    After that I ran these commands as in SPRAL's readme:

     CFLAGS=-fPIC CPPFLAGS=-fPIC CXXFLAGS=-fPIC FFLAGS=-fPIC FCFLAGS=-fPIC NVCCFLAGS="-shared -Xcompiler -fPIC" ../configure --prefix=/D/workspace/extern/ipopt --with-blas="-L/D/workspace/extern/ipopt/lib -lblas_win64_MT" --with-lapack="-L/D/workspace/extern/ipopt/lib -llapack_win64_MT" --with-metis="-L/D/workspace/extern/ipopt/lib -lcoinmetis" --with-metis-inc-dir="-I/D/workspace/extern/ipopt/include/coin-or/metis"
     make
     make install
    
  2. I downloaded IPOPT (stable-3.14). During the IPOPT's compilation, it could not find gfortran. Therefore, I ran:

     export PATH=/mingw64/bin:$PATH
    

    I ran also these commands as in SPRAL's readme:

     export OMP_CANCELLATION=TRUE
     export OMP_NESTED=TRUE
     export OMP_PROC_BIND=TRUE
    

    During the configuration (or maybe during make, I am not sure), it could not find icui18n and icudata libraries. Therefore, I copied libicui18n.dll.a and libicudata.dll.a from D:\Msys2\usr\lib into a path that compiler can see.

    After that I ran:

     	../configure --prefix=/D:/workspace/extern/ipopt --with-spral-lflags="-L/D:/workspace/extern/ipopt/lib -L/D:/workspace/extern/ipopt/lib -lspral -lgfortran -lhwloc -lm -lcoinmetis -lblas_win64_MT -llapack_win64_MT -lstdc++ -licui18n -licudata -fopenmp" --with-spral-cflags="-I/D:/workspace/extern/ipopt/include" --with-lapack-lflags="-L/D:/workspace/extern/ipopt/lib -llapack_win64_MT -lblas_win64_MT -fopenmp" --without-hsl --without-asl --without-mumps
     make
     make test
     make install
    

    During these steps, make test command failed for all cases. However, when I run make install, I can see that library files have been built and located in the right place.

After all, now I have these libraries in my installation path, which is D:/workspace/extern/ipopt/lib

  • libcoinmetis.dll.a
  • libcoinmetis.la,
  • libhwloc.a
  • libhwloc.la
  • libicudata.dll.a
  • libicui18n.dll.a
  • libipopt.dll.a
  • libipopt.la
  • libsipopt.dll.a
  • libsipopt.la
  • libspral.a

And I have these .dll files (in addition to some .exe files) in my bin directory, which is D:/workspace/extern/ipopt/bin

  • libcoinmetis-2.dll
  • libipopt-3.dll
  • libsipopt-3.dll
@svigerske
Copy link
Member

I haven't run Ipopt with Spral on Windows so far.
As you have encountered, their setup doesn't work out-of-the-box under msys2/mingw, so I'm waiting for that to be fixed up.

I would suggest you first try with MUMPS, HSL, Pardiso, or Intel MKL to check whether that works. If it does, then the problem is with Spral or the Spral interface.

Or you run a debugger and check where this bad_alloc exception is thrown.

@bkaangorur
Copy link
Author

Thank you @svigerske, I will try to compile one of them.

@svigerske
Copy link
Member

I finally got around to try to reproduce this.

With increased spral_print_level, I get

This is Ipopt version 3.14.3, running with linear solver spral.

Number of nonzeros in equality constraint Jacobian...:        4
Number of nonzeros in inequality constraint Jacobian.:        4
Number of nonzeros in Lagrangian Hessian.............:       10


 On entry to ssids_analyse                                     :
 options%print_level       =                5
 options%unit_diagnostics  =                6
 options%unit_error        =                6
 options%unit_warning      =                6
 options%nemin             =               32
 options%ordering          =                2
 n                         =                7
 Input topology
 Region            1  with            1  cores
 [find_subtree_partition] load_balance =    1.00000000    


 Entering ssids_factor                                       with posdef = .false. and :
 options parameters (options%) :
 print_level         Level of diagnostic printing           =            5
 unit_diagnostics    Unit for diagnostics                   =            6
 unit_error          Unit for errors                        =            6
 unit_warning        Unit for warnings                      =            6
 scaling             Scaling control                        =      4000000
 small               Small pivot size                       =   1.0000E-20
 u                   Initial relative pivot tolerance       =   1.0000E-02
 multiplier          Multiplier for increasing array sizes  =   1.1000E+00


 Warning from ssids_factor. Warning flag =   8
Matching-based ordering used but associated scaling ignored                                                                                                                                             
terminate called after throwing an instance of 'std::runtime_error'
  what():  outstanding allocations on cleanup

The exception seems to come from within Spral:
https://github.com/ralna/spral/blob/6c5692454b1bb42328dd5203c9cb042bc759468b/src/ssids/cpu/BuddyAllocator.hxx#L103-L105

Thread 1 hit Catchpoint 1 (exception thrown), 0x000000000062bb38 in __cxa_throw ()
(gdb) bt
#0  0x000000000062bb38 in __cxa_throw ()
#1  0x000000000066eb74 in spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> >::~Page (this=<optimized out>, __in_chrg=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/ext/new_allocator.h:89
#2  std::_Destroy<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> > > (__pointer=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/stl_construct.h:98
#3  std::_Destroy_aux<false>::__destroy<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> >*> (__last=<optimized out>, 
    __first=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/stl_construct.h:108
#4  std::_Destroy<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> >*> (__last=<optimized out>, __first=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/stl_construct.h:137
#5  std::_Destroy<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> >*, spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> > > (__last=0x16414d0, __first=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/stl_construct.h:206
#6  std::vector<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> >, std::allocator<spral::ssids::cpu::buddy_alloc_internal::Page<std::allocator<char> > > >::~vector (this=0x1621090, __in_chrg=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/stl_vector.h:677
#7  spral::ssids::cpu::buddy_alloc_internal::Table<std::allocator<char> >::~Table (this=0x1621080, __in_chrg=<optimized out>)
    at ../src/ssids/cpu/BuddyAllocator.hxx:286
#8  std::_Sp_counted_ptr<spral::ssids::cpu::buddy_alloc_internal::Table<std::allocator<char> >*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (
    this=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr_base.h:377
#9  0x00000000005c78a2 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x16411f0)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr_base.h:148
#10 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (
    this=0x16411f0)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr_base.h:148
#11 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (
    this=0x1620f40, __in_chrg=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr_base.h:730
#12 std::__shared_ptr<spral::ssids::cpu::buddy_alloc_internal::Table<std::allocator<char> >, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x1620f38, 
    __in_chrg=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr_base.h:1169
#13 std::shared_ptr<spral::ssids::cpu::buddy_alloc_internal::Table<std::allocator<char> > >::~shared_ptr (this=0x1620f38, __in_chrg=<optimized out>)
    at c:/program files/gnu octave/octave-6.2.0/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include/c++/bits/shared_ptr.h:103
#14 spral::ssids::cpu::BuddyAllocator<double, std::allocator<double> >::~BuddyAllocator (this=0x1620f38, __in_chrg=<optimized out>)
    at ../src/ssids/cpu/BuddyAllocator.hxx:382
#15 spral::ssids::cpu::NumericSubtree<false, double, 8388608ull, spral::ssids::cpu::AppendAlloc<double> >::~NumericSubtree (this=<optimized out>, 
    __in_chrg=<optimized out>) at ../src/ssids/cpu/NumericSubtree.hxx:278
#16 spral_ssids_cpu_destroy_num_subtree_dbl (posdef=<optimized out>, 
    target=0x1620f20) at ../src/ssids/cpu/NumericSubtree.cxx:70
#17 0x00000000005c2e6c in spral_ssids_cpu_subtree::factor (this=..., 
    posdef=.FALSE., aval=..., child_contrib=..., options=..., inform=..., 
    scaling=...) at ../src/ssids/cpu/subtree.f90:273
#18 0x00000000005c0a63 in spral_ssids_fkeep::inner_factor_cpu (fkeep=..., 
    akeep=..., val=..., options=..., inform=...) at ../src/ssids/fkeep.F90:156
#19 0x000000000059ddab in spral_ssids::ssids_factor_ptr64_double (
    posdef=.FALSE., val=..., akeep=..., fkeep=..., options=..., inform=..., 
    scale=..., ptr=..., row=...) at ../src/ssids/ssids.f90:1044
#20 0x000000000059e4e8 in spral_ssids::ssids_factor_ptr32_double (
    posdef=.FALSE., val=..., akeep=..., fkeep=..., options=..., inform=..., 
    scale=..., ptr=..., row=...) at ../src/ssids/ssids.f90:757
#21 0x000000000059a06b in spral_ssids_factor_ptr32 (cposdef=<optimized out>, 
    cptr=<optimized out>, crow=<optimized out>, val=..., 
    cscale=<error reading variable: Attempt to dereference a generic pointer.>, cakeep=<error reading variable: Attempt to dereference a generic pointer.>, 
    cfkeep=0x16203c0, coptions=..., cinform=...)
    at ../interfaces/C/ssids.f90:599
#22 0x000000000056424e in Ipopt::SpralSolverInterface::MultiSolve(bool, int const*, int const*, int, double*, bool, int) ()

CC @jfowkes

@jfowkes
Copy link
Member

jfowkes commented Feb 8, 2022

Thanks @svigerske, this definitely looks like an issue on our side deep within SPRAL:
https://github.com/ralna/spral/blob/master/src/ssids/cpu/BuddyAllocator.hxx#L105
Looks like some memory doesn't get deallocated on cleanup when it should. @tyronerees any thoughts?

@svigerske
Copy link
Member

Continued in ralna/spral#81.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants