Reinout van Rees’ weblog

Pygrunn: Reliable distributed task scheduling - Niels Hageman

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference )

Note: see Niels Hageman’s somewhat-related talk from 2012 . Niels works at Paylogic . Wow, the room was packed.

They discovered the normal problem of operations that took too long for the regular request/response cycle. The normal solution is to use a task queue. Some requirements:

  • Support python, as most of their code is in python.
  • It has to be super-reliable. It also needs to allow running in multiple data centers (for redundacy).
  • Ideally, a low-maintenance solution as they already have enough other work.

Option 1: celery + rabbitMQ. It is widely used and relatively easy to use. But rabbitMQ was unreliable. With alarming frequency, the two queues in the two datacenters lost sync. They also got clogged from time to time.

Option 2: celery + mysql. They already use mysql, which is an advantage. But... the combination was buggy and not-production ready.

Option 3: gearman with mysql. Python bindings were buggy and non-maintained. And you could also run one gearman bundle, so multiple datacenters was out of the window.

Option 4: do it yourself. They did this and ended up with “Taskman” (which I couldn’t find online, they’re planning on making it open source later on: they still need to add installation documentation).

The backend? They started with mysql. It is a great relational database, but it isn’t a great queue. There is a saying on the internet: Thou shalt not use thine database as a task queue. With some adjustments, like autocommit, they got it working nicely anyway.

The task server consists of a python daemon (running under supervisor) and a separate task runner. It runs in a separate process to provide isolation and resource control.

Of course, the task server needs to be integrated in the main server. The task server is written as an independent application, so how does the task finder find the python functions it needs to run? They do this via “server plugins” that define which environment variables are needed, which python path you need and which function and which version you need. All this gets applied by the task runner and subsequently it can import and run the function.

Some additional features of their task runner:

  • Tasks can report progress.
  • Tasks can be aborted.
  • Task start time can be constrained.
  • There’s exception handling.

Some of the properties of taskman: it is optimized for long running tasks. And: it is designed for reliability. Very necessary, as Paylogic is a payment processor.

It also means it is less suited when you have lots of little tasks. Running everything as a separate process is fine for longer-running processes, but it is too heavy-weight for lots of small tasks. Oh, and there’s no admin UI yet: he uses phpmysqladmin :-)

Pygrunn: ZeroMQ - Pieter Hintjens

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference)

Pieter Hintjens has quite some some experience with distributed systems. Distributed systems are, to him, about making our systems look more like the real world. The real world is distributed.

Writing distributed systems is hard. You need a big stack. The reason that we’re using http such a lot is because that was one of the first ones that is pretty simple and that we could understand. Almost everything seems to be http now.

Three comments:

  • So: the costs of such a system must be low. He really likes ZeroMQ, especially because it makes it cheap.

  • We lack a lot of knowledge. The people that can do it well are few. Ideally, the community should be bigger. We have to build the culture, build the knowledge. Zeromq is one of the first bigger open source projects that succeeded.

  • Conway’s law: an organization will build software that looks like itself. A centralized power-hungry organization will probably build centralized power-hungry software.

    So: if you want to write distributed systems stuff, your organization has to be distributed!

    Who has meetings in his company? They are bad bad bad. They’re blocking. You have to “synchronize state” and wait for agreement. A conference like pygrunn is fine: meeting people is fine. At pygrunn, there’s no state synchronization. Imagine that it were a meeting to agree on a standard editor...

In a distributed system, what you really want is participation. Open source development needs pull requests, so to say.

A question about making money from open source resulted in a rant (I don’t mean the term very negatively, here) about open source software being the only way to produce valuable software. “You might as well ask about how you can make money from a free school system”. “It is idiotic to ask the question”. And some things about people believing things because someone says it is so (like “you can only make money with ...”) without thinking themselves.

Something to emulate: our food system. None of us owns the complete food system. Nobody owns the full food system. But it works! Lots of smaller and bigger actors. And everyone had breakfast and lunch today. The system works. This kind of distributed system is an example to emulate in our open source software.

Nice comparison when asked about succesful commercial software. Gmail is a succesful example, but that’s something that grew pretty organically. Compare that with google wave or google plus: who even remembers them? Those were vision driven software. Made based on money. A failure.

