4
$\begingroup$

The question is a bit self explanatory I believe, but just to give a simple example (this is not the entire model of course):

model = AbstractModel()
model.i = Set()
model.j = Set(initialize=model.i)
model.R = Param(model.i)

def lowband(model,i):
    return (model.R[i],100)
model.x = Var(model.i, bounds=lowband, within=NonNegativeReals, initialize=0)
model.y = Var(model.i, bounds=lowband, within=NonNegativeReals, initialize=0)
model.W = Var( bounds=(0,100), within=NonNegativeReals, initialize=0)
model.L = Var( bounds=(0,100), within=NonNegativeReals, initialize=0)

def rule_eq1(model,i,j):
    if i>j:
        return (model.x[i]-model.x[j])**2+(model.y[i]-model.y[j])**2 >=(model.R[i]+model.R[j])**2
    else:
        return Constraint.Skip;
model.eq1 = Constraint(model.i,model.j,rule=rule_eq1)

I get really annoyed by the variable and parameter names in the constraint declarations because of the model. part. If after each declaration we do something like:

x = model.x
y = model.y

and so on and use "x" and "y" instead of the original name, it works just fine too. However, the vast majority of pyomo models I see on the internet follow that approach of always using model.. Is there any good reason for doing this and that I still haven't realised? I think it makes the code writing process worse and it also gets harder to read the code

$\endgroup$
3
  • 1
    $\begingroup$ Agreed. Similar to the "self.blah" in python or the "this.blah" in javascript. Especially in formulas it reduces readability $\endgroup$ Sep 12, 2021 at 22:05
  • $\begingroup$ I understand you are new to Python. $\endgroup$ Sep 14, 2021 at 4:00
  • $\begingroup$ OR-community-discord-server: discord.gg/k5AtFccjne join us to get a bigger live-community. $\endgroup$
    – Eddiee
    Sep 20, 2021 at 21:27

1 Answer 1

1
$\begingroup$

When you say model.x then you know that this x is a part of the model but

if you see model.x-X==2 what can you say about the X ? is it a constant ? constant in the model ? var in the model ?

This also applies to naming the variables if you use model.i it works alternatively, if you use model.generators it works as well! but in the second case it is more clear and easier to understand

$\endgroup$
1
  • 1
    $\begingroup$ But isn't that issue present anyways even if we keep using "model."? In the example above, we have model.x and model.R, a variable and a parameter, respectively. The "model." adds no extra information here $\endgroup$
    – epilefst
    Sep 13, 2021 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.