Marc T. Henry de Frahan

One thing that bugs me about this UDF is that it is assuming that it is filling a cell-centered field (e.g. the way it computes `x`: https://github.com/Exawind/amr-wind/blob/main/amr-wind/physics/udfs/Rankine.H#L36). So there will...

Passing in `IndexType` would require changes in amrex because that's where the function signature/call for `amrex::PhysBCFunct physbc` is happening...

100% with Michael here. The curiosity is why i=40 is being filled. ``` MAC_projection 9 0.01766980429 1.791708441e-14 ghost cells here: (1,1,1) for idim: 0 --------------------------- filfcface call starts Going to...

@asalmgren yup that's understood. Though I bet amr-wind does this inconsistently (this Rankine UDF is one of those that doesn't do that bit right I think). Going through all the...

Yes I think that's about right and the same conclusion I reached last night. It would be good to achieve this without a ton of duplicate code in amr-wind. Going...

yes! I just found the same. The offending line is https://github.com/Exawind/amr-wind/blob/main/amr-wind/core/FieldBCOps.H#L172. This is fine for cell-centered, not fine for face-centered. Phew. Now to think of the right way to fix.

Right now my thinking is this: In FieldFillPatchOps.H: ``` Functor bc_functor() { return m_op(); } Functor face_bc_functor() { return m_op.face(); }. ----> add this and then use `face_bc_functor` in fillpatch_sibling_fields...

Addressed in #1093

This definitely feels like it could be due to using old versions of the stack. You mentioned using `spack` and I am not sure the best way to do that...

And even if it is off, it could be still picking it up: https://github.com/OpenFAST/openfast/pull/2229. We've asked that it be completely disabled so (very) recent commits of openfast should be safe(r)