Feature/brinkman

[timfelle]

Introduction of a Brinkman forcing term.

The idea of this is to enforce regions of low permeability to block flow in certain regions. Included is an example with a Stanford bunny placed in a square duct as a block of resistance.

Still some todo points, but wanted to open it up so I could start to get some feedback

• [x] Documentation of the example and the source term in general, including an image or two.
• [ ] Device acceleration for computation of the brinkman term.
• [ ] Add open mesh example.
• [ ] Trim aabb_tree, triangles outside the fluid domain. -> Postponed, there are some situations which require this to be done with care.
• [ ] Expand to utilize point zones. -> moved to sepparate PR

[timfelle]

Do you have any preference on code structure?

• I currently have implementation details in the source_terms/brinkman folder but i can move it to source_terms/bcknd if that makes it clearer.
• The AABB tree and could be moved to the mesh folder where the Octree also lives.

[njansson]

Is this ready for review now?

[timfelle]

Is this ready for review now?

Hmm i would want to setup a few unit tests but in essence we could pull it in as it is and just do extensions later on.

I have been working on setting up pFunit with my environment so that i could se if it works. The entire setup of the brinkman term is also done on the CPU only. but that would only be important later on if we want really big meshes.

[timfelle]

Lets get it out there. Ill do seperate PR's for the other extensions to it as they are ready. This way others can get to experiment with it.

[timfelle]

Ups, wrong branch

[timofeymukha]

Not gonna lie, I did not check any of the algorithms in the tree and distance stuff. I guess in an ideal world, it would be nice to add unit tests for the aabb, the tree and the distance. Would double as a demonstrator for how these things work :). But perhaps in a later PR then, in case someone feels inspired.

Question, should the aabb go to "common"? Seems like a larger scope than just this source term, e.g. already discussed in context of probes.

[timfelle]

Not gonna lie, I did not check any of the algorithms in the tree and distance stuff. I guess in an ideal world, it would be nice to add unit tests for the aabb, the tree and the distance. Would double as a demonstrator for how these things work :). But perhaps in a later PR then, in case someone feels inspired.

Question, should the aabb go to "common"? Seems like a larger scope than just this source term, e.g. already discussed in context of probes.

Yes, i would like to write some tests for it. However, i have had some issues setting up my environment with the test library. But i am almost there, i think..

And sure, lets move the general stuff somewhere else. I think the signed distance stuff could go to math and the aabb_tree could go to mesh, since thats where the octree also lives.

[timfelle]

@njansson Any idea why the MacOS one fails here? It seem that when I re-ran it different tests from the pfunit thing fails.

Additionally the runner seem upset about some MacOS version stuff: was built for newer 'macOS' version (13.6) than being linked (13.0)

[njansson]

@njansson Any idea why the MacOS one fails here? It seem that when I re-ran it different tests from the pfunit thing fails.

Additionally the runner seem upset about some MacOS version stuff: was built for newer 'macOS' version (13.6) than being linked (13.0)

There seems to be some issue with the runner, it fails when trying to create some temp storage (according to the failed test logs)