HanatoK

> > ### The problem of `colvardeps` > > From the perspective of compiler or interpreter, when constructing the CVC object in `colvar::cvc::cvc`, Colvars is still in the stage of...

> @jhenin's comment is good. There are multiple small fixes here that are definitely worth integrating, but they are mixed with others that pertain to broader design issues. > >...

> 1. Fewer TODOs and self-described hacks; Well, actually this PR was not intended to be merged into the master branch directly. Instead, I developed the code based on #644,...

> I do not see the two approaches as antithetical, either: (i) was just easier to implement than (ii), and there was also less pressure to implement (ii) in NAMD,...

It just reminds me that if we want to compute CVCs in parallel, we may need to lock the `get_group_force_object()` in https://github.com/Colvars/colvars/blob/2c6c712aba07f3de3044c5b4079a560cf2d9cea7/src/colvaratoms.cpp#L1487-L1489 Because CVCs A and B may rely on...

> How do we move forward on this? We can either: > > * merge this into the reusable-cvcs branch and continue work on [Allow reusing computation and data between...

> @HanatoK I do not understand why it has to be either one scheme, or the other. @giacomofiorin I have commented on this issue (see my comment above or https://github.com/Colvars/colvars/pull/700#issuecomment-2379669465)....

> You mean doing load balancing internally to Colvars? So far we've let charm++/openMP do the load balancing, and that hasn't been so bad. @jhenin Sorry, this might not be...

> > @jhenin Sorry, this might not be a load-balancing problem. Let's say if you distribute two threads on two CVCs, for example, a RMSD and a distance of two...

> > Do you mean parallelizing `distancePairs` or something else? Yes. For dihedrals we could have a similar thing like `dihedralTuples`. > > AFAIK Charm++ should give you support for...