Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 12/4/20 6:18 AM, shahab.g...@gmail.com wrote: Not here, but it other functions it would be very useful to be able to map back to the owning particle. I suspect that in that case, it wouldn't be cheaper to loop over particles and map back to particles, but that you could as well loop over particles to begin with. In fact, I have to treat local and ghost particles differently. In terms of updating properties, I only need to update the properties of local particles. This is where things get difficult. The PropertyPool doesn't know which particle properties correspond to locally owned or ghost cells -- and I'd argue that it shouldn't know that either. PropertyPool is really just a slightly more intelligent way to allocate memory on the heap. What the *meaning* of what it stores is not something it knows about, and I don't think it should. If you needed to do something different between locally owned or ghost particles, you'd have to store information in duplicate in some way, and that presents the potential for things to go out of sync. Best W. -- Wolfgang Bangerth email: bange...@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/15633ff5-245f-e536-c087-b35a8ec83ceb%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Hello Shahab, I would wait before trying to do some changes. Rene has started looking more deeply into the particle structure (see : https://github.com/dealii/dealii/pull/11314) and this will, most likely, fix your problem. On Friday, December 4, 2020 at 8:18:11 a.m. UTC-5 shahab.g...@gmail.com wrote: > Not here, but it other functions it would be very useful to be able to map > back to the owning particle. > In fact, I have to treat local and ghost particles differently. In terms > of updating properties, I only need to update the properties of local > particles. When the maximum displacement of a particles reaches half of the > cell length in the triangulation, I call > sort_particles_into_subdomains_and_cells() to update the list of local and > ghost particles. I can explain the algorithm in more details if you want. > Thanks again. > Shahab > > On Thursday, December 3, 2020 at 10:54:42 PM UTC-5 Wolfgang Bangerth wrote: > >> On 12/3/20 4:13 PM, shahab.g...@gmail.com wrote: >> > I want to iterate through all the particles in each iteration of my >> solver and >> > update some of the properties. The problem is iterating through >> particles >> > using particle_handler() is rather computationally expensive. I am >> looking for >> > a way to update the properties without iterating through the >> particle_handler. >> >> I see. >> >> So you'd need to iterate through the the blocks of properties stored in >> the >> PropertyPool? We could write such an interface, but let me ask a couple >> of >> questions first: >> * Do you need to map back from block of memory to the owning particle? >> * Will you somehow need to treat ghost particles differently than the >> locally >> owned ones? How will you make sure that locally owned particles on one >> processor stay in sync with the corresponding ghost particles on the >> other >> processor(s)? >> >> 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/5e92a68f-bd8c-4877-bfad-047b8a4fc86cn%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Not here, but it other functions it would be very useful to be able to map back to the owning particle. In fact, I have to treat local and ghost particles differently. In terms of updating properties, I only need to update the properties of local particles. When the maximum displacement of a particles reaches half of the cell length in the triangulation, I call sort_particles_into_subdomains_and_cells() to update the list of local and ghost particles. I can explain the algorithm in more details if you want. Thanks again. Shahab On Thursday, December 3, 2020 at 10:54:42 PM UTC-5 Wolfgang Bangerth wrote: > On 12/3/20 4:13 PM, shahab.g...@gmail.com wrote: > > I want to iterate through all the particles in each iteration of my > solver and > > update some of the properties. The problem is iterating through > particles > > using particle_handler() is rather computationally expensive. I am > looking for > > a way to update the properties without iterating through the > particle_handler. > > I see. > > So you'd need to iterate through the the blocks of properties stored in > the > PropertyPool? We could write such an interface, but let me ask a couple of > questions first: > * Do you need to map back from block of memory to the owning particle? > * Will you somehow need to treat ghost particles differently than the > locally > owned ones? How will you make sure that locally owned particles on one > processor stay in sync with the corresponding ghost particles on the other > processor(s)? > > 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/2796d59e-3e02-4888-91d5-2b9dc148ec5en%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 12/3/20 4:13 PM, shahab.g...@gmail.com wrote: I want to iterate through all the particles in each iteration of my solver and update some of the properties. The problem is iterating through particles using particle_handler() is rather computationally expensive. I am looking for a way to update the properties without iterating through the particle_handler. I see. So you'd need to iterate through the the blocks of properties stored in the PropertyPool? We could write such an interface, but let me ask a couple of questions first: * Do you need to map back from block of memory to the owning particle? * Will you somehow need to treat ghost particles differently than the locally owned ones? How will you make sure that locally owned particles on one processor stay in sync with the corresponding ghost particles on the other processor(s)? Best W. -- Wolfgang Bangerth email: bange...@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/fb04d6f4-3eb9-9d04-aca8-84a6404e03ec%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Thanks for the reply. I want to iterate through all the particles in each iteration of my solver and update some of the properties. The problem is iterating through particles using particle_handler() is rather computationally expensive. I am looking for a way to update the properties without iterating through the particle_handler. Best regards, Shahab On Thursday, December 3, 2020 at 4:46:33 PM UTC-5 Wolfgang Bangerth wrote: > On 12/3/20 1:19 PM, shahab.g...@gmail.com wrote: > > Can you please write an example of accessing memory pool handles, > iterating > > them and converting the handles to particle properties? > > The way we think about it is that the MemoryPool stores the data in some > way > that should not be of any concern to you. You access these properties > through > the particles they are attached to. As a user you don't have contact with > the > PropertyPool at all. > > At least that was the original idea. Can you explain what you're trying to > do? > > 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/55ace764-efa4-45dc-abb1-233a9c5e5b4en%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 12/3/20 1:19 PM, shahab.g...@gmail.com wrote: Can you please write an example of accessing memory pool handles, iterating them and converting the handles to particle properties? The way we think about it is that the MemoryPool stores the data in some way that should not be of any concern to you. You access these properties through the particles they are attached to. As a user you don't have contact with the PropertyPool at all. At least that was the original idea. Can you explain what you're trying to do? Best W. -- Wolfgang Bangerth email: bange...@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/38921bea-9e6c-29c5-ec1d-87adc369ed85%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Hi,
Can you please write an example of accessing memory pool handles, iterating
them and converting the handles to particle properties?
Thanks in advance.
Best regards,
Shahab
On Monday, October 19, 2020 at 10:57:26 PM UTC-4 Wolfgang Bangerth wrote:
> On 10/19/20 9:03 AM, blais...@gmail.com wrote:
> > I am not sur if I fully understand the memory structure of the Property
> Pool
> > (or at least I am still confused by it).
> > If I understand correctly, the properties of all the particles are
> stored in a
> > single Handle array and the get_properties of a single particle returns
> an
> > array view pointing to this large array.
> > However, the n_properties_per_slot() returns the number of properties
> > associated with a single particle. Is there a way to know from within
> the
> > property pool the size of the handle array?
>
> Maybe
> https://github.com/dealii/dealii/pull/11057
> clarifies the intent of the PropertyPool? The idea is that the property
> pool
> is responsible for all of the memory allocated for particle properties.
>
> I've come to realize that what you want to do wasn't possible in the
> current
> design (because we don't keep track of which memory we have allocated), so
> wrote
> https://github.com/dealii/dealii/pull/11059
>
> Once that is merged, I think what you want to do is maybe something along
> the
> lines of the following addition to the PropertyPool class:
>
> /**
> * Return the first of all of the memory pool handles that are managed
> * by this class. Iterating from begin() to end() then returns the handles
> * associated with all particles in the ParticleHandler class that owns
> * this property pool; using the get_properties() function, these handles
> * can be converted to ArrayView objects that then allow access to the
> * actual properties.
> *
> * This function can be used to access and modify the properties of all
> * particles, though possibly in a different order than if one accessed
> * them using ParticleHandler::begin() and ParticleHandler::end().
> *
> * @note PropertyPools also store the properties of ghost particles,
> * and consequently iterating over all handles also reaches the
> * properties of ghost particles.
> */
> std::set::iterator begin ()
> { return currently_open_handler.begin() }
>
> + same for the corresponding end() function.
>
>
> > If the properties are stored in a continuous block, one could easily
> write a
> > function that takes into argument a vector of property index, the value
> to set
> > and the number of particles for example. This function would then be
> called
> > from the particle handler which in turn would have an interface to this
> > function with the vector of property index and the value to set.
> > Would that be the right approach? If so, I can work on a PR.
>
> PropertyPool doesn't advertise how it stores properties. Currently, it's
> not
> in one large block, though that's something we might want to change at
> some
> future point. The interface above avoids exposing how exactly they are
> stored.
>
> 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/0ef442aa-6197-47c6-b7ca-b40c04e340edn%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 10/19/20 9:03 AM, blais...@gmail.com wrote:
I am not sur if I fully understand the memory structure of the Property Pool
(or at least I am still confused by it).
If I understand correctly, the properties of all the particles are stored in a
single Handle array and the get_properties of a single particle returns an
array view pointing to this large array.
However, the n_properties_per_slot() returns the number of properties
associated with a single particle. Is there a way to know from within the
property pool the size of the handle array?
Maybe
https://github.com/dealii/dealii/pull/11057
clarifies the intent of the PropertyPool? The idea is that the property pool
is responsible for all of the memory allocated for particle properties.
I've come to realize that what you want to do wasn't possible in the current
design (because we don't keep track of which memory we have allocated), so wrote
https://github.com/dealii/dealii/pull/11059
Once that is merged, I think what you want to do is maybe something along the
lines of the following addition to the PropertyPool class:
/**
* Return the first of all of the memory pool handles that are managed
* by this class. Iterating from begin() to end() then returns the handles
* associated with all particles in the ParticleHandler class that owns
* this property pool; using the get_properties() function, these handles
* can be converted to ArrayView objects that then allow access to the
* actual properties.
*
* This function can be used to access and modify the properties of all
* particles, though possibly in a different order than if one accessed
* them using ParticleHandler::begin() and ParticleHandler::end().
*
* @note PropertyPools also store the properties of ghost particles,
* and consequently iterating over all handles also reaches the
* properties of ghost particles.
*/
std::set::iterator begin ()
{ return currently_open_handler.begin() }
+ same for the corresponding end() function.
If the properties are stored in a continuous block, one could easily write a
function that takes into argument a vector of property index, the value to set
and the number of particles for example. This function would then be called
from the particle handler which in turn would have an interface to this
function with the vector of property index and the value to set.
Would that be the right approach? If so, I can work on a PR.
PropertyPool doesn't advertise how it stores properties. Currently, it's not
in one large block, though that's something we might want to change at some
future point. The interface above avoids exposing how exactly they are stored.
Best
W.
--
Wolfgang Bangerth email: bange...@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/f8c034bf-621b-bc23-3c93-6c35be1d346b%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
I am not sur if I fully understand the memory structure of the Property Pool (or at least I am still confused by it). If I understand correctly, the properties of all the particles are stored in a single Handle array and the get_properties of a single particle returns an array view pointing to this large array. However, the n_properties_per_slot() returns the number of properties associated with a single particle. Is there a way to know from within the property pool the size of the handle array? If the properties are stored in a continuous block, one could easily write a function that takes into argument a vector of property index, the value to set and the number of particles for example. This function would then be called from the particle handler which in turn would have an interface to this function with the vector of property index and the value to set. Would that be the right approach? If so, I can work on a PR. On Monday, October 19, 2020 at 10:11:33 a.m. UTC-4 Wolfgang Bangerth wrote: > On 10/19/20 4:58 AM, blais...@gmail.com wrote: > > The issue is that this code is being called a lot (in our case every > > iteration, so 100k to 10M times) and each iteration is very fast (1k > iteration > > is a second or so). Consequently, we've had some severe issue when > timing in > > parallel. > > If nothing is wrong with the code I guess what I am seeing is just the > cost of > > iterating through the particle data structure and valgrind is confusing > me :). > > I'll try to see if I can combine this loop with another one. > > That's one option. Option 2 is to write an interface to the PropertyPool > class > that allows you to set to zero certain components of all particle > properties. > > 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/2cd315d9-f961-4dfc-befb-855f64ccb076n%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 10/19/20 4:58 AM, blais...@gmail.com wrote: The issue is that this code is being called a lot (in our case every iteration, so 100k to 10M times) and each iteration is very fast (1k iteration is a second or so). Consequently, we've had some severe issue when timing in parallel. If nothing is wrong with the code I guess what I am seeing is just the cost of iterating through the particle data structure and valgrind is confusing me :). I'll try to see if I can combine this loop with another one. That's one option. Option 2 is to write an interface to the PropertyPool class that allows you to set to zero certain components of all particle properties. Best W. -- Wolfgang Bangerth email: bange...@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/de251984-eb44-b4d5-e511-5f0869f80cf6%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
The issue is that this code is being called a lot (in our case every
iteration, so 100k to 10M times) and each iteration is very fast (1k
iteration is a second or so). Consequently, we've had some severe issue
when timing in parallel.
If nothing is wrong with the code I guess what I am seeing is just the cost
of iterating through the particle data structure and valgrind is confusing
me :). I'll try to see if I can combine this loop with another one.
Thank you very much for the time and the help!
On Sunday, October 18, 2020 at 10:26:35 p.m. UTC-4 Wolfgang Bangerth wrote:
> On 10/17/20 3:50 PM, blais...@gmail.com wrote:
> > Maybe it is callgrind that is playing tricks on me.
> > Here is the code :
> >
> > for (auto particle = particle_handler.begin();
> > particle != particle_handler.end();
> > ++particle)
> > {
> > // Getting properties of particle as local variable
> > auto particle_properties = particle->get_properties();
> >
> > // Reinitializing forces and momentums of particles in the system
> > particle_properties[DEM::PropertiesIndex::force_x] = 0;
> > particle_properties[DEM::PropertiesIndex::force_y] = 0;
> >
> > particle_properties[DEM::PropertiesIndex::M_x] = 0;
> > particle_properties[DEM::PropertiesIndex::M_y] = 0;
> >
> > if (dim == 3)
> > {
> > particle_properties[DEM::PropertiesIndex::force_z] = 0;
> > particle_properties[DEM::PropertiesIndex::M_z] = 0;
> > }
> > }
> >
> > With dim a template parameter of the class.
> > The index for the particle properties are part of an enum:
> > enum PropertiesIndex : int
> > {
> > type = 0,
> > dp = 1,
> > rho = 2,
> > v_x = 3,
> > v_y = 4,
> > v_z = 5,
> > acc_x = 6,
> > acc_y = 7,
> > acc_z = 8,
> > force_x = 9,
> > force_y = 10,
> > force_z = 11,
> > omega_x = 12,
> > omega_y = 13,
> > omega_z = 14,
> > mass = 15,
> > mom_inertia = 16,
> > M_x = 17,
> > M_y = 18,
> > M_z = 19,
> > displacement_x = 20,
> > displacement_y = 21,
> > displacement_z = 22,
> > n_properties = 23,
> > };
> >
> >
> > I was not sure on what would be the best data structure to identify the
> data
> > in the particle properties, hence this type of enum (which I know is
> maybe not
> > ideal but...)
> >
> > Do you have any suggestions? Could it just be the cost of iterating
> through
> > the map that callgrinds wrongly affects to the zeroing of the variables?
>
> The code looks ok. I have no idea why that shows up so highly in your
> profiles, but would check this with a TimerOutput section like we use in
> other
> tutorial programs. This also tells you how often the code is actually
> called.
> I suspect that valgrind is giving you inaccurate information.
>
> 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/5e415aba-d265-4f43-ac80-7c3773fb8c35n%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
On 10/17/20 3:50 PM, blais...@gmail.com wrote:
Maybe it is callgrind that is playing tricks on me.
Here is the code :
for (auto particle = particle_handler.begin();
particle != particle_handler.end();
++particle)
{
// Getting properties of particle as local variable
auto particle_properties = particle->get_properties();
// Reinitializing forces and momentums of particles in the system
particle_properties[DEM::PropertiesIndex::force_x] = 0;
particle_properties[DEM::PropertiesIndex::force_y] = 0;
particle_properties[DEM::PropertiesIndex::M_x] = 0;
particle_properties[DEM::PropertiesIndex::M_y] = 0;
if (dim == 3)
{
particle_properties[DEM::PropertiesIndex::force_z] = 0;
particle_properties[DEM::PropertiesIndex::M_z] = 0;
}
}
With dim a template parameter of the class.
The index for the particle properties are part of an enum:
enum PropertiesIndex : int
{
type = 0,
dp = 1,
rho = 2,
v_x = 3,
v_y = 4,
v_z = 5,
acc_x = 6,
acc_y = 7,
acc_z = 8,
force_x = 9,
force_y = 10,
force_z = 11,
omega_x = 12,
omega_y = 13,
omega_z = 14,
mass = 15,
mom_inertia = 16,
M_x = 17,
M_y = 18,
M_z = 19,
displacement_x = 20,
displacement_y = 21,
displacement_z = 22,
n_properties = 23,
};
I was not sure on what would be the best data structure to identify the data
in the particle properties, hence this type of enum (which I know is maybe not
ideal but...)
Do you have any suggestions? Could it just be the cost of iterating through
the map that callgrinds wrongly affects to the zeroing of the variables?
The code looks ok. I have no idea why that shows up so highly in your
profiles, but would check this with a TimerOutput section like we use in other
tutorial programs. This also tells you how often the code is actually called.
I suspect that valgrind is giving you inaccurate information.
Best
W.
--
Wolfgang Bangerth email: bange...@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/06722fd1-eb60-37af-d924-58145e61cc18%40colostate.edu.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
Maybe it is callgrind that is playing tricks on me.
Here is the code :
for (auto particle = particle_handler.begin();
particle != particle_handler.end();
++particle)
{
// Getting properties of particle as local variable
auto particle_properties = particle->get_properties();
// Reinitializing forces and momentums of particles in the system
particle_properties[DEM::PropertiesIndex::force_x] = 0;
particle_properties[DEM::PropertiesIndex::force_y] = 0;
particle_properties[DEM::PropertiesIndex::M_x] = 0;
particle_properties[DEM::PropertiesIndex::M_y] = 0;
if (dim == 3)
{
particle_properties[DEM::PropertiesIndex::force_z] = 0;
particle_properties[DEM::PropertiesIndex::M_z] = 0;
}
}
With dim a template parameter of the class.
The index for the particle properties are part of an enum:
enum PropertiesIndex : int
{
type = 0,
dp = 1,
rho = 2,
v_x = 3,
v_y = 4,
v_z = 5,
acc_x = 6,
acc_y = 7,
acc_z = 8,
force_x = 9,
force_y = 10,
force_z = 11,
omega_x = 12,
omega_y = 13,
omega_z = 14,
mass = 15,
mom_inertia = 16,
M_x = 17,
M_y = 18,
M_z = 19,
displacement_x = 20,
displacement_y = 21,
displacement_z = 22,
n_properties = 23,
};
I was not sure on what would be the best data structure to identify the
data in the particle properties, hence this type of enum (which I know is
maybe not ideal but...)
Do you have any suggestions? Could it just be the cost of iterating through
the map that callgrinds wrongly affects to the zeroing of the variables?
On Saturday, October 17, 2020 at 2:30:40 p.m. UTC-4 Wolfgang Bangerth wrote:
>
> > I was wondering if there was a more optimal way to do this? I have
> profiled it
> > with callgrind and it seems that getting the properties array view from
> the
> > particle can be really expensive.
> > Since what we want to achieve is just to set one of these properties to
> zero,
> > I was wondering if there was not a possible optimisation? For example,
> could
> > we just get the array view once and assuming its continuity, set all of
> the
> > same property to zero?
>
> That seems strange to me. The get_properties() function is in essence a
> one-liner with a few indirections. Can you show the code in which you set
> properties to zero?
>
> 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/674e23f3-3a66-48bb-8971-c68280eeb0d5n%40googlegroups.com.
Re: [deal.II] Clearing a particle properties without getting properties for each particle
I was wondering if there was a more optimal way to do this? I have profiled it with callgrind and it seems that getting the properties array view from the particle can be really expensive. Since what we want to achieve is just to set one of these properties to zero, I was wondering if there was not a possible optimisation? For example, could we just get the array view once and assuming its continuity, set all of the same property to zero? That seems strange to me. The get_properties() function is in essence a one-liner with a few indirections. Can you show the code in which you set properties to zero? Best W. -- Wolfgang Bangerth email: bange...@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/9608da77-8e1c-2355-7ce8-a5545df10766%40colostate.edu.
