LumaFlow

This is where I (try to) explain what I am trying to accomplish.
Edit (Added GitHub): https://github.com/olutmatkaijian/LumaFlow/tree/master - this is an older version of the repository. I have a separate Gitea instance up and running. Probably the one on Github doesn't work as intended (yet), but alas, I have a headache because my upstairs neighbors kept running loud music until midnight.

History

Currently writing my M.Sc. Thesis. However, to do so I needed a simulation software. That's where the trouble started anyways - I don't have access to Aspen since it's so expensive. So I looked for alternatives. And one such alternative is DWSIM.

Now don't get me wrong. DWSIM is a pretty awesome piece of software and I am very grateful to the developer for making such an awesome software available as open source. However, DWSIM does not allow for collaborative editing - Simulate365 does, as far as I could tell. The problem with Simulate365 being it's very expensive!

Then there's the issue with software for drawing Process Flow Diagrams (PFDs). The best one, in my opinion, is hands down draw.io - which allows for a Desktop version which is awesome, especially for confidential stuff...Now, technically I think draw.io is open source and there could be a way to set it up on ones own server, but a quick glance at the github repository revealed Java. So I closed that tab quickly.

So: I need a flowsheet software that is collaborative and allows me to attach scripts to nodes.

Inception

It quickly became apparent that what I wanted was a collaborative flow-sheet designer. The problem being, it's either not possible to host them oneself, or it is not possible to attach scripts to nodes.
Then I thought to myself one day: Why not ask an AI? So I did, but it didn't give me any good answers. Didn't suggest any software that would satisfy my needs, anyways.

I have some experience in Flask. A few years back I was trying to build something similar. So I started from there. Thus, the idea for LumaFlow was born: A collaborative flow-sheet editor where I could define inputs and outputs to nodes, then connect them to python scripts and run that sequentially. I think NodeRED or something does something similar? I don't know. Never looked much at NodeRED.

Development

Now what does one do if one does not have the skill to build such an entire system oneself? Of course, ask an AI. ChatGPT was most helpful in designing the outlines of the software, and refining ideas. Vercels v0 - even though more tailored to react - could be coerced into writing code for SvelteKit+Flask+maxGraph. And to my surprise some of it worked, even if rudimentary. It really helped with the early prototyping.

Technical

1. Flask is used as a back-end server - I know python isn't that fast, but mojo would be. Looking to the future, I really hope I can adapt the software to mojo - that is if mojo can keep it's promises. I couldn't get the mojo development stuff to work on my machine. Also flask allows for very easy integration of python which is great.
2. Yjs is used for real-time collaboration between users. I haven't been able to get this to work yet.
3. maxGraph - the library that emerged from mxGraph from draw.io - is used to make the flow sheets.
4. SvelteKit is used for a responsive front-end
5. IBM's Carbon-Design-System is used to make it look better.
6. SocketIO is used in both SvelteKit and Flask for the obvious applications (real-time collaboration).

There's a folder "domain_libraries", containing the folders "Basic", "Streams", "Chemical Engineering", "Electrical Engineering", ...

As the title suggests these are domain libraries. A domain is any domain/field one has a library or writes a library for. Can be anything really, from engineering to logic, possibly even mathematics.
The typical domain library is structured in the following manner:

• components: Folder containing additional svelte components
• modules: Folder containing python scripts for the libraries modules
• svg_elements: Folder containing SVG's for the different elements of the library (e.g. heat_exchanger.svg)
• metadata.json: Version information, Library name, Library description, elements[{name, file, category}]

Prototype

(The IBM logo is only there because I think the carbon design system and IBM color scheme are neat. Blue light non-enthusiasts may disagree. Obviously I am not a great UI designer).

The Vision

The process starts by generating a new flowsheet. With every new flowsheet a new container is also initialized (I'm thinking Docker but there may be better options), where the flowsheets scripts will be executed - doing so on root just seems like a stupid idea.
Anyways, the new container and flow-sheet are initialized. Thus, I am now in the web-interface, the FlowsheetDesigner.
I would start my process by selecting the appropriate domain, for example "Chemical Engineering".
Then I would start adding my components onto the canvas: Reactors, mixers, whatever.
Each component is connected to other components using a Stream, and each component has two a dictionary of variables that components can share between each other. Quite possible, the script would look something like this:
``@inputs
mat_flow_in = float # Amount in [kg/h]
mat_flow_comp_in = dict # Composition of input material stream
energy_flow_in = float # kWh

product = mat_flow_comp_in.append("butane","0.2")

@outputs
mat_flow_out = 100 # [kg/h]
mat_flow_comp_out = product
energy_flow_out = ...

Note that this script is not intended to be functional, just to explain the overall principle. Thus I could for example model a simple chemical system using such code blocks, and manipulate the Streams within the node blocks (or technically the stream itself, if necessary).
After I've setup my flowsheet, connected them with streams and everything, I'd press "Run".
Thus, the software would run each script in sequence until the entire flowsheet has ran.
Since it's all written in Python, I could probably also leverage stuff like MatPlotLib and make beautiful graphs or something.

Notes

I don't know if this makes sense to anybody else. In my head it does.
If I can get this to work, then interdisciplinary teams could work on cool stuff.
Since the whole thing is designed from the ground up to be domain agnostic and modular, there's a myriad of applications one could use it for (given that people go through the trouble of creating domain libraries for it).

I will put what I have now up on a git, maybe that would make things easier to explain?