Common code extraction of DT and DMR

[bozhiyou]

I noticed that there are many common codes in Delauney Triangulation and the DMR application respectively (e.g. the Subgraph, Element, and Tuple data structure), and some of them are also useful for the developing Fast Marching Method application I'm working on.

I'm wondering if these common codes should be extracted out like BFS_SSSP.h in liblonestar folder. I'm not sure who is the original author of DT and DMR and afraid these repetitions are put on purpose. By the way, I also suspect if BFS_SSSP.h should reside in liblonestar folder since it's not useful across all the benchmarks (maybe libanalytics under lonestar/analytics is better?)

[ddn0]

My two cents:

If there is a common abstraction that is independent of specific applications, having some shared functionality makes sense, but there is nothing wrong with copying either. There might be enough differences that abstracting/pulling up commonalities obscures more than it facilitates.

For Delaunay Triangulation and Delaunay Refinement in particular, the implementations were kept separate because I didn't think there was much to gain from entangling the two applications and we didn't intend to make a general computational geometry library.

For BFS/SSSP, I think it is best to think of them as just variants of the same application, and if so, they could share code more naturally than through liblonestar/include/Lonestar/BFS_SSSP.h. IMHO, the only thing that liblonestar really should be providing is common functionality for all benchmarks.

[roshandathathri]

Agree with Donald. However, now that Bozhi is implementing new application(s) in lonestar scientific, it may make sense to put common structures/classes in a separate header.

BFS, SSSP - I think that's too specific to have a separate header.

[ddn0]

Subgraph, Element, and Tuple data structure

Perhaps more concretely, if you are interested in the Tuple and Element for their geometric aspects, it might be useful to find a 3rd-party library that suits.

If you are interested in Subgraph, Element and Tuple for their container-like properties, I'd suggest just reimplementing them in your own application.

[bozhiyou]

Thanks, Donald.

I think of Delaunay Triangulation and Delaunay Refinement as two steps in a pipeline based on similar data structures: DT discretizes the 2D space, DR refines the discretization; and further, what I am implementing now (the Fast Marching Method) is downstream that performs computation on the discretized meshes.

It's definitely fine to keep the copies or make a re-implementation. I'm just motivated by BFS_SSSP.h and think if there should be similar abstractions.

[insertinterestingnamehere]

Yah, the bfs and sssp common code should probably just be moved out of liblonestar since it's not needed by all the other apps.

With the scientific apps, it sounds like we need some consistent way of manipulating meshes. Hopefully there will be a third party library for that somewhere. I don't know where yet. For now we can just copy code.