Problem reading certain .sol files

[Samuel A]

Hello,

I am using AMPL's ASL as a part of a polynomial programming optimization tool to read and write .sol files, and I have run into a problem when reading the .sol files generated by multiple non linear solvers, such as Ipopt, Knitro or Minos. This problem arises when the problem I am trying to solve has no contraints, apparently no matter how simple it may be, and is provided in a .nl binary file. For instance, I have modelled the following problem using AMPL:

var x <=10, >= 0;
minimize f: x;
option presolve 0;
write gproblem_asl_hex;
write bproblem_asl_binary;

I have attached a zip file where I've included a small program which will attempt to read a .sol file in the same way it's trying to be read in the bigger tool I'm working on. I've also included the .nl files generated by AMPL from the previous model, namely

problem_asl_binary.nl

problem_asl_hex.nl

as well as the .sol files generated in both the hexadecimal and binary cases by the non linear solvers mentioned above. The files are the following:

problem_asl_binary_ipopt.sol

problem_asl_binary_knitro.sol

problem_asl_binary_minos.sol

problem_asl_hex_ipopt.sol

problem_asl_hex_knitro.sol

problem_asl_hex_minos.sol

Should the program need to be compiled again, I've included all the necessary header files and possibly more. When compiled, a bunch of warnings arise because of the redefinition of variables, but from what I've seen they don't seem relevant to the process of reading the .sol file. Running the program to read one of the .sol files generated from the hexadecimal problem, for instance:

./read_sol problem_asl_hex.nl problem_asl_hex_ipopt.sol

shouldn't cause any issues, but reading the .sol file generated from the binary problem by the same or any other or the non linear solvers provided:

./read_sol problem_asl_binary.nl problem_asl_binary_ipopt.sol 

returns "bad binary file problem_asl_binary_ipopt.sol", which I've tracked to some part of readsol.c in the GitHub, but I haven't been able to see where the issue is coming from. When I came across the problem for the first time, I wasn't using the newest version of the ASL library, but I've tested that the problem persists in the most recent commit (594e911). In fact, the compiled library libasl.a I've attached was generated from this latest version.

Could you please point me to the problem? I've initially assumed it has to be caused on my end, somewhere in the source code I've attached, but I haven't been able to find a solution for it.

Best regards,

Samuel.

[AMPL Google Group]

I am going to ask the author of ASL to have have a look at this. But first, I want to be sure as to the scope of the problem. As I understand it, the "bad binary file" error is only seen when

• there are no constraints, and
• the binary (not text) form of the .sol file is read.

Also I think the setup is clear: You are compiling main.cpp using libasl.a and the various header files to produce the Linux binary read_sol, which you invoke with statements like

./read_sol problem_asl_binary.nl problem_asl_binary_ipopt.sol

The first argument gives the .nl file from which n_var and n_con are extracted, and the second argument gives the .sol file that is read to get the solution. Please confirm that this is correct, or provide any needed clarifications.

--
Robert Fourer
am...@googlegroups.com

{#HS:1674577153-106824#}

[Samuel A]

Hello,

That is correct. The problem seems to only appear when working with an unconstrained problem that has been read from a .nl binary file. The non-linear solvers produce, in turn, a .sol file that is also binary, which is the one that yields the error message when I try to read it.

The setup is also correct. A statement like

g++ -o read_sol main.cpp libasl.a -ldl

is what I've used to obtain the Linux binary read_sol.

Yes, the first argument is the .nl file from which the .sol file has been generated by one of the solvers, and it is indeed used to get information like n_var and n_con. The second argument is the .sol file that contains the solution I'm attempting to read.

Best regards,

Samuel.

[AMPL Google Group]

Your experience with reading binary .sol files for unconstrained problems has revealed a bug, which has now been fixed. In https://ampl.com/netlib/ampl/solvers, the fix affects readsol.c and asldate.c.

--
Robert Fourer
am...@googlegroups.com

{#HS:1674577153-106824#}

On Wed, Oct 27, 2021 at 8:29 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Hello,

That is correct. The problem seems to only appear when working with an unconstrained problem that has been read from a .nl binary file. The non-linear solvers produce, in turn, a .sol file that is also binary, which is the one that yields the error message when I try to read it.

The setup is also correct. A statement like

g++ -o read_sol main.cpp libasl.a -ldl

is what I've used to obtain the Linux binary read_sol.

Yes, the first argument is the .nl file from which the .sol file has been generated by one of the solvers, and it is indeed used to get information like n_var and n_con. The second argument is the .sol file that contains the solution I'm attempting to read.

Best regards,
Samuel.

On Wed, Oct 27, 2021 at 5:41 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

I am going to ask the author of ASL to have have a look at this. But first, I want to be sure as to the scope of the problem. As I understand it, the "bad binary file" error is only seen when

• there are no constraints, and
• the binary (not text) form of the .sol file is read.

Also I think the setup is clear: You are compiling main.cpp using libasl.a and the various header files to produce the Linux binary read_sol, which you invoke with statements like

./read_sol problem_asl_binary.nl problem_asl_binary_ipopt.sol

The first argument gives the .nl file from which n_var and n_con are extracted, and the second argument gives the .sol file that is read to get the solution. Please confirm that this is correct, or provide any needed clarifications.

--
Robert Fourer
am...@googlegroups.com

[Samuel A]

Thank you for your help!

Best regards,

Samuel.