precsim

There are really good free and open source research FEA & CFD codes available, like FEniCS, Moose, Nek5000, OpenFOAM, SU2 and more. However, being research codes they can be difficult to learn and sometimes even compile and get running, that is why FEATool Multiphysics has been developed [1] - an integrated physics simulation platform with the aim of allowing users to run "any" CAE simulation solver from an easy to use GUI and unified scripting environment.

[1] https://www.featool.com

I often nowadays find GNU GFortran the same speed or faster than Intel Fortan for FEM/CFD codes, while 10-15 years ago Intel Fortan was 10-20% faster in general. So these days I typically just recommend to go with GFortan which is easily available on most platforms.

Very interested in LFortran, are there any benchmarks how it compares with respect to performance to GFortran or Intel Fortran?

Thank you for explaining, I will have to explore this further as this opens up a lot of interesting possibilities. I find it very impressive that you have managed to get virtually no perceptible loading time at all, for octave running on a client (I remember threads now and then about statically compiling octave for portability which all eventually end up with it not being possible so I would never have guessed this was viable).

This is very interesting and would never have guessed that it is possible. I would love to read a more detailed write up how all this works (is everything bundled to a large blob for the octave interpreter for example?). Also is the a specific reason you used v4.4.1? And playing with the PWA everything seems instant, but Octave is ~1Gb installed, wouldn't the Octave wasm have to be downloaded to the client (which it doesn't seem to do)?

> Also if you want to ask me questions about my thinking as a user who thinks a lot in these problems space, feel free to email me (I will want it to move to a phone call, but don't want to post my phone number on hacker news).

Thank you for your offer, I could not find you contact info anywhere though, so I left my contact in my profile if anyone wants to get in touch for collaborations or anything at all really.

> I can understand that, having experienced something similar myself. The problem with users wanting things is they're often things that aren't really compatible with your vision, so you have to compromise and eventually, if you "succeed", you end up being a giant mess that everybody complains about like ANSYS.

Yes, unfortunately that is exactly right as I already am getting the heat. No matter what is wrong Matlab, meshing, OpenFOAM, FEniCS etc it always comes back to me even if its from an external solver or component, leading to lots of support. So yeah, I know many things could be much better and I'm far from what my "vision" is, but I don't have such resources so I have to try to do the best I can.

> Supporting multiple solvers is surely going to mean having solver-specific features, isn't it? Which would eat away at what seems like your vision. Or are you able to keep it abstracted from that so they really are interchangeable?

I have so far kept it abstracted with a minimum set of features, but some solvers only support some physics, models, or features so as you allude to sooner or later it will begin to become specialized modes or so for each solver, which is not ideal and I'm not yet sure the best way to move forward.

> Seems like you are just comsol.

Maybe it isn't too clear, but Comsol is just one solver (depending how to look at it I guess), while the idea of FEATool is to be a fully integrated platform for "any" solver, and in the extension to be able to mix and match and combine them (plug and play so to speak). At present I have just been able to implement the built-in MATLAB based multiphysics solver, with interfaces to FEniCS, OpenFOAM, and SU2.

> Why FENICS and not DEAL.II or MOOSE (I don't know, I am just curious. I used to use FENICs but got frustrated because their input syntax kept changing on me.

No particular reason really, I just started with FEniCS as it is quite popular and I found the FEATool PDE syntax easy to convert to FEniCS Python scripts. The plan is to add more and more external solver options.

> As someone who does this 50+ hours a week in industry (although only structural modelling but frequently coupled with optics/heat transfer/) and is reasonably well versed in the up and coming research I have a couple of questions (or would have if I was a potential buyer).

Thank you, I really appreciate the interest and feedback. Unfortunately its kind of "not implemented/available yet" to all your technical questions, although FEATool technically can solve any system of PDEs, I haven't yet pre-defined and set up everything so it is easy for the end users. So as many things are possible to do by going down to the FEM matrix assembly syntax but from a users standpoint that is most often the same as it doesn't exist.

> Also really cool. I have been thinking about writing software in this space but more nichy for about the past year and am beginning to get started, any interest in collaboration?

Thanks again for the feedback, I'm certainly open to all and any collaborations (email in my profile). Yes, looking back I think starting in a niche would have been a better approach.

I guess the thing is most people only use one solver, but at least when I was doing research it would be rare that two physics solvers based on different discretizations give exactly the same results (sometimes wildly different). So I would say, yes, its actually very valuable, although time consuming, and something most users don't really consider or think about (just because your physics solver converges doesn't necessarily mean the physics are represented accurately).

Thanks for the honest feedback. I started building FEATool far too many years ago not getting anywhere in academia after too many postdocs, since it was the one thing I'm passionate about and good at and I felt was "missing" when I was working. But yes, it seems more and more that each user has a very specific problem that they want to solve which is very hard to generalize for. And although I still think (most if not all) software could be much more user friendly, I probably have taken on more than I can chew (I only keep going now since I feel I have no choice with the years I've already invested).

