UT theoretical chemistry code forum

1. Is DISPLACECAR put in each subdirectories ./01 to ./NN?

2. How many dynamical matrices do we have at last?

Thanks for your help in advance!!!

A dynamical matrix (dynmat) calculation is done on a single POSCAR, which should be in the main directory, just as in a regular vasp run. You don't need any subdirectories for this calculation.

You need to generate one DISPLACECAR, indicating which atoms are going to be displaced, and set NSW in your INCAR file to be the number of degrees of freedom, plus 1.

The calculation will generate a dynamical matrix for your POSCAR, which you can diagonalize to get the normal modes.

In order to calculate prefactors, you need to do two dynmat calculations, one for the POSCAR containing the initial state, and one for the POSCAR containing the saddle point configuration. Once you have the normal modes at the initial state, and the positive modes at the saddle, you can multiply and divide them in the appropriate way to get the prefactor:

v = Prod[initial state modes] / Prod [positive saddle point modes]

(you might need a factor of 2*Pi if depending if you are using angular frequencies)

I was asking about a parallel run. It seems to me that you are talking about a single run. Anyhow, I got great help. Could I ask further questions?

1. Can we use "dynprefactor.pl" script to get the final answer, prefactor?

Yes, dymprefactor.pl should work for you. Note that the input files are supposed to have two columns each. The first is the magnitude of the frequency in cm^-1 and the second on is either 0 or 1, depending on if the the corresponding mode is real or imaginary, respectively. I guess the units of frequency is not important because the prefactor is going to have the same units as the input files.

Discussion are taken place if the multi folder runs for dynmat should be made obsolete.

Please report any problems or questions to the forum.

Andri

I see now that this parallel run dynmat stuff is at the top of our dynmat webpage. This makes no sense. I have never actually run the dynamical matrix in this way. It's fine that it's there, but we should emphasis the normal way of running it, and put this parallel stuff at the bottom.

And just to be clear, this is a parallel-over-images way of running dynmat. The regular, one image, dynmat can be run in parallel without modification.

One reason the parallel-over-images version is not very important, is that you can do the same thing with a set of separate single-image dynmat jobs, where each calculates a subset of the displacements.

Hi,

Just my two cents. The parallel version of the code was set up so you could get through all of the degrees of freedom you want to displace more quickly. It's true that you could do it all in multiple single processor runs, but the parallel version was meant to be a bit more convenient. You didn't need to generate separate DISPLACECAR files, just one, and the code would figure out which processor did which displacements.

It's been a while since I ran this way, but you should only need one DISPLACECAR. You need to make sure that the number of displacements you want to do is a multiple of the number of processors you have. Finally, I think at the end you have a number of OUTCARs equal to the number of processors and that you need to run a script (the dymmatrix.pl script, I believe). This will generate the dynamical matrix from each of those OUTCARs.

One last comment. This mode is to do the displacements on the same POSCAR, not multiple POSCARs. Its only goal is to get the displacements done faster, that's all.

Blas

The mentioned perl script is not dymmatrix.pl but dymmake.pl or make_matrix.pl

In the latest version of the scripts, both in cvs and in the tar.gz file, the script should be called dynmatrix.pl. We are trying to restructure the script names so that they start with a prefix indicating the method, {dym, neb, dim} and no prefix for general scripts. This makes it a bit easier to keep track of them, and to find what is available using autocomplete.