Page 1 of 1

mlwf center positions of the output of AIMD

Posted: Tue Apr 16, 2024 12:05 pm
by luke419
Hello,

I'd like to ask mlwf center positions of the output of AIMD.
From the output file of AIMD, I performed water molecule-wise classification of "the mlwf center positions" and "O and/or H positions" for molecule-based dipole calculation.
Four mlwf centers positions and one O position and two H position would be taken for each of molecule-wise classifications.
The system consists of 64 water molecules.
For this, at the first mlwf and atomic position output of md.r, I tried to match two H positions and four mlwf center (not spread) positions to each of 64 O atoms.
My questions are as follows.

1. Would the order of atom index be maintained at the time series output of mlwf and/or atomic position (e.g., outputs at every 10 step)? Otherwise, would the atom index order change leading to a random order of atom index?

2. The DO length of D2O would be shorter than that of H2O.
Hence, I made the criterion of the nearest neighboring radius of 1.2 A for each O atom to find nearest neighboring two H atoms and four mlwf centers.
However, my analysis showed that many of mlwf center positions do not follow this while two H atoms are successfully found and listed for each of O atoms as shown below.

O_index:0 len(H_index_list):2 len(mlwf_index_list):3
O_index:1 len(H_index_list):2 len(mlwf_index_list):8
O_index:2 len(H_index_list):2 len(mlwf_index_list):4
O_index:3 len(H_index_list):2 len(mlwf_index_list):3
O_index:4 len(H_index_list):2 len(mlwf_index_list):4
O_index:5 len(H_index_list):2 len(mlwf_index_list):4
O_index:6 len(H_index_list):2 len(mlwf_index_list):3
O_index:7 len(H_index_list):2 len(mlwf_index_list):0
O_index:8 len(H_index_list):2 len(mlwf_index_list):4
O_index:9 len(H_index_list):2 len(mlwf_index_list):3
O_index:10 len(H_index_list):2 len(mlwf_index_list):1
O_index:11 len(H_index_list):2 len(mlwf_index_list):3
O_index:12 len(H_index_list):2 len(mlwf_index_list):3
O_index:13 len(H_index_list):2 len(mlwf_index_list):1
O_index:14 len(H_index_list):2 len(mlwf_index_list):4
O_index:15 len(H_index_list):2 len(mlwf_index_list):0
O_index:16 len(H_index_list):2 len(mlwf_index_list):3
O_index:17 len(H_index_list):2 len(mlwf_index_list):3
O_index:18 len(H_index_list):2 len(mlwf_index_list):4
O_index:19 len(H_index_list):2 len(mlwf_index_list):4
O_index:20 len(H_index_list):2 len(mlwf_index_list):4
O_index:21 len(H_index_list):2 len(mlwf_index_list):4
O_index:22 len(H_index_list):2 len(mlwf_index_list):0
O_index:23 len(H_index_list):2 len(mlwf_index_list):4
O_index:24 len(H_index_list):2 len(mlwf_index_list):4
O_index:25 len(H_index_list):2 len(mlwf_index_list):1
O_index:26 len(H_index_list):2 len(mlwf_index_list):5
O_index:27 len(H_index_list):2 len(mlwf_index_list):4
O_index:28 len(H_index_list):2 len(mlwf_index_list):4
O_index:29 len(H_index_list):2 len(mlwf_index_list):5
O_index:30 len(H_index_list):2 len(mlwf_index_list):5
O_index:31 len(H_index_list):2 len(mlwf_index_list):4
O_index:32 len(H_index_list):2 len(mlwf_index_list):4
O_index:33 len(H_index_list):2 len(mlwf_index_list):4
O_index:34 len(H_index_list):2 len(mlwf_index_list):6
O_index:35 len(H_index_list):2 len(mlwf_index_list):5
O_index:36 len(H_index_list):2 len(mlwf_index_list):4
O_index:37 len(H_index_list):2 len(mlwf_index_list):0
O_index:38 len(H_index_list):2 len(mlwf_index_list):0
O_index:39 len(H_index_list):2 len(mlwf_index_list):0
O_index:40 len(H_index_list):2 len(mlwf_index_list):4
O_index:41 len(H_index_list):2 len(mlwf_index_list):0
O_index:42 len(H_index_list):2 len(mlwf_index_list):1
O_index:43 len(H_index_list):2 len(mlwf_index_list):0
O_index:44 len(H_index_list):2 len(mlwf_index_list):3
O_index:45 len(H_index_list):2 len(mlwf_index_list):3
O_index:46 len(H_index_list):2 len(mlwf_index_list):3
O_index:47 len(H_index_list):2 len(mlwf_index_list):6
O_index:48 len(H_index_list):2 len(mlwf_index_list):6
O_index:49 len(H_index_list):2 len(mlwf_index_list):1
O_index:50 len(H_index_list):2 len(mlwf_index_list):4
O_index:51 len(H_index_list):2 len(mlwf_index_list):4
O_index:52 len(H_index_list):2 len(mlwf_index_list):0
O_index:53 len(H_index_list):2 len(mlwf_index_list):0
O_index:54 len(H_index_list):2 len(mlwf_index_list):5
O_index:55 len(H_index_list):2 len(mlwf_index_list):0
O_index:56 len(H_index_list):2 len(mlwf_index_list):4
O_index:57 len(H_index_list):2 len(mlwf_index_list):5
O_index:58 len(H_index_list):2 len(mlwf_index_list):4
O_index:59 len(H_index_list):2 len(mlwf_index_list):0
O_index:60 len(H_index_list):2 len(mlwf_index_list):5
O_index:61 len(H_index_list):2 len(mlwf_index_list):0
O_index:62 len(H_index_list):2 len(mlwf_index_list):1
O_index:63 len(H_index_list):2 len(mlwf_index_list):1

