Calling two different problems, one after the other, breaks the second. about cutest.jl

[abelsiqueira]

I made some modifications in the code to break if two calls to CUTEstModel are made. This does not fix the problem, but it is better than letting the user thinks the decoding was sucessful.
The commit is abelsiqueira/CUTEst.jl@6412f637, and testing was updated after that.

[dpo]

Many thanks. I have to look into this more closely, but I'm tied up until Wednesday.

[dpo]

The same behavior occurs with the Matlab interface, but issuing a clear all before decoding the second problem resolves the issue, which makes me wonder if it's really a CUTEst issue. I've tried calling Julia's garbage collector before loading the second problem, but that didn't do it.

[abelsiqueira]

I was thinking that this could be a problem with the global variables in CUTEst. Maybe the clear all on matlab clear those too?

[dpo]

Yes I believe it does. I don't see a way to clear them in Julia.

[dpo]

Did your previous interface allow for two consecutive problems?

[abelsiqueira]

Yes I believe it does. I don't see a way to clear them in Julia.

Maybe accessing each one directly through this?
But I don't think that is a good idea, because it seems like something that CUTEst should handle on its own.

Did your previous interface allow for two consecutive problems?

No, I had the exact same problem.

[abelsiqueira]

Returning to this discussion, removing @eval did not fix the problem. I'm still investigating though.

I also tried to make something in C to investigate what is happening.
I found out that the problem isn't at the decoding, or at the .f created. In that example, I decode two problems before linking to the executable. Then I rename the SIF files (ELFUN, EXTER, etc.) so that both remain in the folder. Then I link each SIF file to a main.c. This main.c calls opens each problem and print x0 and f(x0), one at a time. Each executable prints the correct output for their linked correspondent, but not for the other. In addition the wrong function value corresponds to the one in CUTEst.jl. This, at least, shows that the problem is not decoding twice, or reopening the OUTSDIF.d file, so it must be internal.

[abelsiqueira]

Hey, turns out that (at least now that we open the library with dlopen), that closing it on terminate made this almost work. This build made this change, and fixed some calls in julia_interface that break in this specific scenario.

However, this is still not fully operational. The OSX build does not work (can't test why), and also the specialized interface test breaks on the second call. Don't know why yet. The segmentation fault that happens is on the dlclose call, but it doesn't happens (necessarily) outside the runtests.jl script.

For now, on linux, checkout the fix/double_decode branch and do

nlp = CUTEstModel("HS32")
cfn(nlp, nlp.meta.x0)
cutest_finalize(nlp)
nlp = CUTEstModel("HS4")
ufn(nlp, nlp.meta.x0)
cutest_finalize(nlp)

[abelsiqueira]

Made it work on C. In this example I decode two problems and load their libraries at the same time. I had to create elfun_ and group_ using a global pointer to the "active" library. This successfully enabled the use of two libraries simultaneously.
Also, I had to use the dl* functions, so maybe I'm on the right direction.

[abelsiqueira]

Hey, just made a PR regarding this problem.
The solution I found is not the best, but it works, and is well tested.
Essentially, I removed the possibility of having two problems open at the same time, which allows the use of a global variable for the shared library.
I tried making it work with two problems at the same time, as my comment above suggests, but eventually it broke randomly again.

However, I think that this is as good as would be expected of a CUTEst interface. The usual user would normally open one file at a time (I think), and the three interfaces are working.

[abelsiqueira]

Fixed