Scan-and-Solve for Rhino

Simulate Early, Simulate Often... In Rhino

# S&S vs classic h-elements

Here is e test made to compare results obtained by S&S and a classic h-element solutor.

Resutls are very near (I don't show displacement because it is exaclty the same), but I can see that the two solutors manage in a different way "hot spots" caused by geometry discontinuities (anyway: with a higer resolution for S&S and a more accurate mesh for H-element solver there is a convergence).

I'm curious about the solver of S&S: it uses a FEM solution applied to "grid elements" instead of "mesh elements" or it include different mathematical concepts (boundary elements, finite volumes)?

I know, I should find some time to read the "white paper" :)

Views: 58

Attachments:

### Replies to This Discussion

As explained in the "white paper" :-) the current implementation of Scan&Solve is quintessentially FEM. Mathematically, there are two significant improvements over classical FEM: (1) boundary conditions are satisfied by the "scan process" as opposed to meshing; and (2) basis functions are B-splines, which have much nicer mathematical and computational properties.
B-splines? Very interesting!

Do you mean that S&S uses cubic basis funciton insted of linear or parabolic ones?
Actually, the beta uses linear B-splines, but we could turn on an ability to use B-splines of *any* degree -- but of course, this would come at an increased computational cost.
In other words, as summarized in this table
http://www.scan-and-solve.com/page/compare-with-fea
Scan&Solve can do it all: h, p, k -- at least in principle.
But we do not know what will end up in the final product yet.