Upgrading Julia and IJulia on Linux

This is a short note on how to swiftly update Julia and IJulia (the kernel to work with Jupyter notebooks) when a new minor version is released. The following instructions are for Linux, with the example of upgrading from version 1.1 to version 1.2.

(remark: the existing StackOverflow question “How to upgrade Julia to a new release?” is very outdated, as of September 2019, and doesn’t cover Jupyter kernels)

Step 1: dowload

Download the latest binary release: https://julialang.org/downloads/ and unpack it. For me: ~/Programmes/others/julia-1.2.0

Step 2: update $PATH

Update path to the Julia binary which is prepended to the $PATH variable in the ~/.bashrc file:

export PATH="/home/pierre/Programmes/others/julia-1.2.0/bin:$PATH"

Test in the shell command line: the julia command should now launch the new Julia REPL (at least after a shell restart).

Step 3: reinstall (and update) packages

Objective here is to reuse all the previously installed packages without the need to remember their names.

In the ~/.julia/environments directory, copy the Project.toml file from the previous version directory (ex: v1.1) and paste it in a directory named as the new version (ex: v1.2).

Now, in the Julia REPL, enter the Pkg REPL (pressing ]) and run update. If there is no new package version, there is no actual download happening. However, compiled packages like IJulia should be rebuilt.

Test: assuming that the IJulia packaged was included in Project.toml, the new Julia version should be available as a Jupyter kernel in the lab/notebook interface.

Step 4: clean up the old Jupyter kernel

In the ~/.local/share/jupyter/kernels directory, there should be at least two directories: the one for the old Jupyter kernel (ex: julia-1.1) and the one for the new kernel (ex: julia-1.2). If the old kernel is not needed, it can be removed.

Notice: the kernel directories can be found with the $jupyter kernelspec list command.

(The directory of the old Julia binary can be deleted as well.)

An open benchmark for energy management under uncertainty

Now that I'm back from SGE 2018 conference, I've put online the manuscript of my article and the slides of my presentation (in French).

“Gestion d'énergie avec entrées incertaines :
quel algorithme choisir ?
Benchmark open source sur une maison solaire”

The title in English (translation of the whole article in progress...) is:

“Energy management with uncertain inputs:
which algorithms ?
Open source benchmark based on a solar home”

Here is the model of the solar home (power flows)

solar home control bench (power flows model )

I've also a first translation of the abstract:

“Optimal management of energy systems requires strategies based on optimization algorithms. The range of tools is wide, and each tool calls on various theories (convex, dynamic, stochastic optimization...) which each require a period of appropriation ranging from a few days to several months.

It is therefore difficult for the novice energy management practitioner to
understand the main characteristics of each approach so we can compare them objectively and finally find the method or methods best suited to a given problem.

To facilitate an objective and transparent comparison, we propose an exemplary and simple energy management problem: a solar house with photovoltaic production and storage. After justifying the sizing of the system, we illustrate the benchmark by a first comparison of some energy management methods (heuristic rule, MPC and anticipatory optimization). In particular, we highlight the effect of the uncertainty of solar production on performance.

This benchmark, including the management methods described,
is open source, accessible online and multi-language (Python, Julia and Matlab).”

Access to the benchmark

The entire source code and the data (an extract from the Solar home electricity dataset by Ausgrid) is available on GitHub:

https://github.com/pierre-haessig/solarhome-control-bench/

As of now, only rather simple energy management methods are implemented, but I'd like to add some kind of stochastic MPC (once I've clarified what this really means), and later Stochastic Dynamic Programming.