Dear Rene, Thank you so much for your excellent explanation. I now understand and agree with that the approach you have chosen is the best way for this purpose. Yidong also told me that he has successfully implemented such helper functions for converting a particle's several features (although other challenges remain toward full parallelization of more advanced MPMs). We will gratefully cite your work as well when our parallelized MPM code will be used in our forthcoming papers. Thank you again for implementing this very helpful feature!
Many thanks, Jinhyun On Tuesday, September 17, 2019 at 5:57:40 AM UTC+8, Rene Gassmöller wrote: > > Dear Jinhyun, > > It is great to hear that our implementation has been useful for you. You > are probably aware that we described the implementation in our paper here: > https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2018GC007508, > but there is also an earlier version of the article on Arxiv that is a bit > more verbose about the reasoning behind our choice of property storage > scheme: https://arxiv.org/pdf/1612.03369.pdf (see Section 2.6). The > original version of these algorithms have been implemented for the ASPECT > project (https://github.com/geodynamics/aspect), and I can understand > that some of the choices might not be optimal for your application. If you > want to take a look at how we implement our properties (including a tensor > valued property integrated_strain) you can find some examples here: > https://github.com/geodynamics/aspect/tree/master/source/particle/property > . > > Basically, our intention behind the generic property storage type was that > we do not want to require our users to derive new particle classes from the > base class for every possible combination of particle properties. As we > have a large selection of possible properties (you mentioned some), but > only a subset of properties is actually used in each computation it would > be wasteful to carry around particles with all properties, and it would be > cumbersome to write new classes for every different application. May I ask, > which part of the current approach worries you? The performance overhead > from copying the properties once per time step should be small compared to > actually solving equations, and as Wolfgang mentioned you can hide the > conversion process by having functions like: > > Tensor<1,dim> > get_strain_tensor(const Particle<dim> &particle) > { > ... do the conversion here > } > > The main complication when creating child classes for particles would > probably be the different memory layout. As particles get transferred a lot > in parallel computation (when they move across domains, during adaptive > mesh refinement steps, during checkpoints) the ParticleHandler class needs > to know about their size, and how to serialize them, so if you plan to go > ahead with a derived particle class this will be the most complicated step. > This is where the generic particle property shines, because we can simply > assume we need to store n_properties numbers, instead of figuring out the > memory requirement for every particle property. > > I hope that explains our reasoning behind the design. Let us know if you > have ideas for how to extend the architecture, or if you have an > application that absolutely requires an extension of the design. > > Best, > Rene > > > > > On Saturday, September 14, 2019 at 1:27:57 AM UTC-7, Jinhyun Choo wrote: >> >> Dear Wolfgang, >> >> Thanks for your answer. To be clearer, Yidong and I have been working on >> the material point method (MPM) which is an offspring of the particle in >> cell method. We have implemented in using deal.ii as described in our arxiv >> preprint https://arxiv.org/abs/1905.00671 >> <https://www.google.com/url?q=https%3A%2F%2Farxiv.org%2Fabs%2F1905.00671&sa=D&sntz=1&usg=AFQjCNHjkIZlfuys-pkzkWmZkfgJ4qlwLA>. >> >> We are now working on parallelizing our implementation of MPM. >> >> As the MPM is developed for solid, a particle in MPM may contain a number >> of tensors (e.g. stains, stresses, and internal variables) as well as >> velocities, especially when the constitutive model is complex (typical for >> geomaterials that we deal with). While it is technically possible to write >> a function that converts a series of tensors into an array of double, it'd >> be absolutely better if a particle can carry more general types of >> properties. (If so, I think it can also be used for general nonlinear FE >> for solid mechanics.) We'd appreciate it if you could think this as a >> possible feature in the future! >> >> Best, >> Jinhyun >> >> >> On Saturday, September 14, 2019 at 4:29:30 AM UTC+8, Wolfgang Bangerth >> wrote: >>> >>> On 9/13/19 1:53 AM, Yidong ZHAO wrote: >>> > >>> > I want to store some material properties in particle properties. If >>> it's >>> > complicated, I think a better way is to write an interpretation >>> function. >>> >>> Yes, do the interpretation function. >>> >>> I've put my thoughts into some of the documentation. See here: >>> https://github.com/dealii/dealii/pull/8752/files >>> >>> Best >>> W. >>> >>> -- >>> ------------------------------------------------------------------------ >>> Wolfgang Bangerth email: bang...@colostate.edu >>> www: >>> http://www.math.colostate.edu/~bangerth/ >>> >> -- 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 on the web visit https://groups.google.com/d/msgid/dealii/6300fbeb-14eb-4ea5-9ba9-a29e85b9fa53%40googlegroups.com.