Pygrunn: Orchestrating Python projects using CoreOS - Oscar Vilaplana

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference)

(Note: Oscar Vilaplana had a lot of info in his presentation and also a lot on his slides, so this summary is not as elaborate as what he told us. Wait for the video for the full version.)

“Orchestrating python”: why? He cares about reliability. You need a static application environment. Reliable deployments. Easy and reliable continuous integration. And self-healing. Nice is if it is also portable.

A common way to make scalable systems is to use microservices. You compose, mix and extend them into bigger wholes. Ideally it is “cluster-first”: also locally you test with a couple of instances. A “microservices architecture”.

Wouldn’t it be nice to take the “blue pill” and move to a different reality? One in where you have small services, each running in a separate container without a care for what occurs around it? No sysadmin stuff? And similary the smart infrastructure people only have to deal with generic containers that can’t break anything.

He did a little demo with rethinkdb and flask.

For the demo it uses coreOS: kernel + docker + etcd. CoreOS uses a read-only root filesystem and it by design doesn’t have a package manager. Journald for logging (it automatically captures the stdout). Systemd for managing processes.

etcd? It is a distributed configuration store. It has a http API.

Also: “fleet”. “systemd for services”. It starts up the containers. It coordinates accross the cluster. It will re-start containers if they die.

How do we get containers to talk to each other? They’re containerized... For that there’s “flannel”: “dhcp for containers”. Per-cluster specific subnet. Per-machine smaller subnet. The best system to run all this is Kubernetes.

Kubernetes uses “replication controllers”. The basis is a “pod”, from which multiple replicas are made, depending on the amount of instances you need.

He then showed a demo. Including a rolling update. Nice. Similarly for a rethinkdb cluster where he increased the number of nodes halfway the demo. Nice, too.

In development, it might be easy to use “nspawn” instead of docker. It is mostly the same, only less isolated (which is handy for development).

Pygrunn: Laurence de Jong - Towards a web framework for distributed apps

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference)

Laurence de Jong is a graduate student.

Everyone uses the internet. Many of the most-used sites are centralized. Centralization means control. It also gives scale advantages, like with gmail’s great spam filter.

It also has drawbacks. If the site goes down, it is really down. Another drawback is the control they have over our data and what they do with it. If you’re not paying for it, you’re the product being sold. Also: eavesdropping. Centralized data makes it easy for agencies to collect the data. And: censorship!

A better way would be decentralized websites. There are existing decentralized things like Freenet, but they’re a pain to install and the content on there is not the content you want to see... And part of it is stored on your harddisk...

See also Mealstrom, which distributes websites as torrents. A problem there is the non-existence of proper decentralized DNS: you have unreadable hashes.

A solution could be the blockchain system from bitcoin. It is called namecoin. This way, you could store secure DNS records to torrent hashes in a decentralized way.

https://github.com/HelloZeroNet/ZeroNet uses namecoin to have proper DNS addresses and to download the website via bittorrent. Not many people use it right now.

And.... the websites you download right now are all static. We want dynamic content! You can do even that with blockchains. An example is the decentralized twitter alternative http://twister.net.co/ . Mostly used by chinese people because twitter is mostly unavailable there.

There are problems, of course. Where do you store your data? Agencies can still do traffic analysis. How do you manage your private keys? Aren’t we getting browsers wars all over again? And can your mom install it (answer: no, it is too hard).

An extra problem is more technical: distributed hash tables are considered unsafe.

And... in the end, if you use hashes for everything (like every individual tweet, email and webpage), that’s a lot of hashes to store, partially locally. So it isn’t the solution, but at least it is a solution.

Pygrunn: Data acquisition with the Vlermv database - Thomas Levine

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference)

Thomas Levine wrote vlermv. A simple “kind of database” by using folders and files. Python is always a bit verbose when dealing with files, so that’s why he wrote vlermv.

Usage:

from vlermv import Vlermv
vlermv = Vlermv('/tmp/a-directory')

vlermv['filename'] = 'something'
# ^^^ This saves a python pickle with 'something' to /tmp/a-directory/filename

The advantage is that the results are always readable, even if you lose the original program.

You can choose a different serializer, for intance json instead of pickle.

