STL defined geometries

I see in the code there is support for STL files, but I don’t know if this approach is fully mature yet? There are few, if any, examples on how to properly add geometries with this approach.

I’m not talking about using Crixus as a preprocessor. What I envision is some API function call like “addSTL(filename, fill_type, origin, etc.)”. For example, if I wanted to add a sphere, I could just draw a sphere in CAD, build a moderately fine mesh and save the STL. The STL coords are xyz referenced to an origin, which I can reorient in the “addSTL” arguments. The particle filling/subtracting should be the only thing GPUSPH worries about. In the end the STL approach would work for any abstract geometry. You could even distribute STL files with GPUSPH and build a library. Users could easily pass geometries to one another or tap into the huge library of STL files associated with 3D graphics and 3D printing for interaction with fluid environments. Point being the STL stuff is very mature and way more efficient then manually trying to build a domain by hand coding primitives for each unique problem domain.

If I’m not mistaken, the filling/subtraction of particles using STL files is exactly what Crixus does, only Crixus goes above and beyond to give advanced initial conditions (via the filling algorithm). However, the user interface, mesh resolution requirements, time to execute the filling algorithm etc. make the Crixus approach a painful solution. I think there are enough assumptions in SPH numerics and physics that the high fidelity initial conditions can be relaxed. In my experience, the current particle fill method for the primitives seems just fine. I don’t know how the filling of primitives would translate to filling STL defined geometries, but at its core, isn’t the STL mesh just a bunch of triangle faces? Couldn’t we treat this is as filling a plane? I certainly don’t have the best answers, but I’m sure there are great answers or resources out there.

All that being said, I personally think more effort should be put into the STL support since CAD already does primitives and so much more. GPUSPH doesn’t need to reinvent the wheel in this respect. The new Problem API is a nice addition to GPUSPH, but I think the STL support is superior in terms of being able to add geometries. Maybe I’m missing something, but this is all just preprocessor stuff and does not depend on GPUSPH in terms of numerics and physics. The Problem API could be considered an external library and thus I would ask why not just use a CAD software and focus on support for “addSTL”? Beyond CAD, STL files can be generated from many different programs, both free and commercial. For example, I can build a DEM in Matlab then export the surface as an STL. I can visualize the whole thing easily during construction and modify without having to compile, run, then export to ParaView as in the GPUSPH approach. There are way more efficient ways to build the geometry and I would like to see GPUSPH support those ways and the most global, cross-platform, method seems to be the STL approach.

If everything I’ve said is water under the bridge and the support does exist…I want to see examples and I want to see the full capabilities on display. For example, more than one object generated by STL files…STL objects which add/subtract etc. I realize I’m asking a lot, but I’m just expressing what users want to see.

Hello @GWAVE,

the STL support is currently mostly limited to the outer walls: you’ll notice that the Fill() and FillIn() methods are not supported. This isn’t a matter of principle, but simply of available work-force and priority, so if anybody is interested in contributing (and help us maintain) the logic to fill the inside of an STL mesh, we’d gladly accept the contribution, but our current focus is in improving other aspects of the code (e.g. integration of several new features such as open boundaries or heat equation that are of interest to almost everyone, us included).

Concerning the existence of a geometric library in GPUSPH, this is actually intentional, and it will remain this way, although we have some plans for improving it, making it easier to define more complex geometries from the simpler ones, with a more sane and robust API than the one we have currently (which is definitely sub-optimal for anything moderately complex).

There are several reasons why we intend to keep the geometric library: (1) it allows definition of test cases without any external tools (at least as long as SA boundaries aren’t used) (2) the test cases can be designed in such a way that they automatically adapt to different resolutions, meaning that you can run higher/lower resolution test cases without having to run any preprocessor again (3) you can adapt the geometry dynamically and/or based on the active problem settings (e.g. the exact boundary position or filling based on the chosen boundary model).