Support full initialization of volumetric maps within Colvars #737
Conversation
giacomofiorin
force-pushed
the
internalize-gridforces
branch
from
10238ef to
6c2ac5b
Compare
giacomofiorin
changed the title
|
It seems with this PR and NAMD's main branch, the interface volmap tests are still failed either in the CPU build or in the GPU build. Do I miss something? |
Correct, this PR tries to fix the issue of NAMD raising an error when gridForces are defined with GPU-resident, even if they are never meant to be used on the GPU. By making Colvars load them instead, the user's intent is much clearer. The issue of NAMD main no longer supporting reduction via ComputeGlobal (on any hardware configuration) still remains unaddressed. |
giacomofiorin
force-pushed
the
internalize-gridforces
branch
2 times, most recently
from
bae0383 to
42ed8ad
Compare
Here, the main test is that numatoms (computed with internal loops) is equal to numatoms_ref (computed by NAMD)
Also remove a few heap allocations
Allow different deformation amplitude between leaflets, small fixes Fix reading input from --deformation-map-mask option Issue identified by @1004parky, mask map was initialized to 1 in all cases. Silence NumPy warnings Small fixes Fix handling of PDB files in generated VMD input Make single-map CVs optional Allow customizing selection for COM and orientation restraints Make generated NAMD and VMD scripts more uniform Unify writing of Colvars input between NAMD and VMD Add support for mapFile keyword
giacomofiorin
force-pushed
the
internalize-gridforces
branch
from
42ed8ad to
4c45a16
Compare
|
Is this ready for review? |
|
@jhenin I have a few jobs that showed discontinuities upon restarting: likely a PBC issue. I converted it back to draft accordingly. |
Currently, volumetric map and Multi-Map variables (link) are implemented in NAMD in two ways:
MGridForcekeywords, with atoms selected byMGridForceFileand scalable computation over multiple processors/nodes (more efficient)MGridForcekeywords, but with atoms selected internally by Colvars and computation done on rank 0 (more flexible)The first approach only works for CPU-only and GPU-offload code path, with the exception of the current NAMD
mainbranch, where agridForcesoverhaul has temporarily removed the ability by Colvars to access the NAMD volumetric maps on any platform including CPU-only.The second approach can theoretically work in any mode: however, NAMD 3.0 GPU-resident raises an error if any volmap-related options are defined (link).
This PR attempts to solve the second issue by having Colvars load directly OpenDX maps without touching NAMD data structures, through the new
mapFilekeyword. This is also supported in VMD, but its implementation still loads the map through VMD (simpler and more robust in an interactive workflow). In either case, future implementations that do not rely on NAMD or VMD internal code could be easily swapped in.