Add support for modeling with SI units

[chriscoey]

Something that has been mentioned before in passing and might be worth discussing down the track: allow modeling with SI units using https://github.com/ajkeller34/Unitful.jl. It may be fairly trivial, I'm not sure.

DifferentialEquations.jl seems to allow this, for example here.

GPKit is a geometric programming toolkit in Python and it supports specification of units and automatically does dimensional analysis to convert or verify units in expressions/constraints. From the GPKit docs, an example of a variable declaration:

# Declare a variable, z, with units of meters, and a description
z = Variable("z", "m", "A variable called z with units of meters")

and a simple model:

# consider a block with dimensions x, y, z less than 1
# constrain surface area less than 1.0 m^2
x = Variable("x", "m")
y = Variable("y", "m")
z = Variable("z", "m")
S = Variable("S", 1.0, "m^2")
c = (2*x*y + 2*x*z + 2*y*z <= S)

(There are other ideas we could borrow from GPKit to make JuMP even more user friendly. I like the little solution tables it can print after a solve.)

[blegat]

You can do this by extending the @variable macro as follows

using JuMP
using Unitful
m = Model()
function unitvar(vref::JuMP.VariableRef, u::Unitful.FreeUnits)
    JuMP.GenericAffExpr(0.0 * u, vref => 1.0 * u)
end
struct Unit
    u::Unitful.FreeUnits
end
struct UnitVariable <: JuMP.AbstractVariable
    v::JuMP.ScalarVariable
    u::Unitful.FreeUnits
end
function JuMP.buildvariable(_error::Function, info::JuMP.VariableInfo, u::Unit)
    UnitVariable(JuMP.ScalarVariable(info), u.u)
end
function JuMP.addvariable(m::Model, v::UnitVariable, name::String="")
    vref = JuMP.addvariable(m, v.v, name)
    # add bridge to `m.moibackend` if its does not support constraints with Unitful coefficients
    unitvar(vref, v.u)
end
@variable m v Unit(u"m")
@show v + 2v + 1u"m" # -> 3.0 m v + 1.0 m

To support adding constraints such as @constraint m 2v + 1 <= 2 , you can simply create a constraint bridge that transforms constraints with functions of Unitful coefficient type to constraints where the coefficients are the values of the unitful quantities (note that you need jump-dev/MathOptInterface.jl#397 to be is fixed for it to work with JuMP in non-Direct mode though).

Both the new constraint bridge and the @variable macro extension would fit nicely into a JuMP extension.
The extension would work nicely with other extension since you don't need to define a new model constructor or define a solvehook.

By the way this could be a nice example for the extensions doc don't you think ?

[odow]

By the way this could be a nice example for the extensions doc don't you think ?

Yes. This is ridiculous. Hooray for a good abstraction.

[IainNZ]

Could be fun to try with https://github.com/IainNZ/RationalSimplex.jl too.

[odow]

Pyomo has this: https://pyomo.readthedocs.io/en/stable/advanced_topics/units_container.html

It came up yesterday in a discussion with @zolanaj. It's particularly useful if you have a large model with lots of different physical units, and you want to avoid issues like adding meters and millimeters.

[trulsf]

I have been playing around with the above ideas to combine JuMP and Unitful. My primary goal was to use units in combination with the @variable and @constraint macros for linear constraints. I started out with the approach suggested by @blegat, but I found it hard to play nicely with the @rewrite macro. Instead I have tried an approach where constraints are handled similar to variables and are bundled with a unit. Being a fairly newcomer to both Julia and JuMP, I have not made a deep dive into the details of MutableArithmetics, and have only implemented limited support for the interface for expressions involving units.

I have made a proof-of-concept package: https://github.com/trulsf/UnitJuMP.jl

It runs on simple examples, but is in no way robust or complete. I would be grateful if anyone with a better grasp of JuMP and its inner workings, could comment upon the overall approach. Is it a viable way of approaching the problem? Or would it be better approach to change JuMP to better accomodate units in GenericAffExpr?

Here is a simple example of its usage:

using UnitJuMP, GLPK

m = Model(GLPK.Optimizer)

@variable(m, x >= 0, u"m/s")
@variable(m, y >= 0, u"ft/s")

max_speed = 60u"km/hr"

@constraint(m, x + y <= max_speed)
@constraint(m, x <= 0.5y)
obj = @objective(m, Max, x + y)

optimize!(m)

println("x = $(value(x))  y = $(value(y))")

#output x = 5.555555555555556 m s^-1  y = 36.45377661125693 ft s^-1

[odow]

Nice! I'm traveling for the next week, but I will take a look when I get a chance. If it's been 2 weeks and I haven't replied, please ping me as a reminder.

…

On Thu, 13 Jan 2022, 8:52 AM Truls Flatberg, ***@***.***> wrote: I have been playing around with the above ideas to combine JuMP and Unitful. My primary goal was to use units in combination with the @variable and @constraint macros for linear constraints. I started out with the approach suggested by @blegat <https://github.com/blegat>, but I found it hard to play nicely with the @rewrite macro. Instead I have tried an approach where constraints are handled similar to variables and are bundled with a unit. Being a fairly newcomer to both Julia and JuMP, I have not made a deep dive into the details of MutableArithmetics, and have only implemented limited support for the interface for expressions involving units. I have made a proof-of-concept package: https://github.com/trulsf/UnitJuMP.jl It runs on simple examples, but is in no way robust or complete. I would be grateful if anyone with a better grasp of JuMP and its inner workings, could comment upon the overall approach. Is it a viable way of approaching the problem? Or would it be better approach to change JuMP to better accomodate units in GenericAffExpr? Here is a simple example of its usage: using UnitJuMP, GLPK m = Model(GLPK.Optimizer) @variable(m, x >= 0, ***@***.***(m, y >= 0, u"ft/s") max_speed = 60u"km/hr" @constraint(m, x + y <= ***@***.***(m, x <= 0.5y) obj = @objective(m, Max, x + y) optimize!(m) println("x = $(value(x)) y = $(value(y))") #output x = 5.555555555555556 m s^-1 y = 36.45377661125693 ft s^-1 — Reply to this email directly, view it on GitHub <#1350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6MQJK4YPNENDDDFQNSZKTUVXLZLANCNFSM4FFTAHUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: <jump-dev/JuMP. ***@***.***>