I'm building epanet-js[0], a local-first web application for simulating water network.
The goal is to replace clunky, expensive enterprise desktop tools (which often charge $10k+ for a wrapped version of the open-source US EPA engine). We want our version to be frictionless: login optional, runs entirely in the browser, and saves files locally to your device.
We are using the Functional Source License (FSL) to keep it sustainable while remaining open.
The GIS system is generally the base for a hydraulic model. You use that data to build a connected graph structure that the hydraulic engine, EPANET, uses to run calculations to figure out the pressure at the nodes and also flow rates in pipes.
There is also a water quality component where you can calculate the age of water in the system or chemical, such as chlorine, or other by-products you may or may not want in the system.
The US EPA site goes into technical details on what the engine can do [0], but the vast majority of modeling is done as part of a water master plan for a water utility.
A water utility will build a hydraulic model of their network and calculate and model the growth of their city over a 30-year period. The model will highlight areas of concern, generally low pressure, and the water utility can propose new infrastructure like larger pipes, tanks, or pumps, and will schedule future capital works to keep service levels acceptable.
They generally repeat this process every 3–5 years, rebuilding the model and rewriting their master plans. Here is an example of a master plan by the City of Kyle [1].
Generally, a water utility is proposing tens of millions of capital works, if not more. So traditionally, the high price tag has just been accepted. But obviously, this doesn't scale down to smaller utilities, and normally consultants will do the work on their behalf, including holding the right software license.
Currently the two largest vendors of hydraulic modelling software are Autodesk and Bentley. Both have taken the EPANET engine and created private forks in the 90s/2000s and never contributed back.
The commercial tools have made it easier for engineers at consultancies and utilities to build hydraulic models by integrating GIS and providing support for scenarios to compare different states of the model or future developments of a city.
Though as Tom points out, this comes at a huge price.
The US EPA does offer a simple GUI which can be used for smaller systems but without a connection to GIS, its usage has been limited.
These commercial versions have become enterprise monsters, they are very complex and expensive.
We wanted to create the right balance between what the US EPA already gives away for free and what the big vendors offer. We believe that releasing the software as FSL which transitions to MIT gives us the right head start and for the advanced features we're charging about 10% of what Autodesk and Bentley do - and for those that think that's too much, they of course can download and host their own private version too.
For those that are still curious, here are some extra links and context.
We created this from a fork of Placemark[0] to give water utilities an alternative choice to the big players, Autodesk and Bentley.
The majority of commercial modeling software uses the U.S. EPA's engine and adds a nicer interface. They all fork the engine to add enhancements but don't contribute back.
This is our attempt to create an open-source alternative for water engineers and contribute back to the core engine at the same time.
I’m building a local-first web app, and SQLite works well for my case since a single project can be contained in one database file, just like users are used to with existing desktop applications.
What I’d really like is an easy way to sync the SQLite database state to a cloud service. Most existing options expect you to query against a remotely hosted database and charge per read/write.
Since the database will have around 100,000 rows and you're typically working with all the data at once, streaming parts of it doesn’t make sense for my use case.
The closest I’ve found is Turso, which has offline writes in private beta, and SQLite Cloud, which lists local-first and offline sync as "coming soon."
The simplest approach might be letting users push to S3 storage with versioning. Ideally, it would also support point-in-time restores, tracking incremental updates alongside full snapshots.
Even better, I’d manage minimal server-side infrastructure and just pull the SQLite database from a service that handles syncing and management.
At the start up I work at [0], we use an open source library I developed to run hydraulic models of water networks in JavaScript [1].
A hydraulic model may be between 1-10MB and the simulation results can end up being 100+MB of time series data.
Other vendors with proprietary engines have to scale up servers to run their simulation engineers and will store and serve up results from a database.
Having everything done locally means we only have to store a static file and offload the simulation to the client.
Because we've architected it this way our hosting costs are low and users generally have faster access to results (assuming they're running a moderately decent machine)
I've found decent success sharing short product features videos, always less than 15 seconds, on LinkedIn.
Making the videos run much faster than normal, at least 1.5x and up to 3x in parts means you can provide a lot more density of information.
It does require the first pass to be visually interesting, and if you don't do something to stand out in the first three seconds you risk being scrolled past.
I also use subtitles to fill in the gaps and assume it will auto replay and if they make it through one replay, that further viewings will be easier to understand what is going on.
I have a relatively small following on LinkedIn ~2.5k but can get between 200-400 likes.
I then use these short clips on my GitHub pages for my work as well.
I work as a water engineer, specializing in building hydraulic models so water utilities can simulate their network.
A big part of that is calibrating them which can be time consuming, you look through hundreds of options. I create a few web based apps to help grind through these tasks but ultimately they were for my own use as a consultant to close projects quickly.
I did pull out the engine as its own open source library for other to use, and that ended up helping me get my current role where I can now maintain it and be paid at the same time.
I've had confirmation from a couple of sources now that this is indeed a SQLite file, or at least a derivative of it, with some key information missing.
If you email me how you know it is a SQLite file and what is missing, I can also send you the data that is contained within the files if that will be helpful to you.
SEEKING FREELANCER | $2,000USD bounty - Work complete, and bounty donation at users request
I'm working on an open-source library in a niche civil engineering field. I have a proprietary file format that I would like to decode and support.
I am almost certain the file is an SQLite database with the header changed, though my attempts to reconstruct the header and find any other changes have failed.
If you think you are up to the challenge, I've linked to some example files below, the first person who can share the procedure to update the file that it will open in a native SQLite reader I will pay a $2,000USD bounty or donate to a charity (your choice).
Email in profile, I'll post below if an answer has been accepted.
edit:
This has been decoded and the bounty will be donated! Waiting for confirmation from the person who provided the script to decode the file and I will share results and proof of donation
I think the vast majority of this thread agree with you that what we saw in the article was incredibly dangerous to the employee.
In my example these sites are unmanned 99% of the time but if there was an operator on site and someone back in the head office went on the loud speaker to tell off some trespassers I can't imagine OH&S or the on-site operator would be the slightest bit impressed.
When I worked at a water utility we would occasionally have people breaking into our remote sites like water towers either to vandalise them or climb the assets for the view.
When you just want people off your site ASAP we found providing the operators with remote loudspeakers and allowing them to say "Hey we can see you, we've called the police" was a very effective way to convince anyone that was trespassing to leave.
Though we did lose a few cameras when kids decided to throw rocks at the CCTV system before they left...
The goal is to replace clunky, expensive enterprise desktop tools (which often charge $10k+ for a wrapped version of the open-source US EPA engine). We want our version to be frictionless: login optional, runs entirely in the browser, and saves files locally to your device.
We are using the Functional Source License (FSL) to keep it sustainable while remaining open.
[0] https://epanetjs.com/