Improve multidimensional arrays implementation

I want to check in code that changes the implementation of iPic3D arrays.

iPic3D currently uses chained pointers (e.g. double *\ arr3;) rather than array classes. This has a number of deficiencies:

There is no way to turn on automatic bounds checking.
De-referencing chained pointers can be much less efficient than alternative multidimensional array implementations for some compilers and architectures.
Memory must be explicitly managed.
For reliably good performance, the programmer must explicitly inform the compiler that arrays are aligned at each point in the code where they are accessed.

I have therefore implemented array classes according to the following specifications:

The user should be able to choose via a compile option whether the underlying array class is one of the following:
- chained pointers
- calculated index of an underlying one-dimensional array
- built-in C arrays using fixed dimensions defined at compile time.
Automatic bounds checking should be available via a compile option, (e.g. -DCHECK_BOUNDS) with no performance penalty when turned off.
Automatic memory management should be available.
Memory allocation should be aligned, and the compiler should be informed of this alignment in the array accessor methods.

I have implemented extensive performance tests of these arrays, and have compared performance of native arrays, chained pointers, and calculated index access for both g++ and icpc (Intel) and for both my laptop and the Xeon processor. With icpc on the Xeon processor, the performance differences can be significant and hard to predict. With g++, performance differences are much smaller. Using the -O3 flag to turn on optimization, I have verified that there is no performance difference resulting from any of the choices of syntax considered in the following paragraphs.

To avoid the need for systematic modifications to the code, I have implemented access of elements via bracket syntax, e.g. intarr[i][j]=5;. If I were writing a new code, I would prefer to use parenthesis syntax, e.g. myarr(i,j)=5;. But requiring such syntax in iPic3D would entail systematically changing about 1000 lines of code, mostly in the fields classes. Given the number of forked versions of iPic3D that need to be merged, it is not desirable to impose such a change at this time. We could use a script to change to such notation in the future; making the switch would be most painless at the end of a merge point in the software development cycle. Given the nature and the pressures of academic work, realizing such a merge point may not be easy.

Ideally, I prefer syntax which distinguishes write access from read access. At a minimum, we should support read-only array access so that we can pass const array references to methods that use array information without modifying it. Therefore, I have implemented get methods, e.g. var = intarr.get(i,j);.

For completeness, I have also implemented set methods, e.g. intarr.set(i,j, myvar);, allowing the user to clearly indicate write-access. I have also implemented a fetch() accessor, which allows both read and write access via:

  myArr.fetch(i,j) = 5;

Of course we could replace fetch with operator(), allowing the usage

  myArr(i,j) = 5;

as in the implementation of Vicenc Beltran and his collaborators, but I preferred being able to search for the string fetch in order to identify potential write-access. I will consider feedback offered in response to this issue and am willing to change fetch to operator() if this is the consensus desideratum.

CmPA / iPic3D

Improve multidimensional arrays implementation #43