2,652
edits
Spot2pdb: Difference between revisions
Jump to navigation
Jump to search
→Notes
(→Notes) |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[ | [https://{{SERVERNAME}}/pub/linux_bin/spot2pdb spot2pdb],[https://{{SERVERNAME}}/pub/sources/spot2pdb.f90] is a jiffy that creates pseudo-PDB files for visualization of reciprocal space, based on <code>SPOT.XDS</code> and <code>XPARM.XDS</code>. The "atom" positions in the pseudo-PDB files are actually reflections positions in reciprocal space. | ||
The usage is simple: just run | The usage is simple: just run | ||
| Line 20: | Line 20: | ||
== Examples == | == Examples == | ||
[[File:insu6A.png]] | [[File:insu6A.png|400px|thumb|left|Indexed spot positions are yellow, un-indexed ones red.]] | ||
[[File:insu6AplusED.png|400px|thumb|right|Same, but with pseudo electron density. The offset between spot positions and electron density is due to a slight error in the header values of ORGX, ORGY (see [[spot2pdb#Notes|Notes]] below).]] | |||
<br clear=all>Examples with wrong ROTATION_AXIS: | |||
[[File:backwardsrotaxis.png|400px|thumb|left|ROTATION_AXIS is -1 0 0 instead of 1 0 0]] | |||
[[File:backwardsrotaxis2.png|400px|thumb|right|another view of result with rotation axis backwards]] | |||
[[File:wrongrotaxis.png|400px|thumb|left|ROTATION_AXIS is 0 1 0 instead of 1 0 0]] | |||
[[File:wrongrotaxis2.png|400px|thumb|right|another view of result with rotation axis 90° off]] | |||
<br clear=all> | |||
== Notes == | == Notes == | ||
* the mapping used by <code>dials.rs_mapper</code> uses the (unrefined) frame header values, and possibly assumptions (as implemented in <code>iotbx.detectors</code>) about geometry aspects, like ROTATION_AXIS, not stored in the header. On the other hand, XPARM.XDS may have different assumptions about geometry aspects, and uses the geometry as refined by IDXREF. Ideally, these two mappings should agree. | * the mapping used by <code>dials.rs_mapper</code> uses the (unrefined) frame header values, and possibly assumptions (as implemented in <code>iotbx.detectors</code>) about geometry aspects, like ROTATION_AXIS, not stored in the header. On the other hand, XPARM.XDS may have different assumptions about geometry aspects, and uses the geometry as refined by IDXREF. Ideally, these two mappings should agree. | ||
* Since <code>dials.rs_mapper</code> uses the STARTING_ANGLE information from the frame headers, the mappings can only agree if <code>XDS.INP</code> also has this item. [[generate_XDS.INP]] versions since 0.82 write <code>XDS.INP</code> with STARTING_ANGLE information | * Since <code>dials.rs_mapper</code> uses the STARTING_ANGLE information from the frame headers, the mappings can only agree if <code>XDS.INP</code> also has this item. [[generate_XDS.INP]] versions since 0.82 write <code>XDS.INP</code> with STARTING_ANGLE information for most detectors. | ||
* if no <code>XPARM.XDS</code> exists, | * if no <code>XPARM.XDS</code> exists, spot2pdb uses [https://{{SERVERNAME}}/pub/linux_bin/generate_XPARM.XDS XDS.INP as a source of geometry information]. | ||
* <code>coot</code> connects atoms that are close, have residue numbers differing by at most 1, and are in the same chain, with bonds (lines). The program makes an attempt to avoid such lines by cycling through chain names; the proper solution would be <code>coot</code>'s ''display objects''. | * <code>coot</code> connects atoms that are close, have residue numbers differing by at most 1, and are in the same chain, with bonds (lines) (Paul Emsley, personal communication). The program makes an attempt to avoid such lines by cycling through chain names; the proper solution would be <code>coot</code>'s ''display objects'' (Paul Emsley, personal communication). | ||