Confusion Regarding Volume Transfer for GEMC

[ruyeli]

Hello,

I am currently integrating a machine learning potential from my group with GOMC to evaluate its performance for GEMC simulations. While adapting the code to interface with our MLP, I've encountered an issue with the volume change mechanism in the VolumeTransfer::Transform() function defined in Volumetransfer.h.

The core of my issue lies in understanding how the max variable is calculated:

  if (GEMC_KIND == mv::GEMC_NVT) {
    double max = std::min(moveSetRef.Scale(bPick[0], mv::VOL_TRANSFER),
                          moveSetRef.Scale(bPick[1], mv::VOL_TRANSFER));
    if(isOrth) {
      coordCurrRef.VolumeTransferTranslate(state, newMolsPos, newCOMs, newDim,
                                           comCurrRef, max, bPick);
    } else {
      coordCurrRef.VolumeTransferTranslate(state, newMolsPos, newCOMs,
                                           newDimNonOrth, comCurrRef, max, bPick);
    }
  }

From what I gather, max serves as the control parameter for the volume change, dictating the range (-max, max) for random volume adjustments of one box while the other box scales correspondingly. However, I am unable to locate the moveSetRef.Scale() function within the source code. My current understanding, based on the code snippet moveSetRef.scale = chkObj.scaleVec; found in CheckpointSetup.cpp, suggests that max might be derived from previous volume change data stored in a checkpoint file, influencing the new volume change range.

Could you clarify how max is determined? Any insights or documentation regarding this would be greatly appreciated.

Thank you.

[LSchwiebert]

Your research project sounds very interesting. If you can share your results with us once you complete your work, that would be greatly appreciated.

Your understanding is correct for the case where we are restarting from a checkpoint file. In that case, we have some information about a good choice of a maximum volume transfer. In general, however, we adjust the maximum volume transfer based on the AdjSteps parameter in the configuration file. Every "AdjSteps" moves, we check the ratio of accepted Volume Transfers based on the number of attempted volume moves during that interval. If the ratio of accepted moves is greater than 50%, then we increase the maximum -- if the ratio is less than 50%, then we decrease the maximum.

If you take a look at issue #525 and the corresponding pull request #526, you can see that we recently changed the maximum volume transfer to avoid some rare cases where we could try to transfer too much volume. The simulation would terminate with an error message -- it would not produce incorrect results. If you look at pull request #526, you will see exactly where in the code the maximum volume transfer amount is computed.

This patch is not yet in the code, but I expect that we will merge it soon into the development branch, and hopefully in the near future release a new version of GOMC.

If you have further questions about this or other aspects of the code, please feel free to ask. (For questions about other aspects of the code, please open a new issue. You may close this issue once you decide that it has been fully answered.)

[ruyeli]

Thank you for your insights and for taking the time to explain the code! I totally understand now. I appreciate your interest in our project and will certainly share our findings with you once our research is complete.

[LSchwiebert]

Glad that explanation was sufficient.

Thanks. Looking forward to seeing the results.