Feature request: connectivity lists

[jmark]

This issue is primarly for noting down my thougths and make them available for the public in order to ignite an open discussion.

Looking from the Julia lang perspective (and also Trixi.jl, StartUpDG.jl, GPU programming, ...) it might be very convenient (and probably very efficient) to generate connectivity lists in t8code and pass them to the user as an alternative to iterator callback handlers.

What do I mean by connectivity lists? Take an examples from StartUpDG.jl :

# Simple hybrid mesh in 2D
# 
#   1  7______8______9
#      |      | 3  / |
#      |   4  |  / 5 |
#   0  4 ---- 5 ---- 6 
#      |      |      |
#      |   1  |   2  |
#   -1 1 ---- 2 ---- 3
#     -1      0      1

VX = [-1;  0;  1; -1; 0; 1; -1; 0; 1] # vertices x coordinates
VY = [-1; -1; -1;  0; 0; 0;  1; 1; 1] # vertices y coordinates
EToV = [[1 2 4 5], [2 3 5 6], [5 8 9], [4 5 7 8], [9 6 5]] # element to vertex map

# StartUpDG.jl builds its own representation of the mesh from above three arrays.

If t8code would give me directly above three arrays, this would simplify the interaction with t8code a lot and also would save lots of CPU cycles for transforming between the different grid representations of t8code and the application.

Moreover, the future for efficient computation is batch processing, especially on the GPU. This even goes beyond element boundaries (data of multiple elements is efficiently processed as one big chunk). I think element-wise iterators cannot account for this use case.

[holke]

Is this question about

• I need a list of nodes (a mapping elements -> vertices with unique vertex numbers)

or

• I need some form of representation of the mesh that i can query for neighbors and other relations

The first one is a rather involved task that is planned in a PhD project at Uni Bonn. The second would be more or less copying code from the Advect example and wrapping it in an interface. The t8_mesh.c/h files (currently empty) are created as placeholders to contain this functionality.

[jmark]

Both. ;)

I understand that the first point is a rather evolved plan.

But if it is ok to provide such a kind of interface (according to the second point) than I am happy to stitch something together.