search

google-code-export / nmrrestrntsgrid

Automatically exported from code.google.com/p/nmrrestrntsgrid
0 stars 0 forks source link

entries with no parsable restraints don't fully convert #258

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I think there are related issues. When there are no restraints that can be 
parsed by wattos, there are still distances and blocks of data that can be 
mapped to a star file. Unfortunately, they never do. the merge log will show a 
thrown error. 

Here is an example, though there are a lot of examples.

Original issue reported on code.google.com by schulte....@gmail.com on 29 Jul 2010 at 1:54

GoogleCodeExporter commented 9 years ago 
Here is an example merge log.

Original comment by schulte....@gmail.com on 29 Jul 2010 at 2:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Since this is pretty important, we would like to get it fixed sooner than later.
Wim, if you want Alex to work on this can you add him to the Google Code list 
here?

Model read finished. Duration 1.81690597534 
Model validity check skipped
Read msd.adatah.localConstants.py version 1.2.3 grunt
Read msd.adatah.localConstants.py version 1.2.3 grunt
Doing 2kx4...
Traceback (most recent call last):
  File "/raid/docr/workspace/recoord/python/recoord2/pdbe/linkNmrStarData.py", line 753, in <module>
    LinkNmrStarData(sys.argv)
  File "/raid/docr/workspace/ccpn/python/pdbe/adatah/Generic.py", line 88, in __init__
    self.catchError(raiseError,timeFlag)
  File "/raid/docr/workspace/ccpn/python/pdbe/adatah/Generic.py", line 81, in __init__
    self.runSpecific()
  File "/raid/docr/workspace/recoord/python/recoord2/pdbe/linkNmrStarData.py", line 182, in runSpecific
    self.runLinkResonances()
  File "/raid/docr/workspace/ccpn/python/pdbe/adatah/Generic.py", line 562, in runLinkResonances
    sequenceComparison.createFormatFileChainInformation()
  File "/raid/docr/workspace/ccpn/python/ccpnmr/format/process/sequenceCompare.py", line 206, in createFormatFileChainInformation
    raise SequenceCompareError('No format chain codes in imported NMR data file, cannot continue!')
ccpnmr.format.process.sequenceCompare.SequenceCompareError: 'No format chain 
codes in imported NMR data file, cannot continue!'

Original comment by jurge...@gmail.com on 29 Jul 2010 at 2:12

GoogleCodeExporter commented 9 years ago 
Please Chris, remove entry 2kx4 and perhaps others if they only have CS. They 
should just be in BMRB.

Original comment by jurge...@gmail.com on 29 Jul 2010 at 2:54

GoogleCodeExporter commented 9 years ago 
Issue 256 has been merged into this issue.

Original comment by jurge...@gmail.com on 3 Sep 2010 at 8:27

GoogleCodeExporter commented 9 years ago 
We should start to remove these CS only entries.

Wim, can you or Alex look at this issue though?

Original comment by jurge...@gmail.com on 3 Sep 2010 at 8:35

GoogleCodeExporter commented 9 years ago 
Added entries that have same issue.

Original comment by jurge...@gmail.com on 3 Sep 2010 at 9:49

GoogleCodeExporter commented 9 years ago 
OK not sure what we can do about this - is this not a Wattos issue where you 
can 'catch' these if there are no restraints parsed that end up in the initial 
NMR-STAR?

Original comment by wfvran...@gmail.com on 6 Sep 2010 at 10:24

GoogleCodeExporter commented 9 years ago

Original comment by wfvran...@gmail.com on 6 Sep 2010 at 10:24

GoogleCodeExporter commented 9 years ago 
Wattos just presents the coordinates that need to be done by FC. Can you add an 
ifelse statement to process this anyway? Without any restraints obviously.

Original comment by jurge...@gmail.com on 6 Sep 2010 at 11:31

GoogleCodeExporter commented 9 years ago 
Do you mean just write out a new NMR-STAR file, without restraints but with the 
coordinates for DOCR?

Original comment by wfvran...@gmail.com on 6 Sep 2010 at 3:11

GoogleCodeExporter commented 9 years ago 
Yes, correct. Do you have time for this -I hope- small change? Thanks Wim!

Original comment by jurge...@gmail.com on 7 Sep 2010 at 9:40