You can also choose your own key_transformer. A key_transformer translates a key to a filename. Handy if you want to use a datetime or tuple as a key, for instance.

The two hard things in computer science are:

  • Cache invalidation.
  • Naming things.

Cache invalidation? Well, vlermv doesn’t do cache invalidation, so that’s easy. Naming things? Well, the name ‘vlermv’ comes from typing randomly on his (dvorak) keyboard... :-)

Testing an app that uses vlermv is easy: you can mock the entire database with a simple python dictionary.

What if vlermv is too new for you? You can use the standard library shelve module that does mostly the same, only it stores everything in one file.

A drawback of vlermv: it is quite slow.

Fancy full-featured databases are fast and nice, but do you really need all those features? If not, wouldn’t you be better served by a simple vlermv database? You might even use it as a replacement for mongodb! That one is used often only because it is so easy to start with and so easy to create a database. If you don’t have a lot of data, vlermv might be a much better fit.

Pygrunn: Python, WebRTC and You - Saúl Ibarra Corretgé

2015-05-22

Tags: pygrunn, python, django

(One of the summaries of the 2015 Pygrunn conference )

Saúl Ibarra Corretgé does telecom and VOIP stuff for his work, which is what webRTC calls legacy :-)

webRTC is Real-Time Communication for the web via simple APIs. So: voice calling, video chat, P2P file sharing without needing internal or external plugins.

Basically it is a big pile of C++ that sits in your browser. One of the implementations is http://www.webrtc.org/. Some people say that webRTC stand for Well, Everybody Better Restart Their Chrome. Because the browser support is mostly limited to chrome. There’s a plugin for IE/safari, though.

There are several javascript libraries for webRTC. They help you set up a secure connection to another person (a “RTCPeerConnection”). The connection is directly, if possible. If not, due to firewalls for instance, you can use an external server. It uses ICE, which means Interactive Connectivity Establishment (see ICE trickle which he apparently used). A way to set up the connection.

Once you have a connection, you have an RTCDataChannel. Which you can use, for instance, to send a file from one browser to another.

As a testcase, he wrote Call Roulette. The app is in python, but in the browser javascript is used as that is more-or-less the native way to do it. The “call roulette” app connects a user to a random other user. Users will send simple json requests to the app. Once the app finds two candidates, both get the other’s data to set up a subsequent webRTC connection.

He made the toy app in python 3.3 because it is new. It has websockets. And async via asyncio “because async is modern :-)”. All, nice new and shiny.

So: users connect from their browser with a websocket connection to the app. They are paired up and the webRTC connection data is send back. Very fast.

Fun: light-weight django-models-like models via https://pypi.python.org/pypi/jsonmodels/ ! Look it up.

He did a live demo with web video with someone from the audience. Worked basically like a charm.

Pygrunn: IPython and MongoDB as big data scratchpads - Jens de Smit

2015-05-22

Tags: pygrunn, python

(One of the summaries of the 2015 Pygrunn conference )

A show of hand: about half the people in the room have used mongodb and half used ipython notebooks. There’s not a lot of overlap.

Jens de Smit works for optiver, a financial company. A “high-frequency trader”, so they use a lot of data and they do a lot of calculations. They do a lot of financial transactions and they need to monitor if they made the right trades.

Trading is now almost exclusively done electronically. Waving hands and shouting on the trading floor at a stock exchange is mostly a thing of the past. Match-making between supply and demand is done centrally. It started 15 years ago. The volume of transactions really exploded. Interesting fact: the response time has gone from 300ms to just 1ms!

So... being fast is important in electronic trading. If you’re slow, you trade at the wrong prices. Trading at the wrong prices means losing money. So speed is important. Just as making the right choices.

What he had to do is to figure out how fast an order was made and wether it was a good order. Non-intrusively. So: what market event did we react to? What was the automatic trade decision (done by an algorithm)? Was it a good one? How long did it all take?

So he monitors data going in and out of their system. He couldn’t change the base system, so: log files, network data and an accounting database. Most of the data is poorly indexed. And a very low signal-to-noise ratio. And of course the logfiles aren’t all consistent. And documentation is bad.

Oh, and the data size is of course also to big to fit in memory :-)

