Multidimensional Arrays for Unit Testing

[rosenbrockc]

Multidimensional Arrays for Unit Testing

[wsmorgan]

Getting the input and outputs into a single file would be very nice except for the fact that if we went that way the only way we would be able to build input files for our unit tests would be to use fortpy. This would be inconvenient when we use things like mathematica to develop unit tests (which I have been doing for some of subroutines I've been testing). So even if it's less convenient I think the more generally accessible option is to use the first option and save/read the array's in slices.

Another possible option would be to have fortpy support either format, HDF5 or slices and have the user add a modifier to the input/output tag that would tell it which of the two it needed to use.

[rosenbrockc]

For the short term, we are going to just handle the arrays in plain text and leave the HDF5 for now. We will reserve the double pound symbol ## as the indicator for array shaping information. This is how it will work:

## 3 2 2
## 1,:,:
0 1
1 0
## 2,:,:
-1 1
1 -1
## 3,:,:
2 3
4 5

• The first line specifies the total shape of the array that can be used for allocating it in memory. It is just a list of the dimensions in the order that they would be entered in Fortran directly.
• The multi-dimensional array is specified in blocks of 2D arrays. Each 2D array block should be preceded by the index specifying where its data should be copied. Fortpy will splice the exact form of the index into the variable name on the left of the assignment. variable(3,:,:) = read(values).

This file format should be able to handle arrays of any dimension. In order to implement this, we will need:

1. Additions to the interfaces fpy_read, fpy_read_p and fpy_read_f that accept variables of dimensions 3 through 7 (which is the maximum supported dimensionality in fortran).
2. Additions to the fpy_save interface for dimensions 3 through 7 that writes out in this format.
3. A new file template for integer.xml and float.xml that handle the multi-D format.

At this point, it may be worthwhile to write a python module that can create the fortpy.f90 file without making errors. Then we will have uniformity across the implementation when the only differences are adding/removing allocatable or pointer modifiers. This will also allow the problem with logical not being supported to be addressed easily as well as complex types in the future, where the values have to be separated in real and imaginary parts.

[rosenbrockc]

Support available from Revision 1.6.0