FC crashes on encountering J couplings in BMRB NMR-STAR file

[GoogleCodeExporter]

NB the J couplings don't need to be in NRG-CING (yet).

What steps will reproduce the problem?
1. Merge CS for this entry.

What is the expected output? What do you see instead?

#############################################
# FormatConverter: executing readJCouplings #
#############################################

ERROR in ccp.nmr.Nmr.JCoupling.__init__
Traceback (most recent call last):
  File "/Users/jd/workspace35/cingStable/python/cing/Scripts/FC/mergeNrgBmrbShifts.py", line 144, in <module>
    MergeNrgBmrbShifts(sys.argv)
  File "/Users/jd/workspace35/ccpn/python/pdbe/adatah/Generic.py", line 89, in __init__
    self.catchError(raiseError,timeFlag)
  File "/Users/jd/workspace35/ccpn/python/pdbe/adatah/Generic.py", line 82, in __init__
    self.runSpecific()
  File "/Users/jd/workspace35/cingStable/python/cing/Scripts/FC/mergeNrgBmrbShifts.py", line 98, in runSpecific
    self.readNmrStarFile(inputStarFile, components=['measurements'])
  File "/Users/jd/workspace35/ccpn/python/pdbe/adatah/NmrStar.py", line 46, in readNmrStarFile
    **localKeywds)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 951, in readProject
    self.getFullProject(fileName,**keywds)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/NmrStarFormat.py", line 774, in getFullProject
    readFunc(minimalPrompts = self.minimalPrompts, version = self.version, **readMeasurementsKeywds)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 1837, in readJCouplings
    return self.readMeasurements(*args, **keywds)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 2011, in readMeasurements
    self.setMeasurements()
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 5277, in setJCouplings
    self.setMultipleResonanceMeasurementsGeneric() 
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 5249, in setMultipleResonanceMeasurementsGeneric
    self.measurement = self.createMeasurement(resonanceComb,self.rawMeasurement)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 8059, in createJCoupling
    return self.createMultipleResonanceMeasurement(resonances,rawMeasurement)
  File "/Users/jd/workspace35/ccpn/python/ccpnmr/format/converters/DataFormat.py", line 8051, in createMultipleResonanceMeasurement
    return self.ApiMeasurement(self.measurementList, value = value, resonances = resonances, **keywds)
  File "/Users/jd/workspace35/ccpn/python/ccp/api/nmr/Nmr.py", line 103841, in __init__
    func(self, value)
  File "/Users/jd/workspace35/ccpn/python/ccp/api/nmr/Nmr.py", line 104734, in setResonances
    + ": %s" % (self,)
memops.general.Implementation.ApiError: ccp.nmr.Nmr.JCoupling.setResonances:
       values may not contain duplicates: <ccp.nmr.Nmr.JCoupling ['1tuz', 2]>

Original issue reported on code.google.com by jurge...@gmail.com on 24 Feb 2011 at 8:19

[GoogleCodeExporter]

Also occurs for 2jxn bmr15562_21.str

Checking all reveals this is a higher priority issue:

jd:nmr/S/ find . -name "*.log" | xargs grep 
"memops.general.Implementation.ApiError"
./el/1el2/1el2_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName:
./jx/2jxn/2jxn_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccp.nmr.Nmr.JCoupling.setResonances:
./jy/2jym/2jym_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName:
./k4/2k4l/2k4l_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName:
./ki/2kid/2kid_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccp.molecule.ChemComp.NonStdChemComp.checkValid:
./kk/2kka/2kka_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName:
./lu/1luu/1luu_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName:
./tu/1tuz/1tuz_starCS2Ccpn.log:memops.general.Implementation.ApiError: 
ccp.nmr.Nmr.JCoupling.setResonances:

Wim, can you take a look? Just ignore these JCouplings for now please.

Original comment by jurge...@gmail.com on 28 Mar 2011 at 1:03

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It's a problem with the atom names in the NMR-STAR file for 2jxn/bmr15562, 
unless a coupling constant between an atom and itself can be measured (not 
likely). I'm now making sure the error doesn't occur any more, check out 
DataFormat.py in ccpnmr/format/converters/ in SF CVS.

The setResonanceNames issue I'm not sure - can you give me a BMRB code for one 
of those entries?

Original comment by wfvran...@gmail.com on 29 Mar 2011 at 1:50

[GoogleCodeExporter]

> The setResonanceNames issue I'm not sure - can you give me a BMRB code for 
one of those entries?
This issue was already tagged with BMRB-6208 ;-)
Thanks for looking into these issues!

Original comment by jurge...@gmail.com on 29 Mar 2011 at 2:36

[GoogleCodeExporter]

Yep but 1tuz and bmr6208 have the setResonances issue, which should be sorted - 
I was looking for a ccpnmr.NameMapping.ResonanceStatusMapping.setResonanceName 
one like 1luu

Original comment by wfvran...@gmail.com on 29 Mar 2011 at 2:47

[GoogleCodeExporter]

1luu is matched to 5531 according to:
http://code.google.com/p/cing/source/browse/trunk/cing/data/NRG/bmrbPdbMatch/new
Many2OneTable.csv

thanks

Original comment by jurge...@gmail.com on 30 Mar 2011 at 7:15

[GoogleCodeExporter]

OK the setResonanceName issue is probably related to the one with the long 
names, I just tried 1luu with 5531 and it works for me...

Original comment by wfvran...@gmail.com on 30 Mar 2011 at 8:33

[GoogleCodeExporter]

Ok that entry works as well here. I'll check the others now.

Original comment by jurge...@gmail.com on 30 Mar 2011 at 9:04

• Changed state: Started

[GoogleCodeExporter]

The first couple are running thru fine as well. Thanks for the fix Wim!

Original comment by jurge...@gmail.com on 30 Mar 2011 at 9:08

• Changed state: Fixed