He used mongodb. A schemaless json (well, bson, binary version of json) store. Great for messy data. Easy to use. Just put in a python dictionary, basically. The data is persisted to disk, but as long as you have enough RAM, it’ll keep it in memory. Very fast that way. You get indexes and speedups by default.

After he managed to get everything into mongodb, he had to make sense of things. So: correlate decision logs to network data. This is easy for humans to spot, but hard for computers. Computers are good at exact matches, humans are better at inexact pattern matches.

He used ipython notebook, a nice interactive python shell with a browser interface. Including matplotlib integration for easy graphs. Syntax highlighting; you can render html inside the shell; you can save your work at the end of the day (which you can’t with a regular python shell!); inline editing.

Nice: since last week, rendering such notebooks is supported by github. (I guess he means this announcement ).

Now mongodb. It is very simple to create a directory and start mongodb. If you stop mongo and delete the directory, it is gone as if it was never there. Easy. And with pymongo it is just a few lines of python code and you’re set. Including a handy query language.

He showed a couple of code examples. Looked pretty handy.

Creating an index is a oneliner. If you know beforehand what kinds of queries you want to do, you can quickly create an index for it, which speeds up your queries a lot. You can make complex indexes, but in his experience, simple single-field indexes are often enough.

Something to watch out for: mongo does never return disk space to the OS. If you delete lots of objects, the OS doesn’t get it back unless you shut mongodb down and “repair” the database. What he does is simply delete the database at the end of the day!

He showed one of the outputs: a graph with response times which immediately showed that several responses were too slow. Good, useful information. One year ago he wouldn’t have dreamt of being able to do this sort of analysis.

Mongo is very useful for this kind of work. You use mongodb’s strengths and you aren’t bothered by many of the drawbacks, like missing transactions.

Pygrunn: Leveraging procedural knowledge - K Rain Leander

2015-05-22

Tags: pygrunn, python, django

(One of the summaries of the 2015 Pygrunn conference )

K Rain Leander works at Red Hat and yes, she wore a bright red hat :-) She’s a python and django newbie. She knows how it is to be a newbie: there is so much in linux that there are always areas where you’re a complete newbie. So everyone is helpful there.

“Amsterdam is the capital of the netherlands” is declarative knowledge. Procedural knowledge is things like learning to ride a bike or a knew language. So: What versus How. You might know declaratively how to swim, but procedurally you might still drown: you need to practice and try.

Some background: she was a dancer in the USA. Unless you’re famous, you barely scrape by financially. So she started teaching herself new languages. Both real-life languages and computer languages. Css, html for starters. And she kept learning.

She got a job at Red Hat. You have to pass a RHCE certification test within 90 days of starting work there - or you’re fired. She made it. She

She has military background. In bootcamp, the purpose is not the pushups and the long runs. The goal is to break you down so that you jump when they say “jump”.

In the Red Hat bootcamp, the goal is not making the test. The goal is to figure out if you’re able to drink from the firehose. Which means if you get a support request, you say “I’ll figure it out for you” and you just dive in and try to figure it out. You have to be able to dive into a whole lot of new information without panicking. That’s drinking from the firehose.

She re-used existing knowledge and previous skills to learn everything. The important part was not being afraid to dive in.

She moved towards programming. Python, django. She was new to it. One of the first steps? “Set up a virtualenv and....”. It can frighten you, but it is just a question of RTFM. Just read the manual. Just read it and then start doing it.

She went to a Django Girls Workshop. (One of the results: http://leanderthalblog.herokuapp.com/). Django girls does a really good job of providing material and documentation. She had some problems installing it, but continued (and succeeded) anyway.

... and then someone challenged her to deploy it on openshift. http://django-leanderthal.rhcloud.com/ It hasn’t succeeded completely yet. But she’ll persevere and get it working.

She recommends http://learnpythonthehardway.org/ to learn python.

What’s next: she’ll practice, practice, practice. And she’ll contribute to the community. Probably build one or two apps. And she’ll be a coach at the upcoming Groningen django girls workshop (“as a coach. No, I’m not worried....”)

So: re-use your existing knowledge and build from there. Don’t be afraid. Just do it.

3Di symposium (NL), tweede ochtendsessies

2015-04-16

Tags: nelenschuurmans

Note beforehand in English: this’ll be one of the rare Dutch entries :-)

