Baron does not work with the Pyro solver manager

[ghackebeil]

Reported on the pyomo forum by @qtothec:
https://groups.google.com/forum/#!topic/pyomo-forum/EmVkqIjJYXg

[ghackebeil]

This one took me some time to figure out. Here is the issue:

The baron solver, as far as I am aware, does not accept command line options. When we give options like a solution file name, these options must appear inside of the baron input file. In the pyro_mip_server setting, the problem file is written by the client and transmitted to the pyro solver server, so the solution file name is assigned ahead of time and the solver server, not knowing this, provides a new random temporary filename and assumes it will somehow be passed down to the solver (but it doesn’t, and baron writes the solution to the original path assigned by the client).

I can think of a few ways to fix this:

1. If there is another way to pass options to Baron, via the command-line or a separate script file, we start doing that. I don’t think there is though. Perhaps someone can petition the Sahinidis group to make a change.
2. We can transmit the assigned solution file name to the pyro solver server, which can be passed down to the solver plugin causing it to not assign a new temporary filename but rather use the provided one. This probably wouldn’t completely fix the issue, as tempfile names generated by a client on one machine might not be valid on the machine where the pyro_mip_server is running. It would fix the case where the client and server are on the same machine, which is likely what a large fraction of users are doing anyway. However, it would break the more general case (multi-machine, multi-OS) for other solvers, which don’t currently have to transmit any predefined tempfile names (I think).
3. We adjust the BARON solver plugin workflow to apply these kinds of solver options just before the solver is executed (after _presolve). The only way I can think of doing this is by copying the original solver input file without the options header section into a new file that includes the options header section at the beginning. This seems costly, but it’s probably not that big of a hit relative to the typical solve time that will be spent in Baron when solving MINLPs.

Thoughts?

[jsiirola]

I agree that (1) is the most elegant (in that it would bring Baron in line with most other solvers). That said, if we have to implement one now, (3) seems reasonable to me.

Given other weirdness we have with the current design of solver writers / symbol maps / etc., is there a way we could re-architect Pyomo's solver interfaces that would be better compatible with both solvers like Baron and things like distributed processing? That is a bigger issue than just this ticket, but something I'd like to start thinking about.

[qtothec]

I asked Nick about it. I can verify that BARON doesn't take command line options, and it doesn't seem to be on the planning horizon:

BARON does not accept command line options. Instead, the server should be adjusted to modify any ResName statements in the .bar file so as to avoid clashes and do the necessary bookkeeping for all files generated. An easy way to do this is generated a directory during run time, run BARON there, copy the results wherever needed, and delete the directory.

[qtothec]

Do we still want to keep this issue around? I don't have any need to use Baron through Pyro at this point.

[ghackebeil]

I think it's probably good to keep around until someone starts on the solver base class re-implementation.