The type of particle properties

[Yidong ZHAO]

Hello all,

From the descriptions of Particle(https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1Particle.html) and PropertyPool(https://www.dealii.org/current/doxygen/deal.II/classParticles_1_1PropertyPool.html), I know the properties of a particle should be ArrayView<double> type. 

Is there anyway I can use the self-defined class as particle's properties?

Many thanks,

Yidong

[Wolfgang Bangerth]

No, for now it's just an array of doubles. But it is of course up to you how
you *interpret* them. For example, when you define dynamics on these
properties (i.e., a differential equation that describes how the properties
evolve), then it's up to you to interpret, for example, an array of 9 numbers
as the components of a 3x3 matrix. In other words, just convert the array of
numbers to whatever type you need, update that type at the end of a time step,
and then convert it back to an array of doubles.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Yidong ZHAO]

Dear Wolfgang,

Thanks for your prompt and clear answer!

Yes, I think *interpret* can work. Here I want to ask for a follow-up question: Whether it's possible(how difficult) to write a child class of Particle, whose property is not an array of double, but other self-defined types (like Tensor etc.)?

Thank you very much!

Best,

Yidong

[Wolfgang Bangerth]

Yidong,

> Yes, I think *interpret* can work. Here I want to ask for a follow-up
> question: Whether it's possible(how difficult) to write a child class of
> Particle, whose property is not an array of double, but other self-defined
> types (like Tensor etc.)?

No -- the ParticleHandler actually stores objects of type Particle. This can't
easily be changed.

What kinds of information do you want to store in your particles? It should
not be very difficult to write functions that convert from an
ArrayView<double> to a Tensor<...> and back.

[Yidong ZHAO]

Dear Wolfgang,

Thanks!

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.

Best,

Yidong

[Wolfgang Bangerth]

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

[Jinhyun Choo]

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. 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

[Rene Gassmöller]

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

[Jinhyun Choo]

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