Zie ook de samenvattingen van de eerste ochtendsessies.

It is the image that counts - Elmar Eisemann

Elmar is professor computer graphics aan de TU Delft. Door goede, niet van echt te onderscheiden, 3D visualisaties kan je mensen vaak veel beter zaken duidelijk maken dan door een grafiekje of een 2D plaatje.

De uitdaging bij 3Di is dat het zo veel data is. Voor de 3Di visualisatie gebruiken ze de AHN2 met kleurinformatie. Dat is 8 terabyte. Als je het op CDs zou zetten zou je een stapel van 20 meter hoog krijgen! Dus als je alles op het kleinste detailniveau wilt tonen lukt dat niet met normale computers.

De oplossing hiervoor is om de detailleringsgraad aan te passen. Iets dat ver af ligt hoeft minder gedetailleerd te zijn. Ook kan je simplificeren en combineren.

Naast de visualisatie zelf moet er ook aan de data zelf gewerkt worden. De beschikbare data heeft normaliter gaten omdat de meeste kleurinfo van boven opgenomen wordt, dus zijkanten van gebouwen zijn een probleem. Dit kunnen ze verhelpen door allerlei berekeningen op de data los te laten.

Ze kijken ook naar integratie van real-time informatie in de 3D visualisatie, zoals regenval en twitter berichten over wateroverlast. Door dit soort informatie in 3D te tonen kan je beter en makkelijker samenwerken als, bijvoorbeeld, hulpdiensten.

Ze doen hiervoor ook onderzoek naar het gezamelijk beslissingnemen. Zaken zoals schetsen in google maps met een mogelijke oplossing (“als we in dit gebied nou xyz doen...”) wat dan tegelijkertijd gedeeld wordt met de andere deelnemers. In 3D. Wat ook handig is om op meerdere beeldschermen en apparaten naar hetzelfde plaatje te kijken, bestuurd door 1 van de apparaten.

Veel onderzoek doen ze ook naar de eigenlijke 3d visualisatie. Bij de eerste 3d bioscoopfilms kreeg je koppijn omdat je hersens kijken naar het scherm en objecten zien die ervoor zitten. Dat klopt niet met elkaar en daarvan krijg je koppijn. De tweede generatie 3D films bleef qua 3D dicht bij het scherm, in de “comfort zone”, maar daar was het effect dus heel beperkt.

Bij de TU Delft houden ze rekening met allerlei manieren waarop je hersenen met je ogen omgaan. Optische illusies, maar dan gebruikt om iets meer 3D te maken zonder aparte apparatuur. Of om luchtfoto’s duidelijker en herkenbaarder te maken door hogere gebouwen wat extra schuin te zetten.

“Augmented reality”: dit kan zo simpel zijn als het tonen van labels (plaatsen, straatnamen) in een 3D visualisatie. Maar het helpt wel veel en geeft veel duidelijkheid.

Waar ook nog veel meer mee kan: de community inschakelen. Hulp bij verzamelen van gedetailleerde gebouwmodellen, bijvoorbeeld.

In al dit onderzoek zit ook veel potentie voor 3Di! Een deel wordt al gebruikt en daarnaast zijn er veel prototypes en leuke testen.

Onderschat trouwens niet hoe snel het allemaal kan gaan! 30 jaar geleden was een computerspelletje een monochroom 2D plaatje van 100x100 pixels. Nu heb je vrijwel fotorealistische real-time 3D spelletjes!

Aan de wind rekenen - Guus Stelling

Guus (professor TU Delft; Stelling Hydraulics) is de grondlegger van 3Di.

Hij breekt als eerste een lans voor het snel gebruiken van innovaties zoals 3Di. Toen de stoommachine nauwelijks was uitgevonden keken er al heel snel mensen naar die uitvinding om te kijken of het Haarlemmermeer ermee drooggemaakt kon worden. Dus... als je een positie hebt om het te doen: zorg dat 3Di gebruikt gaat worden!

Op aarde hebben we 1.360.000.000 kubieke kilometer water! Ruim 90% daarvan zit in de oceanen.

