Pseudocontact shift analysis problems

Topics related to Spinach package
Post Reply
Bomulos
Posts: 2
Joined: Fri Feb 11, 2022 3:49 pm

Pseudocontact shift analysis problems

Post by Bomulos »

Hi, Prof. Kuprov,

I have some questions about Pseudocontact shift analysis, specifically part 4a of the tutorial (http://spindynamics.org/wiki/index.php? ... ntre_model). I've computed my own cube files using ADF and Orca and I've encountered some wierd behavior of Spinach.

First of all, I would like to ask you about the .3d data format you are using - is there any tool that can generate it (I couldn't find anyting about in in Orca manual)? I tried to create my own .3d file from computed .cube files using scripts, but I've encountered problems with the function ocparse. It seems that Matlab couldn't load my files as it incorrectly loaded the first few lines of the .3d file. I was able to load the data explicitly by tweaking the code of ocparse function though.

Then, I would like to ask about the Kpcs.m function. I've generated .3d files for my studied Ru complex but it gives really non-sense values of PCSs. So to test my procedure, I tried to calculate my own .cube file of spin density of Cu complex using the same input as in the tutorial files. Then I've created a .3d file from it and it seems nearly identical to the file from tutorial (the only noticable difference is different size of the cube and therefore steps between the points, it is roughly 2x bigger). Yet, Spinach still failed to load it by ocparse function and used my workaround for it. After dealing with some memory issues (see the next part) it gives pretty similar numbers to the tutorial files, all of the PCSs are offset by 0.03 (which I guess is caused by some changes in Orca versions, I used Orca 4.2.1). I am attaching my input .3d file here.

Finally, about the memory issues, it seems that the Tutorial .3d files is processed much more easily by Spinach and doesn't use that much memory. All of my work was done on my laptop with 16 GB RAM. But when I used my .3d file for the tutorial Cu complex, it crashed becouse of insufficient memory. My workaroud was running all of the lines of Kpcs.m function one by one and deleting unnecessary variables in between them. By investigating the problem I've discovered that the tutorial input actually uses 400x400x400 matrices instead of 600x600x600 used by my input, even though the size of both cubes is the same. How is that possible and could you please tell me what I am doing wrong here?

Thank you so much for your help in advance!

Best regards
David Rajský
Attachments
Cu_Orca.zip
My input for Spinach
(6.29 MiB) Downloaded 57 times
kuprov
Posts: 123
Joined: Mon Mar 29, 2021 4:26 pm

Re: Pseudocontact shift analysis problems

Post by kuprov »

It would seem that latest versions of Matlab no longer automatically parse the text file as intended. I have updated the parser with more explicit assumptions about the header structure - use the enclosed.

Your density looks pretty good now.

Image

The best solution for the memory issue is to... well, add more memory! Think about it: 600x600x600 complex (because of Fourier transforms) double-precision floating point numbers mean 600x600x600x16 = 3.5 GB of data for just the density array. Then you need the PCS field array of the same size and a few more arrays of the same size for the various intermediate results and operators. It's a miracle even the example was running on your laptop! Sorry, mate - you need a proper computer for this.

The reason the dimension is knocked down somewhat in the example set is the zoom_3d function call: it trims the excessive zero padding.
Attachments
untitled.png
untitled.png (31.53 KiB) Viewed 1233 times
ocparse.zip
(1.31 KiB) Downloaded 51 times
Bomulos
Posts: 2
Joined: Fri Feb 11, 2022 3:49 pm

Re: Pseudocontact shift analysis problems

Post by Bomulos »

Thank you for the corrected function, it works well now. Regarding the memory issues, I've already tested Spinach on our university computers and I have no issues there. 16 GB of RAM was really too low!

I do still struggle with the kpcs function though, it gives really strange results. It seems that my script for conversion between .cube and .3d files is not giving the correct format. My question is then what is the correct format of the .3d file? Do you have a script for that? I've basically printed:
1st line - some title
2nd line - proportions of the cube (number of voxels)
3rd line - origin of the cube
4th line - size of voxels (from axis vector of voxels, only 1 value for each axis)
and then the points.

Using this I get much different result for the tutorial molecule than by using the tutorial input. But when I use the first four line from the tutorial input + points caluculated by me, it just works (that would be the case of the .3d file I sent here).

My other question would be about the pad_size parameter - how large it should be? I've noticed that changing it from 0 to 5 gives pretty different results for my data and I wonder, wheter that's ok.
kuprov
Posts: 123
Joined: Mon Mar 29, 2021 4:26 pm

Re: Pseudocontact shift analysis problems

Post by kuprov »

for the 3D file format, Spinach expects something similar to the example file (cu_porph_sd120.spindens.3d) - it's a text file, so should be easy to make sure that what you have is in the same format.

On the simulation side, make sure that:

1. The number of unpaired electrons is correctly set; it's a multiplier on the spin density.

2. That there is enough white space on all sides (pad_size parameter in porphyrin_example_3.m example file). This is important because the solver uses periodic boundary conditions (that's the only way to use the very efficient Fourier solvers) - so you must avoid unphysical self-interactions by leaving sufficient white space on all sides. Basically, increase pad_size until the answer stops changing.

3. That there are no contact hyperfine couplings! This is the most common problem - of course, PCS is only correct as a shift when there is no contact contribution. If there is a Fermi contact coupling between the electron spin density and the nucleus in question, you need to add it (the formula is simple, Gottfried had it in his papers somewhere).
Post Reply