Crest performance on Ubuntu virtual machine in Azure

[meghnashankar]

Hi, I am a student new to Crest, and I am trying to find conformers for molecules that range from 80-300 atoms. I initially tried to run crest through WSL Ubuntu 20.04 on my laptop, but then I discovered that since my laptop only has 4 cores, it is not able to run Crest on even the 80 atom molecules in a reasonable amount of time. Just to experiment, I bought an Ubuntu 20.04 VM on Azure with 48 cores. I've been trying to run a test 80 atom molecule on that, but since I ssh into the VM, occasionally my connection will be reset and crest appears to stop running. After I ssh back in, I run ps and crest is not shown to be running, and there are no files crest_conformers.xyz etc. I would hope that crest would continue to run even when I am not connected to the VM, but that doesn't appear to be the case. Is there no way around this?

Additionally, could anyone help me figure out an appropriate number of cores and amount of time for these optimizations to run? Right now I'm just running the command crest molecule.xyz -T <number of threads> but I would appreciate suggestions for other command line arguments that would be useful in this case. I'm trying to find the lowest energy conformational isomers so that I can run DFT calculations on them.

[myshevchuk]

Use a terminal multiplexer such as screen or tmux.

[tobigithub]

@meghnashankar Regarding your first problem that is solved with the nohup command. See https://linuxhandbook.com/nohup-command/

Regarding your processor question, I think, any processor is fine, but 64-128 cores are better. Probably check the correct runs with lscpu and top or htop. Example for Stanozolol with 40 atoms (smaller example) on system with 128 CPU cores (not threads) runs in 4 minutes on 128 CPU cores.

1. Get the preoptimized structure from PubChem or provide reasonable start structure.
2. Optimize the structure again with xtb --opt thight or extreme

wget -O "stanozolol.mol"   "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/stanozolol/SDF?record_type=3d"
xtb --opt thight stanozolol.mol -T 128

XTB preoptimization will finish in 3 seconds wall time:

           -------------------------------------------------
          | TOTAL ENERGY              -71.285033875679 Eh   |
          | GRADIENT NORM               0.000387923885 Eh/α |
          | HOMO-LUMO GAP               4.753017438285 eV   |
           -------------------------------------------------

------------------------------------------------------------------------
 * finished run on 2021/10/18 at 15:40:20.014
------------------------------------------------------------------------
 total:
 * wall-time:     0 d,  0 h,  0 min,  2.287 sec
 *  cpu-time:     0 d,  0 h,  2 min, 24.350 sec
 * ratio c/w:    63.109 speedup
 SCF:
 * wall-time:     0 d,  0 h,  0 min,  0.187 sec
 *  cpu-time:     0 d,  0 h,  0 min,  9.724 sec
 * ratio c/w:    51.979 speedup
 ANC optimizer:
 * wall-time:     0 d,  0 h,  0 min,  1.578 sec
 *  cpu-time:     0 d,  0 h,  1 min, 55.079 sec
 * ratio c/w:    72.913 speedup

3. Run crest with the conformer option and the correct number of CPU cores (not threads). In this case I choose 128 cores, because that is the correct lscpu core count, but the thread count is 256 and that would choke the system and make the computation much longer. For other systems adjust the value, but never set it higher that the true CPU core count. In case of xyz files start with "xtbopt.xyz"

crest xtbopt.mol -T 128 | tee conformer-output.txt

or if you are concerned about interrupts run with nohup, tee is actually not needed you can just redirect to a normal file.

nohup crest xtbopt.mol -T 128 | tee conformer-output.txt &

4. Use htop or top to check that crest is running, it should saturate the system up to the CPU core count. Then wait, wait, wait. htop should lool like this, roughly half the threads working (hence all CPU cores). In many cases the CPUs have 2 threads per core, if that is turned on/off adjust accordingly.

5. After few minutes (four minutes in this case) there will be a result.

T /K                                  :   298.15
E lowest                              :   -71.28504
ensemble average energy (kcal)        :    0.206
ensemble entropy (J/mol K, cal/mol K) :   35.541    8.495
ensemble free energy (kcal/mol)       :   -2.533
population of lowest in %             :   53.081
 number of unique conformers for further calc            3
 list of relative energies saved as "crest.energies"

 -----------------
 Wall Time Summary
 -----------------
             test MD wall time :         0h : 0m : 6s
                 MTD wall time :         0h : 1m :55s
      multilevel OPT wall time :         0h : 1m :22s
                  MD wall time :         0h : 0m :34s
                  GC wall time :         0h : 0m : 0s
--------------------
Overall wall time  : 0h : 4m : 0s

 CREST terminated normally.

6. Benchmarking is a must. For molecules with 40-80 or even 100-300 atoms you might want to pick some examples, smaller first, then larger and make an regression time estimate by plotting the number of atoms (rotatable bonds) vs the CREST time. You need to pick smaller benchmark molecules that are relevant to your large molecules in terms of possible stereocenters, rotatable bonds etc. Once that is done you can scale to 100 atoms or more.

7. If these small examples calculate in a reasonable amount of time, you can use machines with 100 Cores like XeonPlatinum 8180M 2.5GHz or AMD EPYCs with 128 cores. I found the AMD EPYCS perform a bit better with crest than the Xeons, could be the interconnect or memory architecture, but I am not quite sure. Choose a high IOPS SSD for storage. But I would never just calculate random large molecules, because we don't know what the time estimates are.

8. Same goes for DFT, where many DFT codes actually do not scale with higher CPU core counts, with few exceptions of course like ONETEP. Here even more scaling benchmarks need to be done across multiple nodes of course.

[github-actions[bot]]

This issue had no activity for 6 months. It will be closed in 1 week unless there is some new activity.