Prachtverhaal, maar grotendeels niet samen te vatten. Als het goed is komt er een video van. Dat wordt bij deze alvast een aanrader!

Enfin, ze zijn nu bezig om de wind in de 3Di modellen mee te nemen. Dan komen er allerlei complicaties langszetten. Hoe dunner het waterlaagje, hoe groter het effect van de wind wordt. En hoe lastiger de berekeningen worden.

Hij laat een paar voorbeelden zien, onder andere de reden voor maalstromen bij de kust. Leuk!

Als laatste liet hij een simulatie los op... de doortocht van de zee van Mozes. Een echte locatie was niet makkelijk te vinden en dus gebruikte hij het als voorbeeld voor het belang van details. Hij zette wind op een bak met water met een dijkje in het midden, in twee varianten, eentje met een rechte wand en eentje met een schuin talud. Het verschil in eindresultaat was opvallend en toonde daarmee aan dat de gedetailleerdheid van het onderliggende model van groot belang is.

Slotopmerking: “3Di is een imperfect model. Maar ik ken geen model dat perfecter is!” Modelleren is toch een beetje als een artiest: met een enkele verfstreek moet je soms de essentie vastleggen.

3Di in Afrika - Stefan Nijwening

Stefan (Rebel groep) werkt aan projecten in Afrika om samen met grote bedrijven, zoals brouwerijen en industrie, die water nodig hebben, te kijken naar waterproblematiek.

Hij haalt een project terug van 8 jaar geleden in Ho Chi Mihn City. Het maken van een overstromingsmodel duurde daar te lang om echt in de praktijk te gebruiken. Wat had hij graag 3Di toen al gehad, dat had veel opgeleverd.

Langzamerhand beginnen ook bedrijven en economen naar water te kijken en het als een groot toekomstrisico te zien. Economen en bedrijven kijken toch anders er naar dan overheden. Ze kijken wat er met hun geld gebeurd. Met hun investeringen. Of er extra geld uit investeringen gehaald kan worden (waterveiligheid door een dam en dan ook nog eens stroom opwekken, bijvoorbeeld). En dan economisch afwegen van allerlei varianten.

3Di, met een touch table bijvoorbeeld, maakt water allemaal veel inzichtelijker, ook voor economen die geen vakinhoudelijke kennis ervan hebben. Je kan het zien. En je kan maatregelen simuleren en het effect ervan gelijk zien.

Een uitdaging is om de verschillende stakeholders bij elkaar te krijgen. Het hebben van een 3Di touch table kan dan helpen. Zelf hebben ze ook een dashboard gemaakt waarmee tekstueel allerlei scenario’s met elkaar vergeleken kunnen worden.

Er zit geld in water risico’s! Je kan namelijk veel geld besparen door er goed mee om te gaan.

Hoe exporteer je water - Tineke Huizinga

Tineke, voormalig staatssecretaris, is nu voorzitter van de delta alliance international governing board.

De Delta Alliance is een kennis-netwerkorganisatie. 16 landen zijn aangesloten die allemaal specifieke delta’s vertegenwoordigen. Het is een Nederlands initiatief. Het doel is om de resilliance, de veerkrachtigheid, van de delta’s te vergroten. Dit doen ze door kennisdeling, informatie verzamelen en het ontwikkelen van het kennisnetwerk door verbeteren van het onderlinge contact van de deelnemende kennisinstituten.

Soms kan het vrij eenvoudig zijn. Zo hebben ze toolboxen met instructies voor het maken van bepaalde kaarten, bijvoorbeeld.

Er zit ook een Nederlands karakter in door de nadruk op aanpasbaarheid. Net zoals het deltaprogramma op een tijdsschaal van 50 of 100 jaar kijkt en accepteert dat niet alles 100% duidelijk is. En dat het beleid en de maatregelen dus aangepast moeten (kunnen) worden. En dat het dus verder kijkt dan een 4 jaar, bijvoorbeeld, van een bepaalde regering. Zo’n lange termijn aanpak is in veel gebieden onbekend.

We hebben het als Nederland opgezet uit de overtuiging dat we de wereld echt iets te bieden hebben met onze waterkennis. We lopen voor op de rest van de wereld! Wel is het doel van de delta alliance om de wereldwijde waterkennis bij elkaar te brengen, te delen. Het is zeker niet de bedoeling alleen te “zenden”.

