/run-hpsf-gitlab-ci

GitLab CI has started at https://gitlab.spack.io/amrex/amrex/-/pipelines/1365185.

does std::array work with HIP on device?

does std::array work with HIP on device?

We use it. I haven't seen any issues.

GitLab CI 1365185 finished with status: failed. See details at https://gitlab.spack.io/amrex/amrex/-/pipelines/1365185.

@AlexanderSinn Could you provide more information regarding the types of constructors that would be beneficial for your application?

I am not convinced that BoxND as an input is a good idea. There is an implicit understanding that BoxND is related to AMREX_SPACEDIM of the application, whereas ArrayND is not necessarily tied to this. This mismatch can lead to unexpected behaviour.

Yes, currently lower dimensions also use Array4. I assume this is out of simplicity and to make it easy to write code that works in 1D, 2D and 3D by always passing i,j,k,n to the array. However, I think eventually it should also be possible to use the ArrayND of the dimension the code is compiled for (plus one), as this should be slightly more performant and cleaner. The constructors should allow for both ways of using the array and should essentially mirror the interface of operator() for what combination of inputs and dimensions are allowed. For constructors using BoxND I would suggest:

• T*, BoxND<Dim>:  for Dim == dim, dim-1 and DIM < dim-1. In the last case, the remaining dimensions are set to begin=0, end=1.
• T*, BoxND<Dim>, int ncomp: for Dim == dim-1 and DIM < dim-1. In the second case, the Box is extended with begin=0, end=1. This overload won't be usable if dim == 1

Additionally, the ArrayND, ncomp and ArrayND, start_comp, ncomp constructors could be made to work with N>=2 instead of only N==4.

For the application I'm working on, I currently use implicit conversions from Array4 to a 2D array and a 3D array, where the 3D version removes the second to last dimension but keeps the last one. Dimensions that are removed are asserted to have size one if the constructor is called on the CPU.  This might be best left to the application, not AMReX.

I believe the final issue to address is the default indices used by ArrayND::operator()(IntVect<Dim>) when Dim < N. In my opinion, the default value should be begin rather than zeros.

The forward declaration

template <typename T> struct Array4;

in AMReX_BaseFwd.H still needs to be updated.

Also in the ArrayND, ncomp constructors, replace 3 with N-1.

@yut23 Note that this PR will break the GDB script (https://github.com/AMReX-Codes/amrex/tree/development/Tools/GDB) contributed by you. It would be great if you can fix it when this is merged.

one of our Castro problem setups fails to build with this PR:
http://groot.astro.sunysb.edu/Castro/test-suite/gfortran/2026-01-05-003/rad-2Tshock-3d.make.out

The Castro issue is that the indices passed to ArrayND are Real not integers.

    Real jfac = 1.0_rt;
    Real kfac = 1.0_rt;
    fine(i,j,k) = crse(clo.x, j / jfac, k / kfac) / rfac;

one of our Castro problem setups fails to build with this PR: http://groot.astro.sunysb.edu/Castro/test-suite/gfortran/2026-01-05-003/rad-2Tshock-3d.make.out

The error is from this line

  327 |                 fine(i,j,k) = crse(clo.x, j / jfac, k / kfac) / rfac;

I believe jfac is of type amex::Real. Previously this code relied on implicit conversion from Real to int when indexing Array4. The changes in this PR now require all index arguments to be explicitly int.

Sorry, my earlier test case was incorrect, since the IntVect overloads were only introduced in this branch.
The following code fails to compile in the ArrayND branch with C++17, but works on the dev branch. Compiling with C++20 fixes the issue.

Real* nullptr_real = nullptr;
Dim3 begin = IntVect(0).dim3();
Dim3 end = IntVect(ncells).dim3();
Array4 t (nullptr_real, begin, end, 1);

For discussion. Should we allow this construction now that last_dim_component is a template parameter

ArrayND<Real, 5> a(nullptr, IntVectND<1>(0), IntVectND<1>(ncells));
ArrayND<Real, 5> b(nullptr, BoxND(IntVectND<1>(0), IntVectND<1>(ncells)));

I find this rather confusing tbh.

Agreed. It's very confusing. We should only allow M==N and M+1==N && last_dim_component.

/run-hpsf-gitlab-ci

GitLab CI has started at https://gitlab.spack.io/amrex/amrex/-/pipelines/1389041.

GitLab CI 1389041 finished with status: success. See details at https://gitlab.spack.io/amrex/amrex/-/pipelines/1389041.

This now compiles.

constexpr Array4<int> a{};
static_assert(a.size() == 0);

Thank you for patiently reviewing the PR so many times.

Thank you for the PR! You did the work! If there are still bugs/defects there, it's all my fault for not catching it. :)

This change causes Castro when built with DEBUG=TRUE to run 3x slower. Is there a way to get the performance back in debug mode? Things only seem slightly slower when optimized.

I have a version that is only 10% slower than the original version in debug mode.

See #4900