bitpit icon indicating copy to clipboard operation
bitpit copied to clipboard

bitpit::Map refactor

Open pkestene opened this issue 5 years ago • 4 comments

I order to ease writing IO routine outside of class ParaTree/PabloUniform, a routine that needs to access mesh connectivity and geometry, I would like to suggest the following modifications:

  • add a method to class ParaTree to get a const ref to a Map
  • make public some of the API of class Map
  • let PabloUniform exposes a const ref to the logical coordinate of the node (currently available in ParaTree, but not in PabloUniform).

I'll submit a PR for that so you can have an idea of the modifications

pkestene avatar Feb 12 '20 12:02 pkestene

Hi pkestene, thank you for the suggestions. We'd like to ask you just some clarifications:

  • What is the goal of the modifications? Do you need to write the mesh in physical, reference and logical coordinates?
  • The reference coordinates, bounded in the reference interval [0,1], can be asked directly to Paratree, e.g : <pablo_uniform_object>::ParaTree.getCoordinates(octant_id); is that you need?
  • The logical coordinates can be asked in the same manner, for instance the logical coordinates of all the nodes can be retained, by using the typedef inside the module, by: u32arr3vector logicalNodes = <pablo_uniform_object>::ParaTree.getNodes()

Finally, I suggest you to pass to the use of VolOctree class instead of PabloUniform one. The VolOctree module is a wrapper of PABLO module but it can interface with all the native container of bitpit; morevoer VolOctree class eases the mesh adapting with data defined on the mesh and allows to use the IO bitpit module with classes for VTK output.

edoardolombardi avatar Feb 17 '20 14:02 edoardolombardi

I guess you're probably right. I never tried to use VolOctree; I'll give it a try. I didn't try hard enough to look at that class...

One goal of the modifications was to be able to have a IO Writer Class completely outside of the PABLO; besides in some computational kernels, we also need to have access to ghost octant info (size, level, location, etc...) which at some point (several month ago) was not directly available with the same API as regular octant.

Thank you for your input.

pkestene avatar Feb 19 '20 20:02 pkestene

Yes, you're right; we know the current lack of examples in the library, but if you need some hint to work with VolOctree class you can give a look in the related test folder. In fact, they are real examples used as compilation tests of the project. There, you can find scripts for both serial and parallel use of 2D or 3D VolOctree meshes. Please, let us know if the pull request #44 can be closed or you think that such modifications are equally needed. Thank you for your feedback and comments.

edoardolombardi avatar Feb 20 '20 11:02 edoardolombardi

I'm closing the pull request #44. In case it will needed, we can re-open.

edoardolombardi avatar Feb 28 '20 11:02 edoardolombardi