Skipping the setup of the request list if the NL if stride is 1

[Iximiel]

Description

This change speeds up the use of NL as a linked cells algorithm with stride set to 1

It changes the prepare step to acknowledge the change

Since I saw that the prepare step with the NL is in a few places, I also compacted that step in a method in the NL to propagate this, and any future changes.

I touched some non core module: maze and s2cm

---

Here's the effect of this code on a simple call on COORDINATION:

run name	steps	total time	time in calculate
no NL	200	42.081126	41.768990
using Linkcells with stride=1	200	14.712104	14.356958
using the Neighborlist with stride=1	200	47.810684	47.455588
using the Neighborlist with stride=40	200	2.487337	2.002722

run name	steps	total time	time in calculate
no NL	200	42.524496	42.202752
using Linkcells with stride=1	200	1.948613	1.634255
using the Neighborlist with stride=1	200	40.747972	40.427439
using the Neighborlist with stride=40	200	2.554561	2.034981

Target release

I would like my code to appear in release v2.11

Type of contribution

• changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
• changes to a module not authored by you
• new module contribution or edit of a module authored by you

Copyright

• I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.

• the module I added or modified contains a COPYRIGHT file with the correct license information. Code should be released under an open source license. I also used the command cd src && ./header.sh mymodulename in order to make sure the headers of the module are correct.

Tests

• I added a new regtest or modified an existing regtest to validate my changes.
• I verified that all regtests are passed successfully on GitHub Actions.

[Iximiel]

I do not know how the error in the derivatives of /basic/rt-mpi10 pops up:
The diff is the following (also for deriv.0 and deriv.1).

FAILURE
Diff for deriv.2:
676a677,685
>  0.250000 219  0.000
>  0.250000 220  0.000
>  0.250000 221  0.000
>  0.250000 222  0.000
>  0.250000 223  0.000
>  0.250000 224  0.000
>  0.250000 225  0.000
>  0.250000 226  0.000
>  0.250000 227  0.000
1579a1589,1597
>  0.450000 219  0.000
>  0.450000 220  0.000
>  0.450000 221  0.000
>  0.450000 222  0.000
>  0.450000 223  0.000
>  0.450000 224  0.000
>  0.450000 225  0.000
>  0.450000 226  0.000
>  0.450000 227  0.000
2026a2045,2053
>  0.550000 219  0.000
>  0.550000 220  0.000
>  0.550000 221  0.000
>  0.550000 222  0.000
>  0.550000 223  0.000
>  0.550000 224  0.000
>  0.550000 225  0.000
>  0.550000 226  0.000
>  0.550000 227  0.000

Those new 9 lines are suspicious because 9 is the size of the virial. There are 73 atoms processed by cgauss, so I should expect 219 values for the derivatives plus 9 for the virial, 228 in total (218,227 because we start from 0). I have no idea because why these pops ups for some steps after my modifications, nor if the problem was there before.

I ran grep for the 0th derivative and for the 227th derivatives, to check if the 227 derivative appears for all the steps or not. Click on this text for the results.

> grep '000 227' deriv.0.reference tmp/deriv.0.zfix 
deriv.0.reference: 0.150000 227  0.283
deriv.0.reference: 0.200000 227  0.339
deriv.0.reference: 0.300000 227  0.358
deriv.0.reference: 0.350000 227  0.369
deriv.0.reference: 0.400000 227  0.283
deriv.0.reference: 0.500000 227  0.182
deriv.0.reference: 0.600000 227  0.369
tmp/deriv.0.zfix: 0.150000 227  0.283
tmp/deriv.0.zfix: 0.200000 227  0.339
tmp/deriv.0.zfix: 0.250000 227  0.000
tmp/deriv.0.zfix: 0.300000 227  0.358
tmp/deriv.0.zfix: 0.350000 227  0.369
tmp/deriv.0.zfix: 0.400000 227  0.283
tmp/deriv.0.zfix: 0.450000 227  0.000
tmp/deriv.0.zfix: 0.500000 227  0.182
tmp/deriv.0.zfix: 0.550000 227  0.000
tmp/deriv.0.zfix: 0.600000 227  0.369

> grep '000 0' deriv.0.reference tmp/deriv.0.zfix
deriv.0.reference: 0.150000 0 -0.050
deriv.0.reference: 0.200000 0  0.001
deriv.0.reference: 0.250000 0  0.001
deriv.0.reference: 0.300000 0  0.000
deriv.0.reference: 0.350000 0  0.046
deriv.0.reference: 0.400000 0 -0.050
deriv.0.reference: 0.450000 0 -0.065
deriv.0.reference: 0.500000 0  0.001
deriv.0.reference: 0.550000 0  0.000
deriv.0.reference: 0.600000 0  0.046
tmp/deriv.0.zfix: 0.150000 0 -0.050
tmp/deriv.0.zfix: 0.200000 0  0.001
tmp/deriv.0.zfix: 0.250000 0  0.001
tmp/deriv.0.zfix: 0.300000 0  0.000
tmp/deriv.0.zfix: 0.350000 0  0.046
tmp/deriv.0.zfix: 0.400000 0 -0.050
tmp/deriv.0.zfix: 0.450000 0 -0.065
tmp/deriv.0.zfix: 0.500000 0  0.001
tmp/deriv.0.zfix: 0.550000 0  0.000
tmp/deriv.0.zfix: 0.600000 0  0.046

I am trying to understand what is the problem, but I can use some suggestions @GiovanniBussi

[Iximiel]

It might be that 3 atoms ( 3*3=9 for a coincidence) should drop from the list due to NL calculations? But the stride is 2, so that should appear in 2 consecutive steps and not on the 3rd, the 6th and on the 8th, shouldn't it be something like "2nd, 3rd then 6th,7th"?

[Iximiel]

@GiovanniBussi: I slept on it: i should use the Colvar call for requestatoms list instead of the actionatomistic one. I added the NL as a friend of Colvar, is that ok?

[GiovanniBussi]

Maybe it's cleaner to make the method public?

[Iximiel]

I do not know: RequestAtoms is also an ActionAtomistic non virtual public method, with nearly the same signature, (it has an extra the default boolean parameter).

I tried, for testing, to rename RequestAtoms in Colvar, without touching the code elsewhere. It compiles successfully, but of course plumed explodes in the tests.