2017-10-01 10 views
1

J'essaye de sauver les solutions de ce problème d'optimisation mais elles sont Nonetype. Par conséquent, je veux les convertir en float mais je reçois cette erreur:Pourquoi ne puis-je pas passer de 'Non-type' à 'float'?

float() argument must be a string or a number, not 'NoneType'

Il est rare en raison de la solution imprimée à partir results.write() x1 est 6,57142857142857.

from coopr . pyomo import * 
from pyomo.opt import SolverFactory 

def create_model(N=[], M=[], c={}, a={}, b={}): 
    model = ConcreteModel() 
    model.x = Var(N, within=NonNegativeReals) 
    model.obj = Objective(expr=sum(c[i]*model.x[i] for i in N)) 
    def con_rule(model, m): 
     return sum(a[i,m]*model.x[i] for i in N) >= b[m] 
    model.con = Constraint(M, rule=con_rule) 
    return model 
model = create_model(N = [1,2], M = [1,2], c = {1:1, 2:2}, 
a = {(1,1):5, (2,1):4, (1,2):7, (2,2):3}, 
b = {1:11, 2:46}) 

#model.pprint() 

instance = model.create() 
#instance.pprint() 
opt = SolverFactory("glpk") 
results = opt.solve(instance, load_solutions=False) 
results.write() 

x_1=float(model.x[1].value) 
#x_2=float(model.x[2].value or 0) 

Répondre

0

D'abord, model.create() est dépréciée sur la version la plus récente de Pyomo. Je crois qu'il est maintenant renommé en model.create_instance.

Deuxièmement, vous résolvez l'objet instance retour de model.create(), qui est un objet différent de model. Par conséquent, vous devez accéder à l'attribut .value des variables sur l'objet instance et non à l'objet model. Troisièmement, vous commencez par ConcreteModel, ce qui signifie qu'il n'est pas nécessaire d'appeler model.create() (ou model.create_instance()). Cela crée simplement une copie inutile de ce qui est déjà une "instance concrète". Par exemple, vous pouvez envoyer l'objet model au solveur et le code accédant à .value fonctionnera tel quel.

La méthode create_instance n'est nécessaire lorsque vous démarrez à partir d'un AbstractModel, où vous passez ensuite généralement le nom d'un fichier .dat à lui.