Als delta alliance zouden ze 3Di erg graag op willen nemen in hun toolboxen.

3Di symposium (NL), eerste ochtendsessies

2015-04-16

Tags: nelenschuurmans

(Note beforehand in English: this’ll be one of the rare Dutch entries :-) )

Het 3Di symposium werd, net als vorig jaar, in het prachtige spoorwegmuseum in Utrecht gehouden.

3Di is nu een onafhankelijke stichting. Waarom? Om het te borgen; de verschillende ontwikkelingen worden er in ondergebracht. 3Di is een samenwerking tussen partijen met verschillende achtergronden. Deltares is meer een “braaf” onderzoeksinstituut en mede-ontwikkelaar Nelen&Schuurmans is meer een “dynamische en minder brave” commerciele marktpartij. En dan zijn er de TU Delft en de launching customers. De keus voor een brave stichting was de beste mogelijkheid

Ervaring van het afgelopen jaar - Michiel van Haaersma Buma en Luc Kohsiek

Vorig jaar waren ze blij dat het allemaal werkte. In een jaar tijd is er veel gebeurd. Luc (dijkgraaf HHNK) noemt vier opvallende punten

  • De stichting is opgericht. Best een grote stap!
  • De medewerkers moeten ermee leren werken en ermee kunnen werken.
  • 3Di werkt erg gedetailleerd, dus opeens kom je er achter dat de interne informatie niet op orde is: veel missende duikers en kleine sluisjes, bijvoorbeeld.
  • De innovatie is niet gestopt. De riolering die nu aan 3Di toe gevoegd wordt is geweldig.

Michiel (dijkgraaf Delfland) voegt toe dat ze 3Di vrij uitgebreid in de hele organisatie heeft uitgerold. Daarmee kom je wel achter wat ruwe randjes, maar dat is te verwachten als je rechtstreeks uit het labaratorium naar de praktijk gaat. Ze hebben de lat hoog gelegd. Ook politiek wordt er flink op gelet.

Luc laat een 3Di demo zien van Texel. Een dijkbreuk die Den Burgh bedreigt. Een oude stroomgeul wordt gebruikt om het water zoveel mogelijk af te leiden richting een polder. Als simulatie wordt daarvoor een dijk doorgestoken. Aan het eind worden er berekende plaatjes getoond met daarop hoe lang het duurt voordat het water op een plek is. En ook tot wanneer de wegen nog bruikbaar zijn voor evacuaties. Dit biedt inzicht!

Michiel zegt dat Delfland, dat vroeger een open gebied was, eigenlijk een grote stad is geworden. Hij toont een plaatje waar ook de kassen als bebouwing is meegenomen en dan is het inderdaad voor het grootste deel bebouwd. In het 3Di model hebben ze inmiddels zowel de riolering als het oppervlaktewater gemodelleerd, ze zijn nu bezig het aan elkaar te knopen.

Voor onderling overleg met andere instanties gaan ze richting wat ze een “digitale watertafel” noemen. Gezamelijk als het ware “rond de informatie gaat zitten” en overleggen. Hiervoor kunnen ze 3Di gaan gebruiken. Je hebt dan alle informatie bij elkaar en omdat het visueel is wordt alles veel duidelijker voor alle partijen. Je kan dan letterlijk rond de informatie gaan zitten! Je krijgt meer inzicht en je kan goed laten zien wat het effect is van mogelijke maatregelen (of het nalaten van die maatregelen).

De dagvoorzitter vroeg wat nou het nut van 3Di was. Mooie plaatjes, maar is het niet allemaal al bekend? Twee antwoorden:

  • Je kan veel sneller rekenen als er een calamiteit is. Vroeger moest je een paar weken op je berekening wachten, nu kan je gelijk kijken.
  • Het is veel gedetailleerder dan wat er tot nu toe beschikbaar is. In grove zin weet je wel welke polder onder gaat lopen, natuurlijk. Maar dan neem je ook grove maatregelen. Nu is het allemaal veel nauwkeuriger en gedetailleerder en kan je ook betere en subtielere maatregelen nemen.

