variable in the nested loop of PairHybrid::single method

LAMMPS LAMMPS Mailing List Mirror
1

Hi,

Is the variable “int m” used in PairHybrid::Single supposed to be used in a nested loop? (version: Aug 25, 2019, git commit: 0b34db78 of LAMMPS; lines 762, 778)

Although I do not have any simulations which makes me think that it is a bug, I do not understand why the use of the same variable name is not a problem. Please let me know if you can help me understand this section of code.

Regards,
Ranga

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2

Hi,

Is the variable “int m” used in PairHybrid::Single supposed to be used in a nested loop? (version: Aug 25, 2019, git commit: 0b34db78 of LAMMPS; lines 762, 778)

Although I do not have any simulations which makes me think that it is a bug, I do not understand why the use of the same variable name is not a problem. Please let me know if you can help me understand this section of code.

this appears to be a bug and a conceptual problem. but then again, this feature is only used in granular pair styles and it is rather uncommon that multiple of those are used as hybrid or hybrid/overlay styles.

a more generic and compatible solution should be included in a future patch.

axel.

3

Thanks Axel,

I do have a use case for hybrid, hybrid/overlay style using granular pair styles. In simulations of dense suspensions, we use particles that interact with granular pair styles and lubrication forces. I think there may be some other people who use LAMMPS to do suspension simulations as well; see, for e.g., DOI: 10.1126/sciadv.aar3296.

For my suspension simulations, I wanted to output both the granular contact and lubrication forces at some interval of time. To do this, I took the approach 1 below.

  1. I have modified and extended the lubricate pair style to output forces during run time using the “svector”. Just adding a new variable in the inner loop of pairHybrid::single seems to be a quick fix for this bug.

  2. I could have followed a different route of calculating the lubrication forces by re-running the dump file. Since granular forces are history dependent, it is not correct to recalculate them using dump.
    However, I think, approach 2 may not be accurate: since using single and pair/local outputs forces at half step of time integration, but, dump will output positions and velocities at the end of each time step.

Please correct me if I am mistaken in the two statements above.

Regards,
Ranga

4

Thanks Axel,

I do have a use case for hybrid, hybrid/overlay style using granular pair styles. In simulations of dense suspensions, we use particles that interact with granular pair styles and lubrication forces. I think there may be some other people who use LAMMPS to do suspension simulations as well; see, for e.g., DOI: 10.1126/sciadv.aar3296.

For my suspension simulations, I wanted to output both the granular contact and lubrication forces at some interval of time. To do this, I took the approach 1 below.

  1. I have modified and extended the lubricate pair style to output forces during run time using the “svector”. Just adding a new variable in the inner loop of pairHybrid::single seems to be a quick fix for this bug.

no. you will have a race condition with the unmodified code. with hybrid/overlay, whatever pair style is defined second sub-style will override what is copied from the first and also it will only support the number of entries that are the smaller number of either pair sub-style.

the IMO clean solution would be what is done in the pending pull request #1662
https://github.com/lammps/lammps/pull/1662

axel

5

Hi Axel,

Thanks for the quick reply and for a better solution in the pull. I agree that concatenating the pair_hybrid’s svector with new elements is be a better way to handle this.

In my previous non-general tweak for my specific case, I had avoided the race conditions by changing two pair styles to have the same number of elements for svector - with zeros for the unused elements in each of the pair styles. I summed up the svector elements from the different sub-styles in a modified pair_hybrid file. That also seemed to work fine.

Regards,
Ranga