Extension ideas

[odow]

Solution instance

Mapped directly from MOI status (ignores solver termination)

{
  "version": "0.0",
  "sense": "min",
  "objective": {},
  "constraints": [],

  "solution": {
    "primal": {
      "status": "Feasible",
      "objective": 1.0,
      "variable": {"x1": 1.0, ...},
      "constraint": {"c1": 1.0, ...},
    },
    "dual": {
    }
  }
}

Maybe to warm-start we have "initialsolution" and "optimalsolution" fields?

Solver options

Set tolerances

{"head": "GreaterThan", "lower": 3.0, "atol":1e-6}
{"head": "Integer", "atol":1e-6}

Not sure how to do optimality gap etc.

Modifications

Can either replace entire sets and/or functions

"modifications": [
  {
    "objective": { ... new function ... },
    "c1": {"set": { ... new set ... }, "function": { ... new function ... }}
  }, 
 { ... another realization ... }
]

Or introduce parameters

{
  "set": {
    "head": "GreaterThan",
    "lower": {"head": "parameter", "name": "!SETLOWER!", "default": 3.0}
  },
  "function": { ... }
}

# ... and at the bottom of the file

"modifications": [
  {"!SETLOWER!": 4.0},
  { ... another realization ... }
]

or both

{
  "name": "c1",
  "set": {
    "head": "GreaterThan",
    "lower": {"head": "parameter", "name": "!SETLOWER!", "default": 3.0}
  },
  "function": { ... }
}

"modifications": [
  {
    "!SETLOWER!": 4.0,
    "c1": {"function": { ... new function ... } }
  },
  { ... another realization ... }
]

[odow]

Coming back to the modifications since I need these and it would be good to add to the schema (#47).

We have a few options:

1. Declare as out-of-scope.

Pros: simple

Cons: MPS and CBF have limited supported, I'd have to extend this in the stochastic format anyway

2. Implement parameters (#27). This involves defining a Parameter type:

"Parameter": {
    "oneOf": [{
        "type": "number"
    }, {
        "type": "object",
        "properties": {
            "head": {
                "const": "Parameter"
            },
            "name": {
                "type": "string"
            },
            "default": {
                "type": "number"
            }
        },
        "required": ["head", "name", "default"]
    }]
}

And then any numeric term (e.g., coefficient in ScalarAffineTerm, lower in GreaterThan) becomes

"coefficient": {
    "$ref": "#/Parameter"
}

Pros: works well with non-linear, simple concept, flexible.

Cons: when parsing the value is no longer type-stable. Not obvious how to support constraint transforms (less-than to greater-than etc). Complex-valued parameters?

3. Implement MOI modifications, e.g., something along the lines of

"modifications": {
    "type": "object",
    "required": ["head", "constraint"],
    "properties": {
        "constraint": {
            "type": "string"
        }
    },
    "oneOf": [{
        "properties": {
            "head": {
                "const": "ScalarConstantChange"
            },
            "new_constant": {
                "type": "number"
            }
        }
    }, {
        "properties": {
            "head": {
                "const": "ScalarSetChange"
            },
            "new_set": {
                "$ref": "#/definitions/scalar_sets"
            }
        }
    }]
}

Pros: lines up with MOI

Cons: many modifications missing from MOI (quadratic changes, nonlinear parameters).

[odow]

Closing as out-of-scope. We haven't made any progress on this.