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, [email protected] 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: [email protected] > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5e415aba-d265-4f43-ac80-7c3773fb8c35n%40googlegroups.com.