Wat kan de specialist zonder hightech instrument - Joost Buntsma

Joost (directeur STOWA) komt met een persoonlijk verhaal. 28 juli 2014 zat hij onder een blauwe hemel en in een lekker zonnetje op een camping in een afgelegen hoek van Wales. Ondanks de slechte mobiele dekking kwam er opeens een SMS met “Pap, man, bellen! Nu!”. Oei, wat is er aan de hand?

Met moeite konden ze verbinding krijgen en wat foto’s binnenhalen van nat parket en een borrelend toilet en een ondergelopen garage. Een enorme regenbui zorgde dat de riolering in het laaggelegen gedeelte overstroomde en de straten blank stonden in Heemskerk, zijn woonplaats. Elders was er ook wat aan de hand. Kockengen liep onder, in Alphen a/d Rijn liep een boezem over en in Amsterdam was er ook overlast.

Hij liet een sheet zien met als titel “van primair naar secundair en tertiair”. Hij komt oorspronkelijk van rijkswaterstaat en daar waren ze vooral bezig met de grote overstromingsrisico’s van het falen van een hoofddijk. Daar waren wel overstromingsberekeningen voor, maar vrij grofmazig.

De waterschappen, waar hij via STOWA nu voor werkt, gaat het om de secundaire keringen en dan moet het fijnmaziger zijn dan voor rijkswaterstaat. De tertiaire overlast gaat over overstromende riolen enzo, en daarvoor moet je als waterschap nog veel gedetailleerder werken. Dit kan nauwelijks zonder 3Di.

De stijl van nu gaat ook veel meer van gezag (de overheid of het waterschap vertelt wat er gaat gebeuren) naar participatie (we kijken samen wat er aan de hand is en wat we eraan kunnen doen). 3Di is daar goed voor. Ook ga je dan van een tekstueel rapport naar een visueel instrument.

3Di helpt ook om met modellen een stap verder te gaan: van de beleidsfase richting het veel dynamischer beheer en ook voor bij calamiteiten.

Veilige innovaties - Erik Kraaij

Erik (plv programmadirecteur HWBP, hoogwaterbeschermingsprogramma) heeft het over “vat op veiligheid: wat kan en wil HWBP met 3Di”. Het HWBP is het jaarlijkse programma van dijkversterkingen van de waterschappen en rijkswaterstaat. 748km dijk voldoet op het moment niet aan de wettelijke norm. En ook nog eens 275 kunstwerken. De komende decennia zijn er zo’n 186 projecten. Het is het grootste waterprogramma. Het is erg ruimtelijk georienteerd en het moet ook passen in bijvoorbeeld het deltaprogramma.

Het is een groot project waar veel geld in om gaat, maar er moet ook heel veel gebeuren. En er is een kritische omgeving met veel wensen. Per project moet er dus breed gekeken worden: veel zaken meenemen en veel wensen verzamelen en voldoende overleggen.

Een extra doel is dat innovaties worden gestimuleerd en toegepast. En samenwerking moet intensief zijn: RWS heeft bijvoorbeeld veel kennis van nieuwe contractvormen en waterschappen hebben juist weer de gebiedskennis.

Op dit moment, in de opstartfase van dit project, wordt een kwart van het budget besteed aan innovatie. Dat vinden ze belangrijk.

En wat is dan de rol en meerwaarde van 3Di voor HWBP?

  • In projecten kan 3Di goed laten zien (=inzichtelijk maken) waar een dijk niet goed genoeg is en wat het effect is. Dit zorgt voor meer draagvlak.
  • Je kan kijken naar alternatieve oplossingen. Meekoppelen andere belangen. Afwegingen maken.
  • Het is erg handig voor communicatie, voorlichting en bij inspraak.

De vraag die er dan ligt is of je per project naar 3Di kijkt of dat je het samen als programma oppakt. De projecten zijn van de waterschappen, dus daar ligt de sleutel. Zelf vindt hij dat dit soort zaken beter gezamelijk opgepakt kunnen worden.

3Di: waar ligt die dijk? Wat is er aan de hand? Wat gaat er gebeuren? En... wat betekent dit voor mij, mijn huis en mijn veiligheid?

 
vanrees.org logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):