Too often, Fortran programs implementing variational calculus, i.e. Finite Element, Finite Volume and Finite Difference, have declarations like

```
real ustar(Nxp1,Ny), un(Nxp1,Ny)
real vstar(Nx,Nyp1), vn(Nx,Nyp1)
real CONVx(Nx,Ny), VISCx(Nx,Ny)
real CONVy(Nx,Ny), VISCy(Nx,Ny)
```

In a refactoring to Chapel, these might naively map directly to declarations like

```
var ustar, un : [1..Nx+1,1..Ny] real(32);
var vstar, vn : [1..Nx,1..Ny+1] real(32);
var CONVx, VISCx, CONVy, VISCy : [1..Nx,1..Ny] real(32);
```

The problem with the above is that you have to carry around all these variables throughout the program and your Chapel program inherits those ugly long Fortran parameter lists.

Realizing that these visc[osity] term and conv[ection] terms are just two pieces of data associated with a single point (i, j), i.e. point data, each of which exists in two dimensions, one could declare a single variable, say `vc`

, that contains all of the above point data as:

```
const D = 1..2; // 1 => X-direction, 2 => Y-direction
const V = 1..2; // 1 => viscosity, 2 => convection
var vc : [V, D, 1..Nx+1, 1..Ny+1] real(32); // point data
```

In this way, you needs to carry around one variable, `vc`

, instead of four, albeit with some wasted space in the final row and column in two scenarios.

Within one's code, when one wants to do operations on individual component of that point data, you just slice it up, always with rank reduction. That is, within a routine, one might see

```
ref VISCx = vc[1, 1, .., ..];
ref VISCy = vc[1, 2, .., ..];
ref CONVx = vc[2, 1, .., ..];
ref CONVy = vc[2, 2, .., ..];
```

This results in such slicing, i.e. rank reducing slices, being the predominant slicing operation in

a Chapel refactorization of these types of Fortran programs.

Looking at another scenario, slicing of some array with a reduction down to a rank of 1 where the slice contains memory-contiguous floating point data, is the operation that many of us want to maps to a hardware vector, a feature that many of us want to exploit heavily in our programs.

I looked at all the occurrences of slicing inside old Fortran programs that my colleagues, clients and I, use, and hope to, have or want to port to Chapel. Therein, rank-reducing slicing accounts for 99+% of the slicing operations. I might have missed a few, but not enough to make a huge difference to that number.

This makes the performance of such rank-reduced slicing really critical. Chapel needs as a goal, the ability to slice with rank reduction being as performant as that without rank reduction.

My 2c.

With thanks to @annacfs for her Finite Volume Computational Fluid Dynamics example seen in GitHub Issue #19636.