Hello Winnifried, > With the old functionality it was possible to check if a refinement of > the mesh was performed between storage and loading and then interpolate > the vector onto the refined mesh used for computation.
The new SolutionTransfer workflow performs the transfer of data during the Triangulation::execute_coarsening_and_refinement() call. The initial implementation for the parallel::distributed versions of SolutionTransfer and Triangulation featured this workflow, and I think it was because of a requirement of early versions of p4est. Unfortunately, the new SolutionTransfer class can not be used for what you described at the moment. The main reason for the merge was the following. We did not have a serialization mechanism for the ParticleHandler class in the serial case yet, but already in the parallel distributed case. Instead of adding another specialized implementation, we decided that merging it with the previous implementation would be a reasonable approach, and it would also be more easily maintainable in the future to only handle only one implementation. However, this choice is not a permanent one. We are considering to redesign our current interface and implementation for the SolutionTransfer functionality. https://github.com/dealii/dealii/issues/15280 With the most recent versions of p4est (>= 2.0), it should actually now be possible to separate the data transfer stage from the refinement stage, which would make the implementation more flexible. So what you describe is potentially possible in a unified SolutionTransfer manner. I will add a comment to the above issue to make sure that we follow this design choice. For now, I would propose to keep the Legacy::SolutionTransfer class 'un-deprecated' for the time being until we have the new implementation. I would open up an issue on github and cast a vote among the main developers. Alternatively, you can extract the functionality from the old SolutionTransfer class and copy it into your project, provided you follow the licensing terms of deal.II. > To clarify: is the loss in functionality due to a lack in time and > people contributing but it could be fixed if I am willing to write the > code or is it coming from the problem that locally relevant dof's can > move to different cores in a distributed situation and thus it can't be > (reasonably) resolved in a unified manner for 'standard' and > 'distributed' vectors? To pick up on my comments above, it was not our intention to remove a feature and the clash with your code was an unwanted result. We believed that the effect of the prepare_for_pure_refinement() function could be reproduced by setting refinement flags on all cells, and then walking through the general SolutionTransfer process. To make sure that we retain your use case, may I suggest that you submit a small test case to our test suite? It should somehow recreate your scenario while using Legacy::SolutionTransfer::prepare_for_pure_refinement(). This way we will be alerted about breaking changes. In conclusion, a re-haul of SolutionTransfer means a lot of work. I speak only for myself when I say that I can't find the time to start working on it. Further, since it is 'just' a redesign, no new functionality would be added. Thus it's hard to justify spending time and resources on the redesign if it doesn't help us with any of our projects. If you would like to help us with the process, we would welcome any contribution. The above mentioned minimal test would be a good start. Marc -- 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. To view this discussion visit https://groups.google.com/d/msgid/dealii/fdb44679-e64e-4675-887a-9132f5a7530fn%40googlegroups.com.
