Thanks and high-level interface using P4est.jl
lcw opened this issue · 5 comments
Thanks for all of your work wrapping p4est! It has been fun for me to work with p4est interactively via tmpi (https://github.com/Azrael3000/tmpi).
I have found the low level interface a little cubersome to use interactively so I made an inital draft of something a higher level. I am curious what you think of it.
You may find the high-level interface here https://github.com/lcw/P4estTypes.jl along with some initial documentation. It should be registered in a couple of days JuliaRegistries/General#81365.
Thanks a lot for sharing! The new package looks very nice! Are there any known issues with using P4estTypes.jl, e.g., features that are not (yet) supported or performance traps?
I wonder whether we could use it in Trixi.jl to simplify some code such as
https://github.com/trixi-framework/Trixi.jl/blob/628aee3d0c31598e81ec9afaba9666ab051fad04/src/auxiliary/p4est.jl#L57-L74
What are your plans for this package - just as a playground or stable for production?
I also wonder whether it would make sense to link to it from the docs of P4est.jl.
Thanks a lot for sharing! The new package looks very nice! Are there any known issues with using P4estTypes.jl, e.g., features that are not (yet) supported or performance traps?
Your welcome! I have only implemented a small (but functional) set of p4est. For example, the iterator doesn't support face, edge, or corner iteration yet. Also, Quadrant, LNodes and GhostLayer may need some more love. I plan to add functionality as needed for my multi-GPU dg code. To get an idea of what that is, here is the list of p4est types and functions my old C multi-GPU dg code used:
p4est_balance_ext
p4est_coarsen_ext
p4est_connectivity_destroy
p4est_connectivity_new_brick
p4est_connectivity_new_byname
p4est_connectivity_read_inp
p4est_connectivity_t
p4est_destroy
p4est_ghost_destroy
p4est_ghost_exchange_custom
p4est_ghost_expand_by_lnodes
p4est_ghost_new
p4est_ghost_support_lnodes
p4est_ghost_t
p4est_gloidx_t
p4est_init
p4est_iterate
p4est_iter_face_info_t
p4est_iter_face_side_t
p4est_iter_volume_info_t
p4est_lnodes_code_t
p4est_lnodes_decode
p4est_lnodes_destroy
p4est_lnodes_global_index
p4est_lnodes_new
p4est_lnodes_t
p4est_locidx_t
p4est_new_ext
p4est_partition
p4est_qcoord_t
p4est_quadrant_array_index
p4est_quadrant_compare_piggy
p4est_quadrant_face_neighbor
p4est_quadrant_is_inside_root
p4est_quadrant_t
p4est_refine
p4est_refine_ext
p4est_t
p4est_topidx_t
p4est_tree_array_index
p4est_tree_t
p8est_connectivity_new_tets
p8est_lnodes_code_t
p8est_lnodes_decode
p8est_tets_destroy
p8est_tets_make_righthanded
p8est_tets_read
p8est_tets_t
I would be happy to see contributions that support more of the p4est interface.
As far as performance is concerned, I have currently focused on getting things working and have not profiled anything. The main trap I see so far is callbacks. They are implemented to allow closures to be passed to p4est. I am not sure how performant that will be. Help on this would be much appreciated.
What are your plans for this package - just as a playground or stable for production?
My plan is for P4estTypes.jl to be stable for production (I am planning on using it for my mulit-GPU version of https://github.com/lcw/Bennu.jl--https://github.com/mwarusz/Atum.jl). I would like to iron out any interface/performance issues early so that the API can stabilized quickly. Any help on this front is appreciated.
P4est has been extremely stable over the years so I don't envision many changes once we get a functional set of the API covered.
I also wonder whether it would make sense to link to it from the docs of P4est.jl.
On my end of things it makes sense. The more eyeballs on P4estTypes.jl the better.