I looked into this some years ago. My memory is hazy but at the time I think we decided not to imbed Ampl in our own consulting software because of the exposure of IP and difficulties relating to maintaining different components of the model in different sources. For instance, we have a basic model generated in Concert and wanted the capability of allowing the user to customize that model with additional components in Ampl while somehow obfuscating our base model. At the time, I don´t think that was possible.
So I also have a similar questions:
· Can model components come from sources other than Ampl?
· Even if all model components have to be in Ampl script can some components be maintained in separate AND compiled format?
· Is there an additional license required and what is the cost?
I suspect that all model components must be internal to Ampl scripts. If this is the case we have a different problem. How do we maintain a code base where some components are being generated using Cplex or Gurobi C# libraries and then translated to Ampl script? What we have done is output the Ampl equivalent as a printf (or the equivalent) but this is subject to error and onerous to maintain. Has someone found a better approach?
Regards,
Martin
From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of s.bo...@gmail.com
Sent: Wednesday, July 10, 2013 7:00 AM
To: am...@googlegroups.com
Subject: [AMPL 7238] Embedding AMPL in a desktop application
Hi,
we're building a desktop application (consulting software), a part of which could be modeled as an AMPL program.
Ultimately, what we would like to do is: define a model for the problem in AMPL, compile it in some binary form so that the users of our application can't read the actual source and finally solve the problem using a solver that will be distributed with the application.
I would like to know if it's feasible to convert an AMPL model to some kind of binary format that is not human readable.
Apart from that, is it allowed to embed the AMPL executable in our software so that we can run it on the background if needed?
I am aware that FICO provides this capability, does AMPL have a different approach? (http://www.fico.com/en/Products/DMTools/xpress-overview/Pages/Xpress-Mosel.aspx)
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups "AMPL Modeling Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ampl+uns...@googlegroups.com.
To post to this group, send email to am...@googlegroups.com.
Visit this group at http://groups.google.com/group/ampl.
For more options, visit https://groups.google.com/groups/opt_out.
Generally AMPL is embedded in applications through scripting. The application creates files for an AMPL model, and then initiates an AMPL process that reads a script. Commands in the script then read AMPL model and data files and execute various commands, including one or more "solve" commands in that invoke a solver to find the solutions to the optimization problems of interest. Finally the script writes results to an output file, which the application reads after the termination of the AMPL process. Communication between the application and AMPL is thus via files under this arrangement.
It is also possible to interact with AMPL at a more fundamental level by sending commands to the AMPL processor one by one -- using a C "put" function that we supply -- and interpreting the results. This is not normally used for applications, however.
A higher-level object-oriented API for invoking AMPL from various languages is under development, and we're planning to beta-test some of its versions this fall (though C# will probably be somewhat later).
AMPL is fundamentally not a compiled language. However if the concern is only to hide part of a model from users of an application, we can provide some free routines that facilitate encrypting a model file.
The motivation for AMPL was to make the use of solver libraries unnecessary, so using AMPL together with the CPLEX or Gurobi C# libraries is indeed problematical. Our APIs may eventually help with this, but still the choice of a solution is likely to depend on the specifics of the application.
Bob Fourer
From: am...@googlegroups.com [mailto:am...@googlegroups.com]
On Behalf Of martin smith
Sent: Tuesday, July 9, 2013 5:21 PM
To: am...@googlegroups.com
Cc: 4...@ampl.com; Stewart Wicks (MineSmith)
Subject: [AMPL 7239] Embedding AMPL in a desktop application