GoogleCodeExporter commented 9 years ago

Original comment by jurge...@gmail.com on 16 Sep 2010 at 2:19

GoogleCodeExporter commented 9 years ago 
Just tidying up the issue by listing the entries here and not as labels.
Entry-2kx4
Entry-2kwj
Entry-2kxz
Entry-2ky0
Entry-2ky1
Entry-2ky2
Entry-2kwk
Entry-2kwn
Entry-2kwo
Entry-2kza

Original comment by jurge...@gmail.com on 22 Sep 2010 at 7:18

GoogleCodeExporter commented 9 years ago 
Issue 255 has been merged into this issue.

Original comment by jurge...@gmail.com on 24 Sep 2010 at 2:02

GoogleCodeExporter commented 9 years ago 
Finally got around to doing this! Sorry for the delay...

Anyway if there's no restraints, the script will now write out a:

NO_EXP_DATA

in that directory (with the current date).

Update the SourceForge CVS:

python/pdbe/

for this to take effect.

Original comment by wfvran...@gmail.com on 3 Oct 2010 at 9:30

GoogleCodeExporter commented 9 years ago 
Will it also write out the star file with everything normally in there but the 
restraints?
Cheers

Original comment by jurge...@gmail.com on 5 Oct 2010 at 9:50

GoogleCodeExporter commented 9 years ago 
It should! Worked when I tried it.

Original comment by wfvran...@gmail.com on 5 Oct 2010 at 10:34

GoogleCodeExporter commented 9 years ago 
I tried it on one entry. It made a STAR file and the NRG entry went to 
completion. I didn't thoroughly check everything, though. It also made the 
file, "NO_EXP_DATA," and I upgraded the bmrb-ftp and wwPDB ftp export.

Original comment by schulte....@gmail.com on 5 Oct 2010 at 12:49

GoogleCodeExporter commented 9 years ago 
Cool, now let's do all missing entries. About 40 or so right?

Original comment by jurge...@gmail.com on 7 Oct 2010 at 2:52

GoogleCodeExporter commented 9 years ago 
I think there are a lot more than that. There are 377 entries that haven't 
fully converted since last march. Add to that all the entries since then with 
no parsable data. 

I'll search for missing *_linked.str and do those first.

Original comment by schulte....@gmail.com on 7 Oct 2010 at 3:07

GoogleCodeExporter commented 9 years ago 
I take back the last comment. Those original 377 do have fully converted data 
on NRG. There are only 30 entries without the *_linked.str in 
ccpn_tmp/data/recoord/.

They are being processed now.

Original comment by schulte....@gmail.com on 7 Oct 2010 at 4:00

GoogleCodeExporter commented 9 years ago 
Of the 30 entries I reran, these 22 are now fully converted and filtered on NRG:
2kgu 2kmy 2kri 2ksu 2ktb 2ku4 2kv7 2kvy 2kwj 2kwk 2kwn 2kwo 2kx4 2kxz
2ky1 2ky2 2kza 2kzg 2l0i 2l0x 2l1j 2rr6

These 8 still have problems, usually crashing FC:
2k77 2kmx 2kp3 2kp4 2kql 2kt4 2ktr 2rqo

I believe this issue can be closed.

Original comment by schulte....@gmail.com on 7 Oct 2010 at 4:53

GoogleCodeExporter commented 9 years ago 
Cool, I'll take a look at the missing 8 above but that's another issue 246.
Thanks guys!

Original comment by jurge...@gmail.com on 8 Oct 2010 at 8:57

GoogleCodeExporter commented 9 years ago 
This seems to be a problem again. I'm getting a FC crash when the only 
restraints are chemical shifts. It seems that software packages like CS-Rosetta 
(among others) are powerful enough that structures are being calculated using 
only chemical shift.

Original comment by schulte....@gmail.com on 25 Aug 2011 at 2:31

GoogleCodeExporter commented 9 years ago 
I think at some ccpn update, we broke this again. I just ran 2ldo with only 
XEASY restraints and got this (again)

