Boundary conditions for individual surfaces in EB

[drjosephbrock]

Is there an example that shows the index space layout for embedded boundaries in AMReX? Is it possible to load multiple STL files that individually do not represent a manifold but together form a water tight surface? Ideally I would like to tag the surfaces and apply boundary conditions such specific to the surface features.

[rmrsk]

So, essentially a single watertight surface with triangle subsets associated with their own BC?

With EB, a cut-cell will have a single EB face but the cell may intersect or contain multiple triangles. Would that be a problem for you?

[drjosephbrock]

That shouldn't be a problem as there is a higherarchy in BCs and the OML is usually continuous vs the IML.

[drjosephbrock]

How can I get the the index of the triangle(s) used for the intersect?

[drjosephbrock]

I guess another question (or approach) would be; can I find the facet index (or indicies) used for a cut-cell? Then I can have a separate mapping for BCs...

[rmrsk]

Sorry for being unresponsive - AFAIK the STL stuff is buried inside the EB generation code. One option is to copy/paste it and load the STL as triangles, and then work your way through it from there.

Another option is to apply a utility code (https://github.com/rmrsk/EBGeometry) that's a bit more clever about the data structure representation of surface meshes. The bad news is that I did not attach meta-data to the facets at the time that I wrote this code. In hindsight I now feel stupid about that, but the extension was fairly straightforward so that it now runs also with meta-data. The figure below shows an example where the triangle ID is mapped to cut-cells, but the interface is sufficiently abstract that you can attach most C++ types to the facets (e.g., a boundary condition type, or even a std::map<std::string, std::function<...> if you want to go completely nuts)

If this is something that sounds interesting, I would need a bit more information about how you wish to parse data into EBGeometry. Breaking up watertight surfaces into subsurfaces is not something I thought people would do, but STLs are triangle soups anyways so that might be one way of doing it. The code has also not been hardened with this feature in mind, so having a beta-tester would be very useful.

There are other options too, like using CGAL/libigl/embree or any computational graphics library, but starting from those and getting to where you want will involve much more work on your end.

[drjosephbrock]

This is excellent. I would definitely like to give this a shot. I have tried CGAL in the past, but again, the main issue is figuring out how to pass the meta data to AMReX so I can figure out what the EB surface is.

The use case is for CFD, where I have an STL that I import with different components (and therefore different BC treatments). It doesn't need to be "perfect" in the sense of one dealing with multiple cuts in a cell. There are ways to get around treating the EB BCs if there are two different types of triangles in the cut cell.

[rmrsk]

There is also the matter of what kind of solver you're applying. Coarsening of complex geometries is not something that AMReX always handles, and some algorithms (geometric multigrid or sub-cycling) might choke on them.

[drjosephbrock]

The type of CFD is mostly aimed at doing Euler flow sims.

[rmrsk]

Ok, I did not know that STLs supported "components". Can you share the file or at least the format for one of the triangles?

[rmrsk]

So, one standard STL and an extra ASCII file with the BCs listed in the same order as the triangles?

Just trying to figure out how we should populate the meta-data. I think the internal triangle order will be the same as in the STL. Another way would be to use a file format that supports facet properties natively (e.g., PLY).

[drjosephbrock]

For now, I think a separate file containing the meta data for the triangles (ordered 1-number of faces) is easiest. It would be fairly simple to hand the same routine information from two external sources (STL and data.txt) or a single source split into two (.ply). Keeps it general for how one wants to include meta data as long as they know the ordering?

[rmrsk]

Ok sure - I will merge the meta-data feature in a few days, just need to make sure that none of the application examples choke on it.

[drjosephbrock]

I can work off of the decl_meta branch if you want me to test things out.

[rmrsk]

FYI I have now merged this, and it seems to work reasonably well on the geometries I've tested so far.