Closed drlemmus closed 4 months ago
I see this still happens in Acedrg 284, not just the CCP4 latest (277). Acedrg should remember atoms that are removed by acedrg itself. @flong-mrc can you look into this?
Thanks, I did not realise the name of the deleted H atom can not be used again. I will do something on that.
Fei
On 2024-03-07 10:59, keitaroyam wrote:
CAUTION: This email originated from outside of the LMB: .@. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you think this is a phishing email, please forward it to @.
I see this still happens in Acedrg 284, not just the CCP4 latest (277). Acedrg should remember atoms that are removed by acedrg itself. @flong-mrc [1] can you look into this?
-- Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. You are receiving this because you were mentioned.Message ID: @.***>
Links:
[1] https://github.com/flong-mrc [2] https://github.com/MonomerLibrary/monomers/issues/47#issuecomment-1983265288 [3] https://github.com/notifications/unsubscribe-auth/AEABBSAZRH3NCFTUCFYLLUDYXBCCTAVCNFSM6AAAAABEKYB3DOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTGI3DKMRYHA
-- Dr. Fei Long Structural Studies Division UKRI Laboratory of Molecular Biology Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH UK @.*** Tel:+44 1223 4027844
There are several monomers in the library having this issue (in #44 I excluded hydrogen for comparison). We need to correct them as soon as acedrg is fixed.
Good catch
Hi all,
I think this bug is fixed. The name of a H atom deleted by acedrg will not be used again. However case R0K is a bit complicated. The new added H atom is on a peptide. It is supposed to call H3 according to the name conventions. But name H3 is used for another atom, which is not on a peptide, already in the original molecule. If I use H3 on the newly added atom, I guess it will cause confusion again. So another name is used.
Acedrg is updated on LMB network (hal/hex/max). Please let me known if any issue is spotted.
Thanks,
Fei
On 2024-03-14 13:44, keitaroyam wrote:
CAUTION: This email originated from outside of the LMB: .@. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you think this is a phishing email, please forward it to @.
--
There are several monomers in the library having this issue (in #44 [1] I excluded hydrogen for comparison). We need to correct them as soon as acedrg is fixed.
-- Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. You are receiving this because you were mentioned.Message ID: @.***>
Links:
[1] https://github.com/MonomerLibrary/monomers/pull/44 [2] https://github.com/MonomerLibrary/monomers/issues/47#issuecomment-1997493331 [3] https://github.com/notifications/unsubscribe-auth/AEABBSDKSHJ4RWZH4WGZVODYYGSSBAVCNFSM6AAAAABEKYB3DOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGQ4TGMZTGE
-- Dr. Fei Long Structural Studies Division UKRI Laboratory of Molecular Biology Francis Crick Avenue, Cambridge Biomedical Campus, Cambridge CB2 0QH UK @.*** Tel:+44 1223 4027844
Thank you Fei. PDB unfortunately doesn't reserve H3 for the NH3 moiety so this issue happens everywhere. The alias mechanism (partly) has solved the issue.
@drlemmus I generated R0K dictionary using the latest Acedrg (and the alias added) so that you can test: acedrg_R0K.cif.gz
I thought we should address H-atom related inconsistencies from the CCD, but also (again) found inconsistencies between CCD and PDB. For example 1CC has C6-H10 bond in the CCD but 4m9v has C6-H6 bond (so our current dictionary is valid).
Issues with inconsistent hydrogen naming like 4m9v should be reported to the PDB. PDB-REDO does not notice these things as hydrogens are stripped and regenerated in the first Refmacat run.
I have reported several cases the H3 naming issue. The annotators explained that this issue cannot be avoided in an elegant way, but they will update affected entries in the CCD on request. Note that the turnaround time for these sort of updates is unpredictable and can be very long.
Thanks for reporting the issue to the PDB. Are they also aware of the 1CC/4m9v issue?
what is the problem with 1CC?
Please see the comment above or #50
4m9v runs smoothly through pdb-redo. What is fishy is that the compound is said to not be modified after 2012, but Rachel fixed it in 2020. Anyway, the CCD seems correct to me at the moment.
Is it just because the current monomer library is consistent with the PDB coordinates (but not with the CCD) and also pdb-redo re-generates hydrogen atoms?
According to the CCD, C6 is bound to H6. This is also the case in the PDB entry 4m9v and the CCP4ML
I now checked this again. I see C6 is bound to H10.
loop_
_chem_comp_bond.comp_id
_chem_comp_bond.atom_id_1
_chem_comp_bond.atom_id_2
_chem_comp_bond.value_order
_chem_comp_bond.pdbx_aromatic_flag
_chem_comp_bond.pdbx_stereo_config
_chem_comp_bond.pdbx_ordinal
...
1CC C6 H10 SING N N 32
I got the individual file from Ligand expo which is correct. In components .cif it is indeed wrong.
Worse downloading the individual file from wwPDB is also wrong, but no record of an update.
Interesting.. indeed http://ligand-expo.rcsb.org/reports/1/1CC/1CC.cif has C6-H6 bond, and "Modify atom id" history only appears in this ligand-expo file. Perhaps they forgot to update the CCD?
loop_
_pdbx_chem_comp_audit.comp_id
_pdbx_chem_comp_audit.action_type
_pdbx_chem_comp_audit.date
_pdbx_chem_comp_audit.processing_site
1CC "Create component" 2011-11-17 RCSB
1CC "Modify internal type" 2011-11-17 RCSB
1CC "Modify name" 2011-11-17 RCSB
1CC "Modify atom id" 2020-06-18 RCSB
I think so. The 2020 update is the one I asked for.
Better to contact the PDB person. Would you do?
Done, with you in CC.
Thank you!
Fixed next in next week's release.
When I run AceDRG (CCP4 version) on the CCD definition of R0K, the output restraint file connects atom H10 to the backbone N rather than to the O4 atom. The output restraint file makes refmacat fail because it cannot place the H10 atom. Testcase PDB entry 5ein.