[giacomofiorin]

Currently, GlobalMaster (GM) is a required component of the default interface between NAMD and Colvars; this class interacts with the class colvarproxy_namd to communicate all data related to atoms, groups and unit cell.

CUDAGlobalMaster (CUDAGM) (see #783) is an alternative interface that is much faster in GPU-resident runs, but does not support the other use cases (pure CPU or GPU-offload), or some specialized features of GlobalMaster. Additionally, the CUDAGM client bundled in namd/cudaglobalmaster folder currently uses a different class to interact with Colvars, called colvarproxy_impl, which duplicates some but not all of the code of colvarproxy_namd.

This PR aims to unify the colvarproxy_impl and colvarproxy_namd classes, so that the end product (still called colvarproxy_namd for consistency) can handle both GM and CUDAGM interfaces.

[giacomofiorin]

@HanatoK The commits up until the last one ensure that the colvarproxy_namd object uses the GlobalMaster object only if the latter is defined. All the regtests pass, and I'd be okay with putting it up for review as is.

The latest commit is entirely generated by Copilot, and it combines improvements to colvarproxy_impl with its merge into colvarproxy_namd. I'm gonna try tomorrow to separate the changes into multiple commits

[giacomofiorin]

I'm gonna try tomorrow to separate the changes into multiple commits

The Copilot changes are now split in the three latest commits.

[HanatoK]

I am afraid that this PR would break the CUDAGM plugin build if merged. The original colvarproxy_cudaglobalmaster.C was written without including any Charm++ header files. Is it possible to separate the Charm++ related members in the colvarproxy_namd class to only the GM interface?

[giacomofiorin]

I am afraid that this PR would break the CUDAGM plugin build if merged. The original colvarproxy_cudaglobalmaster.C was written without including any Charm++ header files. Is it possible to separate the Charm++ related members in the colvarproxy_namd class to only the GM interface?

Thanks! As I was afraid, we're not that close to full integration unfortunately. I'm going to create a separate PR for the colvarproxy_namd refactoring specifically, so we can review/merge that and come back to this afterwards, hopefully as a stacked PR