imdt-gc algorithm detailed control of threading

[venturellac]

I would like to use imtd-gc with metadynamics and optimizations carried out with energies and gradients from GFN2-xtb. I am wondering if it is possible to have more detailed control of the utilization of OMP threads. For example, I want to devote all my threads/cores to one energy/gradient calculator and run each metadynamics run in serial.

With my CREST 3.0.1, I notice that each metadynamics runs on a single thread (if I have 6 metadynamics trajectories to do, CREST will put each one on one thread). This is not ideal if I have a more expensive energy calculator than GFNFF. Maybe this can be configured somehow, but I cannot find details. Any help would be greatly appreciated!

[pprcht]

Nested parallelism in OMP, unfortunately, is quite the annoying thing. The code technically is prepped to implement what you describe, but getting it to compile and run is a whole other issue. The problems arise (at least in parts) because the "pure" OMP parts and the linear algebra OMP parts (like intels MKL) fail to properly communicate with each other in nested OMP mode. So far I always ran into some troubles when attempting this.
If you'd like me to, I can look into it again, but currently all threads are automatically chosen and distributed automatically with no manual option available.

[venturellac]

Thank you for commenting on this - I just wanted to ensure I was using crest variables properly. Anyway, I believe this can be worked around by externally handling parallelism. For example, one can run independent xtb metadynamics runs in parallel, then subsequently run ensemble sorting and z matrix crossing in a separate calculation run.

[pprcht]

Technically, yes. However, since we switched to tblite from xtb as the tight-binding backend in 3.0, we won't be pursuing subprocess implementations any further (with some temporary exceptions for QCG and MSREACT). Also, on top of the subprocess bookkeeping, such workaround would also require a similar thread handling infrastructure that is needed for the nested parallelism (which already exists in the latter case).