illwerke vkw | F# data engineer / backend developer | Bregenz (AT) or remote in AT/DE | fulltime

illwerke vkw is a hydropower focused utility in western Austria. The position requires fluent German. The position is within a math-heavy team working on power plant scheduling and energy trading algorithms in F#.

- Official link: https://jobs.illwerkevkw.at/Vacancies/1215/Description/1

There is a limit, but it is rather high. The big constraint is the steel cladding of the shafts --- those nearly vertical tunnels are all "armored", because normal rock would not resist the pressure. The company I work for has plants with 800m ~ 2400 feet height difference running, I know of slightly higher ones in the French/Swiss Alps. Up to 1km is doable with current engineering.

- Cplex and Gurobi, sometimes some open source ones.

- Energy modelling: the core models for one timestep are small (ca 1-2k variables), but together with long timescales/stochastic programming the model formulation blows up (easily by a factor of 10-40k).

- Mostly LP-relaxations of MILPs with manual cuts. MILPs themselves take often too long.

- The solvers are ok:

  - There is a nice theory around LPs and MILP is understandable. So in principle, I trea them as black boxes.

  - API: Similar enough between solvers because of nice formalism of MILP. Generic APIs on most platforms (pyomo, jump, ..). Beware magical helpers.

  - Performance: For LP predictable. For MILP -- tune it. It becomes tricky when tuning solvers/staying solver-independent without sacrificing performance. Metaheuristics to the rescue. Open source solvers have a harder time here.

- The big problem is the modelling and context part: translating the problem into am MP formulation, ensuring correctness of units/scales, generation of apis and docs ... once you do it by hand, but if you want to run a modeling loop or support multiple models (variants, optimisations, special cases), then this ist most of the effort (and costs human time, instead of computing time).