Traceback (most recent call last):
  File "/raid/docr/workspace/recoord/python/recoord2/pdbe/linkNmrStarData.py", line 753, in <module>
    LinkNmrStarData(sys.argv)
  File "/raid/docr/workspace/ccpn/trunk/ccpn/python/pdbe/adatah/Generic.py", line 88, in __init__
    self.catchError(raiseError,timeFlag)
  File "/raid/docr/workspace/ccpn/trunk/ccpn/python/pdbe/adatah/Generic.py", line 81, in __init__
    self.runSpecific()
  File "/raid/docr/workspace/recoord/python/recoord2/pdbe/linkNmrStarData.py", line 182, in runSpecific
    self.runLinkResonances()
  File "/raid/docr/workspace/ccpn/trunk/ccpn/python/pdbe/adatah/Generic.py", line 562, in runLinkResonances
    sequenceComparison.createFormatFileChainInformation()
  File "/raid/docr/workspace/ccpn/trunk/ccpn/python/ccpnmr/format/process/sequenceCompare.py", line 206, in createFormatFileChainInformation
    raise SequenceCompareError('No format chain codes in imported NMR data file, cannot continue!')
ccpnmr.format.process.sequenceCompare.SequenceCompareError: 'No format chain 
codes in imported NMR data file, cannot continue!'

and did not get a file with this name, "NO_EXP_DATA."

Original comment by schulte....@gmail.com on 8 Sep 2011 at 2:01

GoogleCodeExporter commented 9 years ago 
Just ran this on my setup and it works fine, writes out an NO_EXP_DATA file. 
Are you using the stable branch of CCPN after switching to the SVN version?

Original comment by wfvran...@gmail.com on 12 Sep 2011 at 11:32

GoogleCodeExporter commented 9 years ago 
As for entry 2lcb, you mean that we should be reading the chemical shifts as 
well? In any case, works fine for me, with NO_EXP_DATA file written out... .

Original comment by wfvran...@gmail.com on 12 Sep 2011 at 12:27

GoogleCodeExporter commented 9 years ago 
Another one.

Original comment by jurge...@gmail.com on 16 Sep 2011 at 2:09

GoogleCodeExporter commented 9 years ago

Original comment by schulte....@gmail.com on 16 Sep 2011 at 2:10

GoogleCodeExporter commented 9 years ago 
This one doesn't work here. I think something was un-fixed when we switched 
from cvs to svn. Just to be sure, I updated ccpn and FC, but the bug still 
persists.

Original comment by schulte....@gmail.com on 3 Oct 2011 at 5:15

GoogleCodeExporter commented 9 years ago

Original comment by schulte....@gmail.com on 21 Dec 2011 at 3:14

GoogleCodeExporter commented 9 years ago 
First, apologies for the slow reply.

This cannot happen in the CCPN stable branch - I suspect you're using trunk, 
the version of pdbe/adatah/Generic.py in there does not have to fix that I put 
in.

Original comment by wfvran...@gmail.com on 22 Dec 2011 at 2:35

GoogleCodeExporter commented 9 years ago 
Chris, could you try updating CCPN again on production and rerunning the 
entries still listed for this issue.

Original comment by jurge...@gmail.com on 24 Feb 2012 at 9:36

GoogleCodeExporter commented 9 years ago 
This issue is for 2l7v 2ldo 2kx4 2l6z 2lcb 2l6y 2lc9 but I'm removing them in 
the labels to keep the overview cleaner. We're still able to search for them.

Original comment by jurge...@gmail.com on 24 Feb 2012 at 10:00

GoogleCodeExporter commented 9 years ago 
I tried processing 2ldo  and 2l6y and they did not convert. I updated ccpn and 
tried running them again. Still no luck. 

Now I'm trying to track down why the new ccpn isn't working.

Original comment by schulte....@gmail.com on 1 Mar 2012 at 7:05

GoogleCodeExporter commented 9 years ago 
I got the new ccpn up and running. I reran all of these and they seemed to have 
all converted! They also correctly created the files 'NO_EXP_DATA'. I'm going 
to set this as finished.

Original comment by schulte....@gmail.com on 1 Mar 2012 at 9:45

GoogleCodeExporter commented 9 years ago 
Great job.
Can we keep this open a touch longer, until they are out on production?

Original comment by jurge...@gmail.com on 2 Mar 2012 at 9:52

GoogleCodeExporter commented 9 years ago 
Yes

Original comment by schulte....@gmail.com on 2 Mar 2012 at 2:04