Issues #73 and #72 demonstrate that the .lp file format is not very clearly specified. It might thus be more stable to use other more clearly file formats for any solvers that allow this. For solvers from the COIN-OR Suite (including cbc, but also see: https://coin-or.github.io/user_introduction), the best format is probably OSIL and according to slide 8 in this COIN-OR presentation, .nl might be another option.
OSIL
"an open, XML-based format used by the Optimization Services framework of COIN-OR"
This seems to be a very rigorously specified and very powerful format and all the tools in COIN-OR can handle it. It would require using some Rust xml parsing library and implementing the specification with it: there are some good hints in this recent blog post, so probably strong-xml or yaserde would be good. So implementing the format will be more involved.
All relevant info is on this webpage, including a link to the original paper describing it and the current stable specification:
.nl
"AMPL’s intermediate format that also supports non-linear modeling."
I guess, the complexity of implementing this would be somewhere in between the .lp file format and the OSIL .xml format. It might be a good compromise, as it seems that both COIN-OR and gurobi have capabilities of working with the .nl format.
Resources:
What do others think? Further format suggestions? Or objections?
Issues #73 and #72 demonstrate that the
.lpfile format is not very clearly specified. It might thus be more stable to use other more clearly file formats for any solvers that allow this. For solvers from theCOIN-ORSuite (including cbc, but also see: https://coin-or.github.io/user_introduction), the best format is probablyOSILand according to slide 8 in thisCOIN-ORpresentation,.nlmight be another option.OSIL"an open, XML-based format used by the Optimization Services framework of COIN-OR"
This seems to be a very rigorously specified and very powerful format and all the tools in
COIN-ORcan handle it. It would require using some Rustxmlparsing library and implementing the specification with it: there are some good hints in this recent blog post, so probablystrong-xmloryaserdewould be good. So implementing the format will be more involved.All relevant info is on this webpage, including a link to the original paper describing it and the current stable specification:
.nl"AMPL’s intermediate format that also supports non-linear modeling."
I guess, the complexity of implementing this would be somewhere in between the
.lpfile format and theOSIL.xmlformat. It might be a good compromise, as it seems that bothCOIN-ORandgurobihave capabilities of working with the.nlformat.Resources:
.nlformat.nlfile format reader in C++.nlfile format in more detailWhat do others think? Further format suggestions? Or objections?