I use the length conversion from Bohr to Angstrom when the results was taken from md.r.
I think that the unit of mlwf center positions should be the same as that of atomic positions (i.e., Bohr). Is it right?
I attached the file of the first output named md_first_output.r.
Would you let me know what would be wrong with it?

Best regards,
Young

Re: mlwf center positions of the output of AIMD

Posted: Tue Apr 16, 2024 10:43 pm
by fgygi
Hello Young,
Note that the positions of the MLWF centers are always inside of the unit cell. The atomic positions can however move out of the cell (which means that they actually reenter the cell through periodic boundary conditions). If you want to associate the MLWF centers with molecules, you should make sure to compute the distances between atoms and MLWF centers by taking the periodic boundary conditions into account. This means that you should consider the shortest distance to the nearest periodic image of an atom.
There also seems to be a problem with the calculation you ran in md_first_output.r. It shows that the wave functions in the restart file gs.xml are not in the ground state. This is apparent from the value of the energy which is too high. You can compute the ground state using e.g. the following input file:

Code: Select all

h2o64.i
set ecut 65
set wf_dyn JD
set xc PBE
run -atomic_density 0 30 10
save gs.xml
where h2o64.i contains the initial coordinates. After you do that, you could use the following input file to run the MD simulation and compute the MLWF centers:

Code: Select all

load gs.xml
set xc PBE
set wf_dyn PSDA
set atoms_dyn MD
set dt 10
set iter_cmd compute_mlwf
set iter_cmd_period 10
run 100 5
save md2.xml
Last, I should mention that you will get good performance with 256 tasks (using 384 may not give significant speedup), and you may use the -nstb 2 command line argument to distribute the tasks better.

Best,
Francois

Re: mlwf center positions of the output of AIMD

Posted: Tue Apr 30, 2024 4:29 am
by luke419
Hello,

Many thanks for your answers, Francois.

1. May ask the meaning of "0 30 10" in run of gs.i and "100 5" in run of md.i in detail?
Even if we change 30 and/or 100 to other values (100 and 10000) for gs.i and md.i, respectively, would the values of "0, 10" and/or "5" be recommendable?
Would you let me know where I can find the usage of keyword of the qbox input file?
There is not "run" keyword in http://qboxcode.org/doc/html/usage/variables.html.

2. For 256 task, the use of "-nstb 2" is suggested.
Would you let me know how we can choose the best paramter value of -nstb for N task?
Will the use of "-nstb 2" be good for 512 task?

Best regards,
Young

Re: mlwf center positions of the output of AIMD

Posted: Mon May 06, 2024 3:01 pm
by fgygi
Hello,
1. Details of the run command can be found at http://qboxcode.org/doc/html/usage/commands.html#run .
2. The choice of the nstb parameter depends on the dimension of the Fourier transforms used in the calculation. This can be determined by looking at the value of the parameter np2v in the output. This is the size of the charge density Fourier grid in the z direction. If np2v = 128, for example, and the number of tasks used is larger than 128 (e.g. 256) it is more efficient to use a 128x2 process grid than a 256x1 process grid. This is achieved by using -nstb 2. If using 512 tasks, using -nstb 4 will results in a 128x4 process grid, which may be effective. Note that for a small problem, using 512 tasks may not lead to significant speedup.