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.