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/6d16e3e6-a649-426d-8cea-7d137bf2b474%40googlegroups.com.
