Merge two optimization models

[Simon Hilpert]

Hi, 

is there a way to merge two optimization models?

I have to ConcreteModel instances and I would like to merge all constraints etc. into one optimization model. 

The objective will be set new. As there might be the same naming for some of the attributes for the two models, 

I thought of somehow using the Block() functionalities of pyomo. 

# Abstract example: 

m1 = ConcreteModel()

m1.constr1 = Constraint(...) 

...

m2 = ConcreteModel()

m2.constr1 = Constraint(..)

...

# delete objectives

m1.del_component('objective')

m2.del_component('objective')

# magically merge the two problems:

m =m1 + m2       ????

# set new objective

m.objective = (...)

I hope the example is concrete enough to understand...

[Gabe Hackebeil]

A ConcreteModel is a Block, so you can simply place one on the other or add them both to a new model. E.g.,

m1 = ConcreteModel()

m1.obj = Objective(...)

...

m2 = ConcreteModel()

m2.obj = Objective(...)

...

m = ConcreteModel()

m.m1 = m1

m.m2 = m2

m.m1.obj.deactivate()

m.m2.obj.deactivate()

m.obj = Objective(...)

...

Gabe

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Hilpert]

Hi Gabe,

Thanks! It worked for me. 

Actually I am merging two solved instances (results loaded back) and I have one last question:

I like to use the values found  for variables of the 'subproblems' as intitial values for a warmstart of the merged problem. 

Based on the reduced costs I fix some variables, which will be basically converted into parameters for the optimiation problem.

The rest of variables of course do have values as well, but they are not fixed. 

 Is it enough to just set  warmstart=True for the merged problem and solve again? 

[Gabe Hackebeil]

Yes, but with one catch. Not all solver interface will accept the warmstart keyword. For example, the NL file interface, which is for solver executables that work with AMPL like cplexamp and ipopt, does not accept this keyword but will always send warmstart information for all variables.

Otherwise it's up to the exact solver plugin that we have implemented. I think for the CPLEX and Gurobi LP file and Python interfaces we just send the values for binary or integer variables if they exist.

Gabe

--

[Simon Hilpert]

Does the first statement imply, that if I have a solved instance (or a instance with initial values for variables) and I will pass it via the NL interface, a warmstart is performed in any case? (Even though i can't set this explicitly)

Thanks a lot! 

[Gabriel Hackebeil]

Correct.