external Dirichlet BC

[ZiyangHuang]

Hi,

I am learning AMReX_BCUtil.cpp in order to write a user-defined boundary condition. I am aware that the first argument of dummy_cpu_fill_extdir() is a Box, while it is an IntVect for the operator in dummy_gpu_fill_extdir{}. Is there any reason that CPU uses Box, while GUP uses IntVect?

The second question is whether the input arguments of dummy_cpu_fill_extdir() can be changed. Since I am working on a scalar, I don't need the component indexes like int dcomp and int numcomp, while keeping those can make the code more general. But at the moment, can I remove those from the input argument list of dummy_cpu_fill_extdir()?

Thanks!

[WeiqunZhang]

The IntVect version works for both GPU and CPU builds, whereas the Box version is for CPU builds only. So you don't actually need to worry about the Box version. It's this way for historical reasons. The GPU support was added in a way that it does not break existing codes. So we added a new interface (i.e., the IntVect version).

I don't think you should change the interface of dummy_cpu_fill_extdir. It does not buy you much. If you really want to, you certainly can. You will need to have your own version of CpuBndryFuncFab. You could also have your own version of PhysBCFunct that does not use CpuBndaryFuncFab and dummy_cpu_fill_exidir at all.

[ZiyangHuang]

Thanks for your clarification. I will just use the IntVect version for both GPU and CPU builds for simplicity.

Will any change to the input argument list of dummy_cpu_fill_extdir() require a new version of CpuBndryFuncFab? My BC depends on conductivity, and I want to add the conductivity to the input argument list of dummy_cpu_fill_extdir(). In this case, do I need to write a new version of CpuBndryFuncFab?

[WeiqunZhang]

Note that the dummy_cpu_fill_extdir functor is used by CpuBndryFuncFab, not called by you directly. So if you want to change the interface of the dummy_cpu_fill_extdir functor, you need to change CpuBndryFuncFab too. Otherwise how could dummy_cpu_fill_extdir get the conductivity argument?

That being said, this does not mean changing the interface of dummy_cpu_fill_extdir is the only or the desired approach for your code. Note that your version of dummy_cpu_fill_extdir is a functor that could contain its own data. For example, suppose you have a code that can talk to chatgpt and you can use it in your bound fill function.

struct my_fill_extdir
{
    void operator () (...) {
           chatgpy->give_me_coductivity(...);
    }

    ChatGPT* chatgpt;
}

Of course, this also does not mean you have to use the interface of dummy_cpu_fill_exdir. It's completely up to you.

[WeiqunZhang]

I used chatgpt as a joke to mean you can store anything your want in a functor. If I ask ChatGPT for an example of modifying the dummy_gpu_fill_extdir functor, it gives me this. Hopefully you get the idea.

🔹 Adding conductivity

For example:

struct my_gpu_fill_extdir
{
    Array4<const Real> conductivity; // or pointer/ref to whatever you need

    AMREX_GPU_DEVICE
    void operator() (const IntVect& iv, Array4<Real> const& dest,
                     const int dcomp, const int numcomp,
                     GeometryData const& geom, const Real time,
                     const BCRec* bcr, const int bcomp,
                     const int orig_comp) const
    {
        Real k = conductivity(iv); // use conductivity field
        dest(iv, dcomp) = k * some_function(iv, geom, time);
    }
};

Then when you construct the boundary function, you supply the conductivity field:

auto conductivity_arr = conductivity.array(mfi); // for the current tile
my_gpu_fill_extdir bc_functor{conductivity_arr};

GpuBndryFuncFab<MyData> gpu_bndry_func(bc_functor);

🔹 Why this works

    operator() signature stays the same (AMReX requirement).

    Extra data is passed via struct members.

    Works for both CPU/GPU functor styles (you can make a CPU version the same way).

[ZiyangHuang]

Your example helped a lot. I got the idea now. Thanks!