The MOSEK Python optimizer API manual Version 7.0 (Revision 141)
Optimizer API for Python - Documentation - Mosek Optimizer API for Python - Documentation - Mosek
606 APPENDIX F. MOSEK FILE FORMATS Apart from containing objective, constraints, bounds etc. it may contain complete or partial solutions, comments and extra information relevant for solving the problem. It is designed to be easily read and modified by hand and to be forward compatible with possible future extensions. F.3.1 Intended use The OPF file format is meant to replace several other files: • The LP file format. Any problem that can be written as an LP file can be written as an OPF file to; furthermore it naturally accommodates ranged constraints and variables as well as arbitrary characters in names, fixed expressions in the objective, empty constraints, and conic constraints. • Parameter files. It is possible to specify integer, double and string parameters along with the problem (or in a separate OPF file). • Solution files. It is possible to store a full or a partial solution in an OPF file and later reload it. F.3.2 The file format The format uses tags to structure data. A simple example with the basic sections may look like this: [comment] This is a comment. You may write almost anything here... [/comment] # This is a single-line comment. [objective min ’myobj’] x + 3 y + x^2 + 3 y^2 + z + 1 [/objective] [constraints] [con ’con01’] 4
F.3. THE OPF FORMAT 607 [tag "value"] double-quoted value [/tag] [tag arg="value"] double-quoted value [/tag] F.3.2.1 Sections The recognized tags are • [comment] A comment section. This can contain almost any text: Between single quotes (’) or double quotes (") any text may appear. Outside quotes the markup characters ([ and ]) must be prefixed by backslashes. Both single and double quotes may appear alone or inside a pair of quotes if it is prefixed by a backslash. • [objective] The objective function: This accepts one or two parameters, where the first one (in the above example ‘min’) is either min or max (regardless of case) and defines the objective sense, and the second one (above ‘myobj’), if present, is the objective name. The section may contain linear and quadratic expressions. If several objectives are specified, all but the last are ignored. • [constraints] This does not directly contain any data, but may contain the subsection ‘con’ defining a linear constraint. [con] defines a single constraint; if an argument is present ([con NAME]) this is used as the name of the constraint, otherwise it is given a null-name. The section contains a constraint definition written as linear and quadratic expressions with a lower bound, an upper bound, with both or with an equality. Examples: [constraints] [con ’con1’] 0 = x + y [/con] [con ’con3’] 0
- Page 577 and 578: D.6. TYPES OF CONVEXITY CHECKS. 555
- Page 579 and 580: D.10. DOUBLE INFORMATION ITEMS 557
- Page 581 and 582: D.10. DOUBLE INFORMATION ITEMS 559
- Page 583 and 584: D.11. FEASIBILITY REPAIR TYPES 561
- Page 585 and 586: D.13. INTEGER INFORMATION ITEMS. 56
- Page 587 and 588: D.13. INTEGER INFORMATION ITEMS. 56
- Page 589 and 590: D.13. INTEGER INFORMATION ITEMS. 56
- Page 591 and 592: D.16. INPUT/OUTPUT MODES 569 intpnt
- Page 593 and 594: D.20. CONTINUOUS MIXED-INTEGER SOLU
- Page 595 and 596: D.26. OBJECTIVE SENSE TYPES 573 D.2
- Page 597 and 598: D.31. PRESOLVE METHOD. 575 paramete
- Page 599 and 600: D.35. RESPONSE CODE TYPE 577 D.35 R
- Page 601 and 602: D.42. PROBLEM REFORMULATION. 579 si
- Page 603 and 604: D.46. SOLUTION TYPES 581 solsta.dua
- Page 605 and 606: D.50. STREAM TYPES 583 startpointty
- Page 607 and 608: Appendix E Troubleshooting When cre
- Page 609 and 610: Appendix F Mosek file formats MOSEK
- Page 611 and 612: F.1. THE MPS FILE FORMAT 589 Fields
- Page 613 and 614: F.1. THE MPS FILE FORMAT 591 must b
- Page 615 and 616: F.1. THE MPS FILE FORMAT 593 Constr
- Page 617 and 618: F.1. THE MPS FILE FORMAT 595 v 1 is
- Page 619 and 620: F.1. THE MPS FILE FORMAT 597 Please
- Page 621 and 622: F.2. THE LP FILE FORMAT 599 minimiz
- Page 623 and 624: F.2. THE LP FILE FORMAT 601 st defi
- Page 625 and 626: F.2. THE LP FILE FORMAT 603 bounds
- Page 627: F.3. THE OPF FORMAT 605 iparam.writ
- Page 631 and 632: F.3. THE OPF FORMAT 609 Note that a
- Page 633 and 634: F.3. THE OPF FORMAT 611 F.3.2.3 Nam
- Page 635 and 636: F.3. THE OPF FORMAT 613 [bounds] [b
- Page 637 and 638: F.4. THE TASK FORMAT 615 This can b
- Page 639 and 640: F.7. THE SOLUTION FILE FORMAT 617 c
- Page 641 and 642: Appendix G Problem analyzer example
- Page 643 and 644: G.2. ARKI001 621 2 476 45.42 48.19
- Page 645 and 646: G.4. PROBLEM WITH BOTH LINEAR AND C
- Page 647 and 648: Bibliography [1] Chvátal, V.. Line
- Page 649 and 650: Index analyzenames (Task method), 2
- Page 651 and 652: INDEX 629 getpcni (Task method), 25
- Page 653 and 654: INDEX 631 putbarablocktriplet (Task
- Page 655 and 656: INDEX 633 rescode.err inv numj, 521
- Page 657 and 658: INDEX 635 rescode.err sen bound inv
F.3. THE OPF FORMAT 607<br />
[tag "value"] double-quoted value [/tag]<br />
[tag arg="value"] double-quoted value [/tag]<br />
F.3.2.1<br />
Sections<br />
<strong>The</strong> recognized tags are<br />
• [comment] A comment section. This can contain almost any text: Between single quotes (’) or<br />
double quotes (") any text may appear. Outside quotes the markup characters ([ and ]) must<br />
be prefixed by backslashes. Both single and double quotes may appear alone or inside a pair of<br />
quotes if it is prefixed by a backslash.<br />
• [objective] <strong>The</strong> objective function: This accepts one or two parameters, where the first one<br />
(in the above example ‘min’) is either min or max (regardless of case) and defines the objective<br />
sense, and the second one (above ‘myobj’), if present, is the objective name. <strong>The</strong> section may<br />
contain linear and quadratic expressions.<br />
If several objectives are specified, all but the last are ignored.<br />
• [constraints] This does not directly contain any data, but may contain the subsection ‘con’<br />
defining a linear constraint.<br />
[con] defines a single constraint; if an argument is present ([con NAME]) this is used as the name<br />
of the constraint, otherwise it is given a null-name. <strong>The</strong> section contains a constraint definition<br />
written as linear and quadratic expressions with a lower bound, an upper bound, with both or<br />
with an equality. Examples:<br />
[constraints]<br />
[con ’con1’] 0 = x + y [/con]<br />
[con ’con3’] 0