Nope, absolutely not. There is no implied liability nor fitness for any purpose whatever.
The software is thoroughly checked and tested with all kinds of address sanitizers again and again - in particular with clang's address sanitizer on windows, and valgrind on Linux.
Thus, I'm pretty confident there is not going to be any segfault or buffer overflow, memory leak, or other type of memory or stack corruption that could cause unwanted behaviour or even a crash of Blender. However, I still need to decline any liability, in that rarest of rare cases. Also, if you decide to model a real-world structure, you might still need to hire a structural engineer instead of rely on Matchstick.

Matchstick performs a simple case of the classical direct stiffness method of structural analysis. It takes nodal displacements and rotations, as well as gravity self-loads into account, as well as rotational moments.

Everything was written from scratch by myself and myself only. Apart from the C++ standard library, I only use the Eigen library for the linear algebra needs. No other external library is used. Every single source file, other than those included from Eigen, was written by myself from reading general textbooks on the direct stiffness method. I am therefore the only copyright holder for all source code.

Yes, I compared the results on a large number of input data with the results of some open source software for structural analysis. It coincides, up to numerical inaccuracies.

I've only benchmarked the core part of the software - the structural analysis itself.
I expect the complexity of the algorithm  - the underlying sparse matrix solver - to be something along O(N log(N)) where N is the number of edges, assuming the number of vertices is proportional to the number of edges. In short, this is as fast as it gets and is just marginally and indistinguishably slower thatn O(N) which would imply a fixed number of passes over the input data.

For all practical intents and purposes, O(N log(N)) is the same as O(N). It therefore makes sense to measure the runtime of the algorithm and divide it by the number of vertices and expect the result to stay more or less the same as you scale up your input data.
On my main development machine (which was not a top notch machine, ten years ago), a vertex of some small input is processed in about 9 microseconds. On my low-end laptop, it takes about two to three times longer.

It has certainly paid back to reimplement the direct stiffness method in C++ instead of Python.

Therefore, it makes sense to expect that inputs the size of some few thousand vertices could be processed in less than hundred milliseconds, which is about the upper limit for interactive "frame-rate" processing/editing.
Since I don't want Matchstick to freeze your computer, input sizes are strictly limited to 1000 vertices - which should be much more than enough for all kinds of wood log cabins, beach shacks, or even roof trusses.

Again, much more could be done performance-wise. I just picked the relatively low-hanging fruits.

Performance is one of the selling points of Matchstick. With some parallelization effort and a fast CPU, the per-vertex performance could easily be pushed below one microsecond. On structures of reasonable sizes, this would allow to run many thousands or even millions of input configurations in a brute-force manner.

Nope, it's no machine learning at all. It is plain old practical numerical mathematics. I firmly believe that we are standing on the shoulders of giants, but much too often we are oblivious about that and behave as if we were just at ground level. The kowledge of how to do a sound structural analysis counts as such a shoulder.
That being said, there are some interesting possibilities to use it for machine art. In particular, one can use it to train a neural net to produce structurally sound structures.
But it could be taken to be "generative art" - at least, after stretching the term a little.

Yes sure. Again, please just drop me an email.

It is realistic just as much as classical linear elastic analysis of structures of homogeneous materials with constant cross section - not less and not more.

For the "physically correct" option, the following material parameters are used:

- Diameter of the circular cross section: the supplied bevel depth r
- Polar (torsional moment of inertia of the cross section Jxx = 2 * M_PI / 4.0 * pow(r, 4)
- Area moments of inertia Iyy and Izz: both Jxx / 2
- Young's modulus E: 1e10 N / m^ 2
- Shear modulus of elasticity: G 4e9 N / m^ 2 - this passes as acceptable values for timber
- Density: 500 kilograms per cubic meter

A full-fledged structural analyis add-on is available on request: mathias@mathiasfuchs.com

I have invested a large amount of effort into making sure the add-on is as user-friendly as possible. In particular, I don't want the user to be bothered by error message unless it is strictly necessary. On indeterminate input, the solution will be a least squares solution in the sense of minimizing both ||Ax - b|| and ||x||. In many cases, this guarantees a sensible (maximally symmetric) output.

It does not perform structural analysis of plates such as floor slabs, walls, facades etc, let alone of volumetric entities. Instead, it only treats graphs which are basically one-dimensional lines embedded in 3d space - networks of nodes connected by members (or "frame elements"). Each member or frame element stands for a log/bar/beam etc.
Each such beam is treated in a circularly symmetric way, just as a wood log or bamboo stick. Frames with non-circular cross-section are not treated - but if that's what you want or need, drop me a line (mathias@mathiasfuchs.com) as it it is easy to incorporate but the UI/UX aspect is a little more complicated and depends on your use case.