Model building style recommendations
- Separation of problem logic and data
- Typically, the model logic stays constant once developed, with the data changing each run
- Fix the model and obtain data from their source to avoid editing the model which can create errors, expose intellectual property, and is impractical for industrial size data
- You should aim to build a model with sections in this order
- constant data: declare, initialize
- all non-constant objects: declare
- variable data: initialize / input / calculate
- decision variables: create, specify bounds
- constraints: declare, specify
- objective: declare, specify, optimize
- Use a naming convention that distinguishes between different model object types, for example
- known values (data) using upper case
- unknown values (variables) using lower case
- constraints using mixed case
- Variables are actions that your model will prescribe
- Use verbs for the names of variables. This emphasizes that variables represent `what to do' decisions
- Try to include `min' or `max' in the name of your objective function; an objective function called `OBJ' is not very helpful when taken out of context!
- Indices are the objects that the actions are performed on
- Use nouns for the names of indices
- Declare all objects in your model (optional unless using compiler option noimplicit)
- Allows the compiler to detect syntax errors more easily
- Mosel's guessed declaration doesn't always work
- A form of rigour and documentation
- An opportunity for a descriptive comment
- Comments are essential for a well written model
- Always use a comment to explain what each parameter, data table, variable, and constraint is for when you declare it
- Add extra comments to explain any complex calculation etc
- Comments in Mosel:
declarations make: array(1..NP, 1..NT) of mpvar ! Amount of p produced in time t sell: array(1..NP, 1..NT) of mpvar ! Amount of p sold in time t end-declarations (! And here is a multi-line comment !) forall(t in 1..NT) ...