Hi,
Note that you can specify what the isotope is using the value.set()
user function. The exact element is, from memory, only used when
calculating the centre of mass, so I don't think this is very
important for what you are calculating. It really depends what you
are doing here. HH appears only to be the hydroxyl proton in Tyr and
the terminal NH2 protons in Arg. HZ is attached to CZ in Phe, the
terminal NH3 protons in Lys, and protons attached to carbons in Trp.
Are you measuring NH2 and NH3 relaxation? If so, which theories would
you like to use to interpret the data?
I am measuring NH2 relaxation and will be using Lipari-Szabo Modelfree
Note that there is a problem with missing theory here. First you need
the CSA value. Then you need the dipole interaction vector, which in
this case is 2 actually vectors. In Abragam's relaxation equations
used in all model-free programs there is a key assumption which fails
- that the CSA tensor and the dipolar interactions are collinear.
Even if the CSA component of relaxation is negligible, the 2 NH
vectors point in different directions which will intersect the
diffusion tensor at different positions and hence have different
relaxation rates (the spectral density functions are direction
dependent, so different directions have different J(w) values). But
you also have movement of the sidechains causing this to be somehow
averaged out (I'm unaware of any theory for treating this yet). In
addition, you have crazy interference (cross-correlated relaxation)
between NH1, NH2, and H1H2. You will really have to see what others
have done before you to handle this mess, and then try to determine if
any model-free program out there will handle such a nightmare
situation (relax, Modelfree4, Dasha, and Tensor2 do not).
The internal reader accepts
these CONECT records perfectly. An easy test is to read in the PDB
file with CONECT records with the internal reader and then write it
out again. They should be preserved. If not, this is a bug which can
be reported at https://gna.org/bugs/?func=additem&group=relax which I
can then repair.
I think the mf_multimodel script uses the internal reader...what is the
command to read with the internal reader?
This is an argument to the structure.read_pdb() user function. This
now defaults to the internal reader.
This could be related to point 3 above. Did you see any optimisation
when running the script? Were there any RelaxWarning messages anyway
through the analysis?
Couldn't notice any warning message but it actually didn't seem to be doing
anything because all the values were the same.
Maybe if you created a bug report and attached to it some truncated
files (data and script) which reproduce the problem (the data subset
can be randomised if you are worried about it being online). If I can
run and test it myself, then I should be able to spot the problem
instantly and have a fix in hopefully ~5 min.
Cheers,
Edward
Re: MF_Multimodel