Hi Jack, Could you please elaborate why you need to read the data on ghost cells? The CellDataStorage and TransferableQuadraturePointData classes are designed to do assembly, where we always loop over *locally owned cells* and calculate local matrices to be assembled. If the ownership of cells change during coarsening/refinement, the quadrature data will be shipped to a new owner.
However when designing these classes we did not consider their usage with ghost cells. You could theoretically have some data attached to ghost cells, but I am not sure you will be able to synrchonize it easily. Namely, when the locally owned data belonging to some processor changes, you would need to ship this to other processors for which this cell is a ghost cell. That's not implemented, if I recall correctly. Cheers, Denis. On Thursday, November 3, 2016 at 8:24:11 AM UTC+1, Jack wrote: > > Dear Jean， > > > > Thanks so much for your suggestions. I’m really very happy for such new > development. > > > > I understand that using the CellDataStorage and > TransferableQuadraturePointData classes is better than user_pointer when > the mesh requires coarsening and refining. > > *Yet I do not understand how can I read the data of a neighbor quadrature > point that happens to in a ghost cell. Could you give me some clues?* > > > > Thanks! > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
