Use remediated mmCIF files

[GoogleCodeExporter]

Wim requested to use these. 

Unknown to me what exactly changed.

rsync --port=8730 rcsb-rsync-4.rutgers.edu::ftp-v3.2/
ask Wim for password

I'll try to sync today.

Original issue reported on code.google.com by jurge...@gmail.com on 19 Feb 2009 at 10:57

[GoogleCodeExporter]

Ok, checking diffs for 1brv:

252c243
< GLY 'peptide linking'   y GLYCINE         ? 'C2 H5 N O2'     75.067
---
> GLY 'L-peptide linking' y GLYCINE         ? 'C2 H5 N O2'     75.067
Not sure if it's a bug. Shouldn't affect this project.

Original comment by jurge...@gmail.com on 19 Feb 2009 at 1:02

[GoogleCodeExporter]

Thanks Jurgen. You must have a lot of other things on your mind now, but if you 
did
regenerate the files and you have a minute, let me know where they are!

Original comment by wfvran...@gmail.com on 24 Feb 2009 at 2:01

[GoogleCodeExporter]

I hear you are making good progress on the new machine's setup. 
Does it make sense to have me update this for tang still?
Are we going to base the remediated files first of tang? Or grunt?

On my development machine I will switch to the archive listed above when I get 
more info from Wim on the 
changes done.

Original comment by jurge...@gmail.com on 26 Feb 2009 at 9:08

[GoogleCodeExporter]

The one change that could cause problems is that ACE and NH2 are handled 
differently
again. It would be worth checking the difference in mmCIF files for some of the
following examples (provided by Monica):

NH2
RCSB100049     2JND
RCSB100172     2JQS
RCSB100174     2JQU

ACE
RCSB041064     2OFC
RCSB041065     2OFD
RCSB041066     2OFE
RCSB041129     2OH5
RCSB041130     2OH6
RCSB041131     2OH7
RCSB041707     2OXJ
RCSB041708     2OXK
RCSB041822     2P0R
RCSB026439     2EAR
RCSB026440     2EAS
RCSB026441     2EAT
RCSB026442     2EAU
RCSB027468     2Z3C
RCSB027469     2Z3D
RCSB027470     2Z3E
RCSB041291     2OLP
RCSB042502     2PL9
RCSB042535     2PMC

If there are differences, send me the new joined coord/restraint NMR-STAR file 
that
comes from these and I'll see if the linking process is still working without 
problems.

Original comment by wfvran...@gmail.com on 26 Feb 2009 at 9:37

[GoogleCodeExporter]

I'm working on this but taking some time to get my FC install up again.

Original comment by jurge...@gmail.com on 3 Mar 2009 at 3:23

[GoogleCodeExporter]

Model read finished. Duration 1.32472991943 
Model validity check skipped
Traceback (most recent call last):
  File "/Users/jd/workspace34/nmrrestrntsgrid/python/nmrrestrntsgrid/core/linkStep.py", line 7, in 
<module>
    from recoord2.msd.linkNmrStarData import LinkNmrStarData #@UnresolvedImport
  File "/Users/jd/workspace34/recoord/python/recoord2/msd/linkNmrStarData.py", line 16, in <module>
    from msd.adatah.Util import runConversionJobs
  File "/Users/jd/workspace34/recoord/python/msd/adatah/Util.py", line 6, in <module>
    from msd.adatah.Constants import pythonCommand, numCpu
  File "/Users/jd/workspace34/recoord/python/msd/adatah/Constants.py", line 49, in <module>
    from ccp.general.Io import getArchiveChemCompDataDir
ImportError: cannot import name getArchiveChemCompDataDir

Is probably caused by a misnaming in ccp.general.Io:
def getChemCompArchiveDataDir():

Wim, could you check if that's still the case? It looks like a bug.

Original comment by jurge...@gmail.com on 3 Mar 2009 at 3:40

[GoogleCodeExporter]

Original comment by jurge...@gmail.com on 3 Mar 2009 at 3:41

[GoogleCodeExporter]

Never mind. I might have changed this locally...

Original comment by jurge...@gmail.com on 3 Mar 2009 at 3:46

[GoogleCodeExporter]

Yep think so - I can't find this anywhere...

Original comment by wfvran...@gmail.com on 3 Mar 2009 at 3:50

[GoogleCodeExporter]

Ok, my setup works again. Now on to testing the new files...

Original comment by jurge...@gmail.com on 3 Mar 2009 at 4:37

[GoogleCodeExporter]

I haven't tested the entries you listed above because they're not in NRG; no 
NMR restraints available.
My entry 1brv came thru without a single difference.
I am syncing this week to tang and will switch to it hopefully next week.

Original comment by jurge...@gmail.com on 5 Mar 2009 at 10:16

[GoogleCodeExporter]

Here's a longer list...

Original comment by wfvran...@gmail.com on 5 Mar 2009 at 10:51

Attachments:

• ace_nh2_entries.txt

[GoogleCodeExporter]

Since /dumpzone can't contain another copy of pdb I'm switching right away.

Hopefully nothing breaks.

squid:/export/raid1/mirrors                      917G  827G   81G  92% /dumpzone

Original comment by jurge...@gmail.com on 5 Mar 2009 at 10:52

[GoogleCodeExporter]

Thanks Wim, I'll look at a couple of them that are in NRG:

