Generating boundary halo cells

[a-jp]

Using the apf (or PUMI) API how do I generate halo cells on physical boundaries? I would need any allocated field to also be available within the halos. I need the halos to perform flux based boundary conditions. These halos are distinct from those created at partition boundaries.

Thanks Andy

[cwsmith]

For very simple geometries these could be generated using PUMI APIs at runtime (there will be more/other problems given that they are outside the geometric model).

Adding an enclosing region (volume) to the geometric model by offsetting the exterior surface is the only robust solution I can think of. The mesh generator could then create mesh elements in the new region.

@MarkShephard @onkarsahni - Any ideas?

[a-jp]

If relevant in my case the geometry model is simply defined as:

  gmi_register_null();
  gmi_register_mesh();
  gmi_model *g = gmi_load(".null");

Halo cells (sometimes called ghost cells also) are very common in the finite volume world. We use them to implement boundary conditions. The key point is they are not "real" cells, they are never written to a mesh file, they have no concept of points defining them, no concept of faces or edges defining them, and are simply there to allow fluxes to be specified at the face boundary. So the key aspect is that on the boundary face the right cell (defined normally as the normal pointing out of the domain and therefore the halo is on the right of the boundary face in the face normal direction and the interior cell is on the left: this is just a convention and doesn't really matter) can be addressed while looping over faces. The second key aspect is that a nominal cell-centre and cell-volume can be ascribed, but again these don't need to be determined from the nodal coordinates and are normally a function of the left (interior) cell that shares the boundary face. Finally, data needs to be stored in those cells and be accessible via the face index/pointer/object etc.

Randomly, another way round this would be if the following was possible. For memory efficient reasons, is it possible to store a field only on select faces? So could I on the boundary face store the "cell halo volume". That would work as there is always a one-to-one mapping from boundary face to halo cell. But I can't do that by storing that field needlessly on all internal faces (with only meaningful numbers on the boundary faces) as there's quite a bit to store in the halo cells to enforce boundary conditions and this would blow memory (the main reason halo cells are used is for that memory efficient reason). Is the allocation of a field on only some entities (domain boundary faces in this instance) possible in apf/pumi?

I'd been adopting the view that, "it must be possible to build halo cells for boundary faces, as nobody would be able to use pumi for cell-centered finite volume methods without it", but now I'm thinking that maybe I've hit on a real issue here (for me) going forward....

Many thanks for the help, other thoughts/work arounds very welcome, including help with the above work around... Andy

[a-jp]

@cwsmith did you have any thoughts on how to do this? Bit stuck....happy to use a work around like the one I suggested. Is that approach possible?

[cwsmith]

At a conceptual level, PUMI does not have any notion of halo cells as described.

At a lower level, a tag or field can be created that exists on all entities of a given type. I don't think there is currently a mechanism to specify a subset of the entities (via geometric model classification or otherwise). If there is a lot of data needed for each mesh face classified on the geometric model boundary, and the mesh is static (i.e., the order or distribution does not change) a user level associative structure relating those boundary faces to the data may be the way forward.

[a-jp]

Ok. So how would I progress this? It seems to me the most generic approach that would have uses for other reasons (as yet to be mentioned), and fit with the pumi/apf constructs of no cells outside of the geometry constraints, would be to develop the field API to allow storage on a subset of entities. Would you agree? This needs to work for parallel, adaption, mesh motion, renumbering, redistribution etc. So keen to develop something in that context.

If so how would I go about starting that? (Preference here is not to base it, at least initially, on the geometric model, as I currently do not make use or interact with that part of the lib).