arjenmarkus/interpolation2d3d

Interpolation in 2D and 3D, object-oriented interfaces

interpolation2d3d's Issues

Strided access with array views

I noticed that all the interpolation classes make copies of the x-, y-, and z-arrays (when applicable). This is of course a safe and pragmatic design choice, after-all memory is cheap today.

For large applications, one might not be able to afford the copies. In this case it might be preferable to have a network_view class, which only stores a reference to the data:

real, pointer :: x(:) => null(), y(:) => null()

What I've realized today is that such a class could access the coordinates in their natural storage layout:

subroutine create_mesh_2d( this, x, y )
    class(network_view_2d), intent(inout)  :: this
    real, intent(in), target          :: x(:)
    real, intent(in), target          :: y(:)

This would mean an application could support both Fortran- and C-like layouts,i.e.

    real, target :: x(4), y(4)

    x = [ 0.0, 0.0, 1.0, 1.0]
    y = [ 0.0, 1.0, 0.0, 1.0]

    call network%create_mesh( x, y )

or

    real, target :: xy(2,4)

    xy(1,:) = [ 0.0, 0.0, 1.0, 1.0]
    xy(2,:) = [ 0.0, 1.0, 0.0, 1.0]

    call network%create_mesh( xy(1,:), xy(2,:) )

I think the strided array access is a very cool Fortran feature. I haven't looked deeper into the original routines from Renka. Presumably those expect (contiguous) assumed-size arrays. Those would need to be modified to take assumed-shape arrays for the above to work

Note I have no urgent need for this, but the idea seemed worth documenting at least.