Yes, I think the initial simulation definition/set up can be "easy", but once you get to parallel shared memory clusters it unfortunately have to be much more hands on. I had hoped to eventually not only allow running individual solvers from a single interface, but also allow coupling them similar to PreCICE [1], however making that easy to use is something I've not dared attempt yet.

[1]: https://www.precice.org

Don't really know how this ended up on the front page now, but the overall "idea" that I have yet to find anyone else understand and believe in (even my old prof and colleagues don't seem to "get it"), is that: wouldn't it be great if there was a unified, ideally simple, interface from which you could just select any solver by the click of a button, whether you wanted to use OpenFOAM, FEniCS, or maybe even Ansys, etc. Then you could set up your simulation model once, and run it on "any" and many solvers (to validate and check results etc.). So that's what I've been trying to do by myself for the past 7 years or so. For better or worse it initially seemed like a good idea to use Matlab/Octave, but have been planning to eventually move either to Python or Pascal/Delphi backend.

The first versions were open source asking for funding by donations. Although I would have really liked for FEATool to be open source (and I think such as tool would be ideally suited as such), unfortunately not having any form of funding but my personal savings, it was needless to say financially unsustainable (not to say that actually its financially much easier now).

Very interesting, making simulations "easy and accessible" really resonates with me having spent far too many years single handedly trying to get traction for my "easy to use" engineering physics, FEA, and PDE ideas and simulation tools [1]. I would be very interested in collaborations if anyone from hash.ai (or anyone else) is reading this and ever think of including/or moving in to the "easy to use" PDE based simulation space.

[1]: https://www.featool.com

Although not exactly a structured course or lessons, FEATool has been designed to be a very easy to use toolbox for physics simulations and learning by experimentation and trial and error with built-in tutorials (currently free license for home use during the lockdowns [1]), for fluid flow and heat transfer the simpler CFDTool might be more appropriate with an even simpler interface that "hides" the underlying PDEs [2].

[1] https://www.featool.com [2] https://www.cfdtool.com

Sure. As you guys seem to plan to do, I also started with some Matlab based work from my PhD years and felt that would be the quickest and easiest way forward. I also made the bet that the Octave app GUI functionality (uixx functions) would become good enough to use for commercial apps, which as great as base Octave is, it in my opinion hasn't. So as I make a fully client side app I am now dependent on users also purchasing or already having Matlab too.

As for Python, it is also a bet and compromise with the following specific criteria:

- Fast and easy to develop in (as I as a bootstrapped solo-dev have to do everything by myself)

- Reasonably simple to translate to from Matlab code

- Good and easy to use client side GUI functionality

- Easy for other users to use (as I want as many users a possible to use the functionality and potentially be able to write extensions themselves)

- 3D Visualization libraries (VTK, ParaView)

with this in mind my choices were:

1) Python

2) Julia

3) (Object) Pascal

4) Web stack (Javascript + webassembly)

I almost initially chose (Lazarus free) Pascal due to its IDE, fast compilation, and easy deployment but eventually I found the fixed pixel based GUI placement not ideal (although there are probably workarounds for that). Although using a web stack would be ideal from a user and sales perspective (with no installation), my impression of web programming is "messy" and I'm afraid that for CAE simulation apps this approach would freeze the computers completely (Electron!). Although I initially thought Julia would be ideal as the syntax was very close to Matlab, it seems to become more and more complex as it matures and my impression is that there still isn't a good way to deliver (pre-)compiled client side apps which is my requirement. So all in all I felt that Python probably the best compromise. It is still a bet, but with the "Matlab engine" you can call Matlab in the background so port bit by bit. In your case though with a (web) server-client app you might fare better with Matlab/Octave.

Tech-stack aside, I've found the hardest part is the non-techy bits, especially sales, marketing etc. which I still haven't figured out.

Best of luck!

As someone whos has written a very large and complex toolbox in Matlab [1], and now rewriting in Python I would not recommend locking yourself in to Matlab/Mathworks. However, if you don't use any GUI functionality you might get away with it, and you might be able to use Octave which can run must Matlab code unmodified (also see Octave online for deployment).

[1]: https://www.featool.com