Where/When does AMReX register a box/boxarray layout for refinement?

[aerojpapp]

Hello,

I was able to successfully integrate AMReX into my code using the FORTRAN interfaces for an unrefined level 0 grid. However, I'm having difficulty moving to the next step...refinement. Because of my code structure, I've bypassed the default parameter parsing from an input file and instead am using the amrex_parmparse types to define various inputs. I think I'm missing an important input because I can't see the connection between the multi-fab and the refinement properties. I've defined a geometry, a box array associated with multiple muiti-fabs, and a distribution mapping using amrex_geometry_build(), amrex_boxarray_build(), and amrex_distromap_build() interfaces respectively. Following the initialization process in the Advection_F example, I then initialize the AMR core and register the 5 functions for level refinement using amrex_init_virtual_functions(). Then I allocate storage for each multi-fab refinement level, again similar to Advenction_F example. Finally, I call amrex_init_from_scratch() which starts the process of creating each of the grid levels and multi-fabs.

The un-refined level 0 works fine. After all the mult-fabs are created at level 0, the error estimate subroutine I registered with AMR core is called and it is here where there is an inconsistency in the various layout sizes. Using the Advenction_F example, in the my_amr_module.F90, my_error_estimate() function, a tagboxarry type is passed in as a c_ptr. A multi-fab iterator is created from the phi_new multi-fab and the tagboxarray values are set looping through the iterator and associated tilebox. My question at this point is what makes the tagboxarray lbound()/ubound() size consistent with the multi-fab? Is it because somewhere when the boxarray was created using amrex_boxarray_build() it is saved and this is what is used to define the tagboxarray? Or, is a tagboxarray type created somewhere internally and I'm missing it because I don't use the default parmparse function during startup?

The tagboxarray type in the Advection_F example is one bigger in all directions compared to the phi multi-fab. For my example, my boxarray goes from minimums of 1,1 to maximums of 400,400. With a 2 cell buffer for ghost cells, the bounds for the multi-fab data pointer is -1,-1 to 402,402. However, the tagboxyarray goes from -1,-1 to 400,400, not -2,-2 to 403,403 as would follow the convention in Advenction_F.

Hopefully this isn't too much in the weeds. Any help would be appreciated.

Thanks,

John

[aerojpapp]

As an addendum, everything would be consistent if my initial boxarray went from 0 to 399 instead of 1 to 400. So although creation of a box type allows for the arbitrary specification of the beginning and ending indexes, the defaults used to create refined boxarrays and tagarrayboxes buried somewhere in the AMReX library only allow index starts from 0.

John

[WeiqunZhang]

I am not surprised that the code breaks if the coarsest level's domain index does not start with zero.

[aerojpapp]

For now I just reverted to starting at zero but whenever I translate from multi-fabs to my local arrays, I have to remember to offset by one.

[WeiqunZhang]

Do you local arrays always start with 1?

AMReX always use global index. So even if the global domain index starts with 1, the subdomain owned by a process may start at any numbers.

[aerojpapp]

It's not a big deal. It's just that I got the impression that a box type can be created with any start/stop cell index and that this would carry over to refinement levels but it seems that when the tagboxarray and refined boxarray are created, they are created from a box with the same cells as the original but not specifying a start index of 1. When using the box lo/hi variables, I just have to remember to add one to the index to be able to reference any of my local variables arrays

[WeiqunZhang]

Please also note the component index in Fortran starts with 1, whereas in C++ it starts with 0.

[aerojpapp]

Yup.