
The Emergent Features of JuliaLang: Part II – Traits - eperim
https://invenia.github.io/blog/2019/11/06/julialang-features-part-2/
======
7thaccount
Interesting to see this here as I've seen Invenia post on the Julia subreddit
from time to time.

Can anyone from Invenia explain how they make money or what they're trying to
do? I work with electricity market optimization every day (main topic listed
on their blog and site) and am curious what they're trying to bring to the
table. There are already lots of vendors in this area (ABB, Siemens, GE) that
use the state of the art MIP/LP solvers to run the US grid (what CAISO, PJM,
SPP, MISO, NYISO, ISO-NE, and ERCOT all do). On the retail side (think DER
aggregators) I know SolarCity is trying to get into that game.

Julia is a great numerical language and it has a good solver agnostic library,
but rewriting stuff in Julia won't get you much of a gain in this market. You
mention machine learning which has several use cases for the grid, but I don't
see a product or a mention of Invenia working with any utilities, ISOs, or
vendors.

Btw: I hope I don't come across as negative (I wish you the best of luck). I
do see a lot of companies do things like try to sell block chain to utilities
without them even knowing what kinds of problems they have.

~~~
oxinabox
Invenia has been interested in electricity grids since 2006 and has provided
many kinds of services to interested parties, for example load forecasts. We
are continuing to work on many things in the area. Recently we published some
of our blue sky research on grid optimization using modern machine learning
ideas
([https://www.climatechange.ai/CameraReady/43/CameraReadySubmi...](https://www.climatechange.ai/CameraReady/43/CameraReadySubmission/icml_invenia_cameraready.pdf)).

~~~
7thaccount
Load forecasting is a reasonable thing. There are already enough vendors for
that to where I wouldn't focus in that area personally, but if it is working
for you, then that is good.

I read your linked paper last night and I'm not 100% sure what to make of it.
If I understood it (big assumption :)) it seems like the intent is to use
heuristics (Ex: particle swarm optimization) to seed a warm start for a
nonlinear solver for the ACOPF problem? Is that right? Although the nonlinear
ACOPF problem is academically interesting, the industry is using every last
ounce of performance from the best MIP solvers (CPLEX & GUROBI) for the DCOPF
unit commitment problem.

The 5-minute economic dispatch problem only takes a few seconds as it is
formulated as a LP problem, however, the unit commitment process is a MIP
problem though and I don't think the nonlinear solvers will have anywhere near
the performance we need even with a warm start.

There is some interesting work being done on ACOPF (ARPA-E competition project
that ASU is heading up).

------
adamnemecek
Part I [https://invenia.github.io/blog/2019/10/30/julialang-
features...](https://invenia.github.io/blog/2019/10/30/julialang-features-
part-1/)

~~~
renox
I like the convenient unit syntax, if this works well with
IntervalArithmetic.jl, julia can become a competitor to Frink
[https://frinklang.org/](https://frinklang.org/)

~~~
eigenspace
Here's an example of them working together rather effortlessly:

    
    
        using Unitful, IntervalArithmetic
        const m = u"m"
        const k = 2π/10m
    
        f(x) = cos(k * x)/(k^2 - 1/x^2)
    
        julia> f((10.0 ± 0.1)m)
        [2.5924, 2.60024] m^2
    

If I try to put in a dimensionally incorrect argument to f, I get an error:

    
    
        julia> f((10 ± 0.01)u"s")
        ERROR: MethodError: no method matching cos(::Quantity{Interval{Float64},𝐓*𝐋^-1,Unitful.FreeUnits{(m^-1, s),𝐓*𝐋^-1,nothing}})
        Closest candidates are:
          cos(::Float16) at math.jl:1085
          cos(::Complex{Float16}) at math.jl:1086
          cos(::Missing) at math.jl:1138
          ...
    

This isn't the most friendly error message in the world, but that can
certainly be worked on and with a bit of patience it's pretty clear that it's
saying that the problem was that it tried to compute the cosine of a unitful
quantity which is nonsense.

_____________________________________

Unfortunately I had to use unitful intervals (i.e. (10.0 ± 0.1)m) instead of
intervals of uniful quantities (i.e. 10.0m ± 0.1m) because
IntervalArithmetic.jl demands that it takes real quantities, but Unitful
quantities are subtypes of Number instead of Real.

~~~
eigenspace
Just as a followup, I just realized that the Measurements.jl package _does_
know how to deal with non-real uncertainties, so one can instead do

    
    
        using Unitful, Measurements
        const m = u"m"
        const k = 2π/10m
    
        f(x) = cos(k * x)/(k^2 - 1/x^2)
    
        julia> f(10.0m ± 0.1m)
        (2.5989 ± 0.0014) - (0.0 ± 0.16)im m^2

------
npr11
Really useful examples; especially the data in rows versus columns example :)

------
blufish
Congrats lyndon we went to uni together dope

