Writing force file from arc file

[jacekkozuch]

Dear all,

(I wrote the same question in the tinker discussion board, but this one is more active. So, sorry for the duplicate)

I have seen that there's the option "save-forces" similar to "save-induced". However, till now I've only found how to print the ____.uind file after having already performed the MD production run (i.e. using the analyze option). Is there a way how to write the ____.force file in a similar way from and existing arc file?
If not, do you see an easy way how change a few lines in the analyze code (introduce another option for instance), so that this can be done? Doing this to the CPU-analyze code would be sufficient to me.

Thank you in advance!

Best
Jacek

[jayponder]

If you include the "SAVE-INDUCED" keyword with Tinker (a.k.a. "Tinker8", the CPU version), then a file *.uind with the induced dipole components on each atom will be written during an MD simulation and alongside the *.arc trajectory file.

Similarly, if you include the "SAVE-FORCE" keyword, a *.frc file will be written with the force components on each atom.

I believe (not 100% sure) that both of these keyword options are only available in CPU Tinker8, and are ignored by the GPU Tinker9 code. In order to maintain efficiency, many of these kinds of options that are available in Tinker8 are not included in the GPU version.

[jacekkozuch]

Thanks for the quick reply.

Yes, I'm aware of "SAVE-INDUCED" and "SAVE-FORCE". Actaully, I'm wondering how to get the *.uind and *.f files from a MD trajectory, i.e. arc file, that I already have, but for which I haven't written *.uind and *.f files.

The function ANALYZE provides the *.uind file after (some) options. But I'm not sure if there's an easy way to get the *.f file in a similar way?

One work around I thought of is to do a restrained/single point calculations with "SAVE-INDUCED" and "SAVE-FORCE". This would be just a bit messy, as single xyz files from an entire arc file would need to be calculated this way step by step. I know that GROMACS has the pretty neat option "-rerun" feature (https://manual.gromacs.org/current/user-guide/mdrun-features.html), which allows to feed in a trajectory and forces are recalculated. Maybe TINKER has something like this and I'm just not aware of this.

Thanks!

[zhi-wang]

I believe when an xyz arc file is saved, the velocities, induced dipoles, energy gradients, and accelerations are sent back to Tinker8, thus these keywords are supposed to work too. But there may be a bug regarding the GPU synchronization in Tinker9 for saving the force. I'm looking into it.

[jacekkozuch]

Hi Zhi,

Just to avoid confusion: I'm not implying that there is any bug in the code. I believe SAVE-INDUCED and SAVE-FORCE work.

However, what I am after is:
If I only have an *.arc file (no *.uind nor *.f, e.g., because I "forgot" to put those keywords in), how can I generate *.uind and *.f files afterwards?
I know that ANALYZE can generate *.uind files when saying:

analyze *.xyz -k *.key M # or with *.arc

Output:
...
...
...
Induced Dipoles Written To : *.uind

Is there a similar way to do something equivalent to ANALYZE, but obtain the *.f file?

[zhi-wang]

This would require some scripting. You can either use your favorite tools: awk, grep, python, etc, to loop over the arc file, and run testgrad9 on the file you generated, or you can use the utility archive in Tinker8 to "unzip" the arc file for you so you can run testgrad9 later. testgrad9 only gives you the total analytical gradient on the atoms, unlike the testgrad utility in Tinker8 which gives you a lot more details, so no extra command-line arguments are required. testgrad9 doesn't work on the arc file, but I am willing to add support if you think this will be useful.

[jacekkozuch]

That's exactly what I was after! Thx!
In principle it's not a big deal to use ARCHIVE beforehand to unzip the *.arc. However, it will create a bit of a mess after having saved 10 000 steps during the trajectory (what we typically do). Also, I can imagine that Tinker8/9 may do the job more efficientely, then using python & co to unzip, testgrad, zip *.f files.
Therefore, I think it would be convenient to have testgrad be able to do that ("testgrad8" would be sufficient for now). So, I think it depends on how much effort it would take to implement it onto testgrad in your opinion?
I'll take a look into the code.

[zhi-wang]

Adding this feature is very easy.

[jacekkozuch]

Just seen your the email about the new release! Thanks a lot! I'll test it and let you know if I observe any issues

[jacekkozuch]

Just a quick follow up question:
As I see it there is no simple way to print the r7 and r14 contributions of the vdw separately, right? Or is there by any chance a keyword that I missed that switches off one of the two?

[jayponder]

No, there is no easy way to print separate "r14" and "r7" terms, without doing a (simple) custom modification of the code. And it would not be particularly useful anyway- the buffered 14-7 is a single potential, and it's not really correct to say that the r14 term is "repulsion" and r7 is "dispersion".

[jacekkozuch]

Thanks for the explanation!