NPT length tuner increases the length steps instead of decreasing them

[rodolfo subert]

Dear all,

I am trying to perform an HPMC NPT simulation with self tuning box moves.
The tuners of the translation and rotation moves work fine.
The problem I face is that regardless the magnitude of the length.delta parameters I set in the barostat, the volume acceptance is systematically zero and the tuner, instead of decreasing the value of delta is constantly increasing it.

This how I set up the relevant parts of the code
I begin setting up the barostat

compress = hoomd.hpmc.update.BoxMC(trigger=npt_trigger, betaP=P)
compress.length = dict(delta=[v,v,v], weight=1) 
sim.operations.updaters.append(compress)

## Note that I tried arbitrary small values for delta changing the parameter v to values as small as 5e-9

# and the tuners

tune = hoomd.hpmc.tune.MoveSize.scale_solver(moves=['a', 'd'],
                                             target=0.2,
                                             trigger=tune_trigger,
                                             max_translation_move=0.2,
                                             max_rotation_move=0.2)
sim.operations.tuners.append(tune)

tune2 = hoomd.hpmc.tune.BoxMCMoveSize.scale_solver(
                                            trigger = tune_trigger,
                                            boxmc = compress,
                                            moves=['length_x', 'length_y', 'length_z'],
                                            target=0.2)
sim.operations.tuners.append(tune2)

To play around I set the triggers to 10 or 100 steps (the problem is independent on this vlaues) and then run the simulation for 5000 steps

Every 200 steps I print the values of the moves acceptance and some simulations observables in a list. Below that I print the values of the translation, rotation and volume deltas.
What I see is that the translation and rotation delta change accordingly to the acceptance rate and the target acceptance. Whereas the volume delta keeps increasing regardless the 0 acceptance rate.

['timestep', 'packing_fraction', 'translation_move', 'rotation_move', 'volume_move', 'Lx', 'Ly', 'Lz', 'time']

[700, 0.318534908870942, 0.4428940291724439, 0.1880721473258575, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 13.576036632061005]

delta d 6.009000749298016e-05
delta a 1.980025318797184e-05
delta v _HOOMDTuple(0.00055, 0.00055, 0.00055)

[900, 0.318534908870942, 0.4441006579793545, 0.1883455744438635, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 26.763997711241245]

delta d 7.229455317701591e-05
delta a 1.961950781363972e-05
delta v _HOOMDTuple(0.0006050000000000001, 0.0006050000000000001, 0.0006050000000000001)

[1100, 0.318534908870942, 0.4449258886483277, 0.18913114173598214, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 39.9447375908494]

delta d 8.707208510364456e-05
delta a 1.944722411236188e-05
delta v _HOOMDTuple(0.0006655000000000001, 0.0006655000000000001, 0.0006655000000000001)

[1300, 0.318534908870942, 0.44577450837202776, 0.19137436656047221, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 53.16437678784132]

delta d 0.00010489376710649355
delta a 1.944722411236188e-05
delta v _HOOMDTuple(0.0007320500000000001, 0.0007320500000000001, 0.0007320500000000001)

[1500, 0.318534908870942, 0.4453130766124889, 0.19072812816837648, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 66.3286330550909]

delta d 0.00012636944344091746
delta a 1.944722411236188e-05
delta v _HOOMDTuple(0.0008052550000000003, 0.0008052550000000003, 0.0008052550000000003)

[1700, 0.318534908870942, 0.4485105054496523, 0.1934278609919177, 0.0, 3.3789663314819336, 3.2984631061553955, 3.14772367477417, 79.59313233941793]
delta d 0.0001524947397255606
delta a 1.944722411236188e-05
delta v _HOOMDTuple(0.0008857805000000004, 0.0008857805000000004, 0.0008857805000000004)

Thank you in advance for your help,
Rodolfo

[Joshua Anderson]

Rodolfo,

I don't know what `volume_move` is in your output. HOOMD-blue provides counts of the number of accepted and rejected moves: https://hoomd-blue.readthedocs.io/en/v4.0.0/module-hpmc-update.html#hoomd.hpmc.update.BoxMC.counter. You can examine the count to see the total number of moves proposed. In hindsight, HOOMD should count length moves separately from volume moves - but for now at least counter.volume is the correct attribute to inspect.

Based on your box Lx,Ly,Lz output, there are many accepted volume moves. Note that Lz is increasing rapidly. Under the assumption that the acceptance rate for Lz moves is high, the tuner should be increasing the delta values to reduce the acceptance rate. Is your system 2D by chance? If so, set delta[3]=0.

------

Joshua A. Anderson, Ph.D.

Research Area Specialist, Chemical Engineering, University of Michigan

--
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/f9c66b01-7ea7-48c7-8d3d-3e82f6f51b9cn%40googlegroups.com.

[rodolfo subert]

Dear Joshua,
thank you for your quick answer.
My apologies for not being more specific in the observables printed
volume move is compress.volume_moves[0]/sum(compress.volume_moves), also Lz is constant in the data above, the last number that is rapidly increasing is time.
Also, the system is not 2D, the system is 3D.

I have kept playing with the compression parameters. Regardless their value I noticed that every time the volume tuner is triggered, the delta_lengths systematically increase by exactly 10%.
Am I maybe targeting a value of 0.2 for the deltas, rather than for the volume acceptance?

I have also tried to change the solver from scalar_solver to secant_solver, the behaviour is roughly similar.

Another possibility is that the tuner behaviour depends on the number of attempts rather than on the acceptance alone.

Do you have any other suggestion to understand the observed behaviour?

Thank you,
Rodolfo

[Joshua Anderson]

Rodolfo,

I would ignore the tuner for now. First understand what BoxMC is doing. I would start with a very small value for v, and examine the values of compress.volume_moves[0] and compress.volume_moves[1] to ensure they are as expected. Then I would check for any overlaps in the system (sim.integrator.overlaps). If there are existing overlaps, they would likely not be removed by a length move, causing every length move to be rejected.

With no overlaps in the starting configuration and a very small (but nonzero) v (e.g. 1e-6), there should be 1 total volume move per timestep and the majority of those moves should be accepted (I assume npt_trigger is hoomd.trigger.Periodic(1)).

------

Joshua A. Anderson, Ph.D.

Research Area Specialist, Chemical Engineering, University of Michigan

To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/f50c7c71-3f02-4bcc-b9d2-f8293a90f35an%40googlegroups.com.

[rodolfo subert]

Dear Joshua,
I understand your point, thank you for your help.