Compute TI with pair_style hybrid & tail corrections

I am using compute ti with pair_style hybrid overlay and pair_modify tail yes.
While doing so, my results (version 2022) differed from original paper (version 2012) having a constant offset.

I tried the same again, this time by not using tail argument in compute ti.
Then averaging values of with & without tail corrections gave me correct tally with the original paper somehow indicating double counting of tail corrections.

Going over documentation revealed a patch in 2014 that when using pair_modify tail with pair_style hybrid, where tail contributions from sub-styles were not being summed to total energy.

My question is, that now in version 2022, while using compute ti with hybrid pair_style and tail corrections turned on, I then should not use tail keyword in compute ti at all as its already taken care of in thermodynamic integration and if tail keyword is used, it would result in double counting? Or is my understanding of using compute ti incorrect.

My results are shown in the picture and input file with tail corrections on and tail keyword in compute ti is also attached.


in.txt (2.1 KB)

I don’t think that what you observe is limited to hybrid potentials. The way compute ti accesses the tail correction is exactly the same for regular and hybrid potentials. So the question of double counting is more a question of what is the correct procedure. Please recheck the documentation of pair_modify. If I remember correctly, It states that the tail correction cannot be modified when scaling potential parameters and thus it would be incorrect to globally include the tail correction. If that is the case, then adding tail corrections with pair_modify would be incompatible with compute ti. But don’t take my word for it…

Thanks Axel.

  1. I tried to see if I can find anything about scaling of tail corrections in documentation. I couldn’t but I observed in ver 2012, thermo_custom etail is giving me scaled tail corrections with scaling potential parameter. But in 2022, etail is not scaled. This could be the reason of difference between 2012 & 2022 results as shown above.

  2. In v2012, evdwl did not contain etail. Whereas, current version does contain etail in evdwl. Now, based on how compute ti approaches these energies, could this be that, using tail argument in compute ti double counts the tail corrections → Once etail is already a part of evdwl and once additionally?

  3. In general, since etail is not scaling currently, way out could be using a long cutoff or using lj/long instead of lj/cut? I know this is a specific question about protocol, but I would appreciate if you could comment.

Thank you for your time & effort on this forum.