Home

Outlining changes to update method

Broadly speaking, the update method, according to this line of thinking, should be used to help generate solutions for problems more quickly when variants of a similar problem (or problems) have already been solved. This will be done primarily by working to provide the solver with "warm start" values when possible in a variety of situations. These updates should also aim to minimize the responsibility of users to identify and manage the details of the various processes involved.

First, it should be assumed that solutions to similar and related problems exist. Node prices from these existing solutions will serve as the foundation for the warm start generation process.

There are a few main groups of scenarios that update ought to be able to handle:

1. Problems that differ only by parameter arguments, such as tol.

• Functionality for this exists in some capacity in the hinting branch of this fork
  • Those changes should be refactored and worked into these processes
  • The hinting version of the code makes some assumptions about usage that are not quite correct anymore. It also requires users to provide node prices as an argument, which is not preferable
• This is likely the easiest case to handle. There would the same number of units in each problem, meaning minimal wrangling of nodes. Minimal adjustments to node prices are necessary--just some new integer conversion and rounding in some cases.
• This is also likely the logical starting point for this effort.

2. Combining problems that were originally divided up into subproblems or sub-groups into a larger problem.

• This will involve finding ways to adjust prices between the different problems in order to create a reasonable set of prices for the combined problem
• Potentially, there may be cases where optimal solutions can be generated, avoiding any call to the solver.

3. Introducing new data into a problems

• I've outlined some procedures that are designed to generate CS starting values when introducing a single new node into a network. These should readily generalize to scenarios involving the introduction of multiple nodes to a network. More to come on that.

4. Data has been modified

• Not entirely sure what the full scope of this looks like yet. Intuitively, if the data has not been modified greatly, then a set of node prices from a previously solved problem with the old data should serve as a good warm start.
• However, there might be more that we can do to extend the functionality.

I propose that the new update method will need to appropriately determine what set of procedures is most appropriate, rather than having the users make decisions about what type of warm start generation procedure is needed.

I think that this can be achieved if users are required to pass an optmatch object to the method. This is preferable to requiring a node price argument, as is currently the case in the hinting branch

Requirements

optmatch objects should have the formula used to create them as an accessible slot or attribute.

We should make use of new functionality allowing for quick comparison of optmatch objects when possible.

Logic for determining each scenarios

How can changes in the data from one problem to another be detected?

• Saving a formula with each optmatch object has a number benefits. First, it can help identify which parameters have been tweaked, if any. Additionally, it can help identify how data has been sub-grouped (if at all). We can also evaluate what was passed in previously, as long as environments haven't been cleared/deleted.