1a1p 1a93 1abz 1ad7 1aft 1as5 1awy 1bde 1bfw 1bh1

Original comment by jurge...@gmail.com on 5 Mar 2009 at 10:59

[GoogleCodeExporter]

Chris, you can't process the entries today. It probably will have to be 
postponed to Mon. I'll let you know when 
the new remediated mmCIFs etc. are in.

Original comment by jurge...@gmail.com on 5 Mar 2009 at 11:40

[GoogleCodeExporter]

Wim, could you take a look at the 1a1p case.

Before it linked 137 out of the 145 restraints.
Now none. The attached is input to the FC and the FC log using 1 model only.

I'm using your presetDict.py settings:

'1a1p': {

  'authors': ['Wim Vranken'],

  'linkResonances': {

   'keywds': {

     'forceChainMappings': [
                             ['A', ' ', 1, 0],
                             ['B', 'B', 1, 0]
                           ],

     'specificResNameMappings': {
                                  " .13.H1": "B.1.HN1",
                                  " .13.H2": "B.1.HN2",
                                },

      },
    },
  },

Original comment by jurge...@gmail.com on 5 Mar 2009 at 12:22

Attachments:

• 1a1p_join.str.gz
• linkNmrStarData.log

[GoogleCodeExporter]

OK this is what I was fearing... anyway will see what can be done automatically.

By the way you are aware only the first two models of the ensemble are in the
NMR-STAR file, Jurgen?

Original comment by wfvran...@gmail.com on 5 Mar 2009 at 12:33

[GoogleCodeExporter]

O, you mean instead of the 1 model I mentioned above? I'm aware yes.

Original comment by jurge...@gmail.com on 5 Mar 2009 at 12:35

[GoogleCodeExporter]

Ah I should read things more carefully! Mea culpa

Original comment by wfvran...@gmail.com on 5 Mar 2009 at 12:37

[GoogleCodeExporter]

OK the good news is that my code seems handle the change in the input file (NH2 
as
part of the main sequence instead of a separate chain) withouth problems. This 
is
what I was most worried about.

The 1a1p case in particular then:

1. The original forceChainMappings includes this bit:

    [B', 'B', 1, 0]

   Which is now not valid any more, of course, since there's only chain A. This whole
   bit can go.

2. The 'specificResNameMappings' has to change to reflect the new 'residue 14' 
status
of the NH2, *and* have to map this directly to the CCPN atom names using the
useCcpnAtomMatching flag (there's no XPLOR NH2 names), so this entry ends up 
looking
like this:

'1a1p': {

  'authors': ['Wim Vranken'],

  'linkResonances': {

   'keywds': {

     'specificResNameMappings': {
                                  " .13.H1": " .14.HN1",
                                  " .13.H2": " .14.HN2",
                                },

      'useCcpnAtomMatching': True,

      },
    },
  },

I think it is probably going to make most sense to go over all the entries that
Monica listed, and re-curate by hand. I can't see an easy automatic way out for 
these
problems.

Original comment by wfvran...@gmail.com on 5 Mar 2009 at 1:03

[GoogleCodeExporter]

Luckily only 10 entries in NRG. Chris could you rerun these entries?
1a1p 1a93 1abz 1ad7 1aft 1as5 1awy 1bde 1bfw 1bh1
The attached giffie shows how many restraints originally were linked by FC for 
each entry.

Original comment by jurge...@gmail.com on 5 Mar 2009 at 1:17

[GoogleCodeExporter]

Chris, could you take another look at this now that the sync is done?

Original comment by jurge...@gmail.com on 31 Mar 2009 at 8:53

[GoogleCodeExporter]

Original comment by jurge...@gmail.com on 31 Mar 2009 at 9:04

• Added labels: Component-FormatConverter, Component-BMRB

[GoogleCodeExporter]

I redid these. Where is the gif with the original linkings you were talking 
about?

Original comment by schulte....@gmail.com on 31 Mar 2009 at 6:18

[GoogleCodeExporter]

Sorry, I forgot to upload and now it's lost. It's even not in my trash, sorry.
Can you close the issue if you're happy?

Original comment by jurge...@gmail.com on 31 Mar 2009 at 8:36

[GoogleCodeExporter]

I'm not sure if I'm happy or not. Some entries seemed to fix, others didn't.

Original comment by schulte....@gmail.com on 31 Mar 2009 at 8:40

[GoogleCodeExporter]

Ok, let's pick them up on Thu with our regular Skype. I have a couple of 
deadlines tomorrow.

Original comment by jurge...@gmail.com on 31 Mar 2009 at 8:42

[GoogleCodeExporter]

sounds good. I'm kind of bogged down at the moment also.

Original comment by schulte....@gmail.com on 31 Mar 2009 at 8:47

[GoogleCodeExporter]

http://restraintsgrid.bmrb.wisc.edu/NRG/MRGridServlet?block_text_type=2-parsed&b
lock_text_type=3-
converted-DOCR&db_username=wattos1&file_detail=2-parsed?file_detail=3-converted-
DOCR&format=n%2Fa&pdb_id=1a1p,1a93,1abz,1ad7,1aft,1as5,1awy,1bde,1bfw,1bh1&reque
st_type=block_set&
subtype=full&type=entry

Shows that only 1bde has a problem. The problem is with exports so this issue 
can be closed.

Original comment by jurge...@gmail.com on 9 Apr 2009 at 2:18

• Changed state: Fixed