[SCIP] Valgrind log showing slightly different solution path in MINLP

[Bayramoglu, Selin]

Many thanks for the detailed response!

I have linked SCIP into an executable so the memory leaks in the log should not be a problem for me. As for the slightly different solution paths I think it is unavoidable at the moment and not due to a bug in my program.

Best,

Selin

From: Stefan Vigerske <svigerske at gams.com>
Date: Thursday, 1 February 2024 at 00:22
To: Bayramoglu, Selin <sbayramoglu3 at gatech.edu>, scip at zib.de <scip at zib.de>
Subject: Re: [SCIP] Valgrind log showing slightly different solution path in MINLP
Hi,

SCIP is deterministic, but the deterministic calculations that it is
doing under valgrind can be different from the one without valgrind.
We have seen this before, in particular when nonlinear constraints are
present, and the current assumption is that this is due to valgrind
being imperfect for some operations that are done in non-default
rounding mode (which happens for bound tightening of nonlinear constraints).
See also the point "Valgrind has the following limitations in its
implementation of x86/AMD64 floating point relative to IEEE754." in
https://valgrind.org/docs/manual/manual-core.html#manual-core.limits
That part about 64bit vs 80bit floating point precision could also play
a role.

Regarding the memory leaks, these are not so trivial to fix. On the
positive side, these are allocations that happen only once. If you have
linked SCIP into an executable, then "once" would mean one time the
program runs. This memory will be freed up again anyway when the
executable finishes. If you load and unload SCIP as a shared library
dynamically (dlopen()), then this allocation by
CppAD::thread_alloc::thread_info() happens every time the library is
loaded, so there is a more serious memory leak. It would be nice to free
the memory when the library unloads, but there is no portable way to do
this (On Unix-like systems you have either __attribute__(destructor)
(GCC/clang) or the .fini section to define global destructors at
arbitrary places, but with MSVC you can have only one DllMain() per
library). Having an API function that a user could call when
unloading/exit would probably be the way to go.
The memory from GOMP's initialize_env() is similar. GOMP allocates some
global memory once and does not free it. I'm not sure what will happen
there in a setting where the GOMP lib is repeatedly loaded and unloaded.
A call to omp_pause_resource_all(omp_pause_hard) may free this memory.

Best,
Stefan

On 01/02/2024 03:58, Bayramoglu, Selin wrote:
> Hello everyone,
>
> I am solving an MINLP with SCIP 8.0.0 with default options and a node limit of 1 and running it with Valgrind (options: --leak-check=full --show-leak-kinds=all --num-callers=50). My program only executes SCIP with no additions. It seems like the solution path of the runs with and without Valgrind are slightly different. The first line after presolve shows that the number of LP iterations are different. To my knowledge SCIP is deterministic in the absence of a time limit so I expect it to have the same solution path in both runs.
>
> In addition, the valgrind log shows no errors but only memory leaks of type “still reachable”. It seems like it is safe to execute the program given these leaks but I wanted to get your opinion on it.
>
> Please find attached the problem file and the logs. Many thanks for your help in advance.
>
> Best regards,
>
> Selin
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20240201/09e1caad/attachment.html>