[COOT] coot scripting

[Zhu JiaPeng]

Dear all,

I am currently working with a protein containing multiple subunits. For each 
subunit, I need Coot to perform rigid body fitting followed by real-space 
refinement. Manually inputting the Python commands 
rigid_body_refine_zone(reso_start, resno_end, chain_id, imol) and 
refine_zone(imol, chain_id, resno1, resno2, altconf) and then pressing "accept" 
for each chain has proven to be quite tedious.

Is there a way to combine these commands into a single script for automation?

Best wishes,
Jiapeng
















To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [COOT] Coot/mmdb2 issues with NCS and links in mmCIFs

[Paul Emsley]

On 13/10/2023 13:12, Neil Rzechorzek wrote:


Dear colleagues,



Hi Neil,


I have been iteratively rebuilding and refining a crystal structure 
using coot (v. 0.9.8.91) and Phenix.


Refinement makes use of NCS restraints, and the structure additionally 
has some covalent links between protein sidechains and bound ligands.



OK, sounds interesting.


NCS parameters and links are output by Phenix in both PDB and mmCIF 
file formats.


Coot happily opens the PDB file, and the covalent links are displayed 
as the usual dotted lines.


However, coot fails to open the mmCIF file.  According to an old 
ccp4bb post 
(https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=ind1910=CCP4BB=0=73942 
), 
this appears to be an mmdb2 library issue that I gather has not been 
resolved.


That's right. But there's more. I've been working on a new version of 
Coot and that reads 6ttq (for example) just fine.


  In particular, the _struct_ncs_oper category in the mmCIF is the 
culprit and - as the previous poster noted - removing this whole 
section from the file enables coot to open it.  I gather this is akin 
to deleting the MTRIX section in a PDB file, though am not sure 
whether this is either permitted or advisable for a deposited structure.



Indeed.

Additionally, coot doesn’t show the sidechain-ligand links in this 
modified mmCIF file.  The correct _struct_conn.id loops are present – 
is there a switch somewhere that encourages coot to show them?



There is no user-control over this.


  I’ve checked other deposited mmCIF files with such links, and they 
too suffer from the same problem.



Do you have a particular code in mind?

As I’m now depositing the structure at the PDB, I’m trying to resolve 
these issues prior to accepting the final annotated version.  While 
end users will always be able to open the PDB file in coot, mmCIF 
seems to be the preferred file type for many.



This will increasingly become the case.


Apologies if I’ve missed other posts/solutions to these issues, or 
have misunderstood something – I did search, but could not find 
answers.  Any suggestions would be extremely welcome!


The ball is in my court. The version of Coot that I am using (from the 
main branch of the Coot repo) doesn't have these problems, AFAICS. I 
need to get it in shape for release.


Since mmdb2 is managed by the CCP4 team, I will likely post this to 
ccp4bb also.


They will say "if mmdb2 is the problem then GEMMI is the solution" - or 
some such.


Paul.





To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/