problem with conv_err

[GoogleCodeExporter]

see the image:

The errors 37 and greater do not make sense. Is this an error or a bug?

Original issue reported on code.google.com by schulte....@gmail.com on 19 Nov 2009 at 3:19

• Blocked on: #238

Attachments:

• conv_err.tiff

[GoogleCodeExporter]

I can't get a joined restraints/coordinate file for this one. Not on 

http://sunfish.bmrb.wisc.edu/nmrRestrGrid/

Wim

Original comment by wfvran...@gmail.com on 20 Nov 2009 at 10:01

[GoogleCodeExporter]

Try on tang: /grunt/docr/NRG/star/2w1o/2w1o_join.str

Cheers

Original comment by jurge...@gmail.com on 20 Nov 2009 at 10:38

[GoogleCodeExporter]

This seems to come from the lines:

Error: duplicate resonance '_B.7.HD#' (nmrStar names) found - constraint not 
imported

in the .log file. I'll check what's going on...

Original comment by wfvran...@gmail.com on 23 Nov 2009 at 2:02

[GoogleCodeExporter]

This is taking a while. The problem is threefold, it seems:

1. There were issues with the way the tags were passed on in 
linkNmrStarData.py, this
is fixed.

2. In the NMR-STAR dictionary, loop 'Gen_dist_constraint_conv_err', the tag 
which
should be called 'Parse_file_constraint_ID' is called 
'Parse_file_constraintaint_ID',
plus the 'foreign key' value should probably (see point 3.) be set to
'Gen_dist_constraint.ID'. I've fixed this in my dictionary, but should be fixed 
at
source (hence inclusion of you on this Eldon).

3. The interpretation of 'Parse_file_constraint_ID'. Currently this is set to
'Gen_dist_constraint.ID' - the question is whether it should reflect the 
original ID
in the parsed restraint file (if it exists?), or the new ID in the final 
NMR-STAR
file (as is done now - the numbering changes if restraints are removed). One 
for you,
Jurgen!?

Original comment by wfvran...@gmail.com on 23 Nov 2009 at 5:13

[GoogleCodeExporter]

On 3. 
it should reflect the original ID in the parsed restraint file.

It always exists otherwise it doesn't need to go from parsed to converted.
Cheers

Original comment by jurge...@gmail.com on 23 Nov 2009 at 7:00

[GoogleCodeExporter]

OK in that case there is a slight problem, because that means that in some 
cases (the
original parsed file) it is OK to have it as foreign key, whereas in others (the
converted file) it should not be a foreign key - or do I misunderstand? In any 
case,
it's probably best to remove all foreign key settings for 
Parse_file_constraint_ID, I
think.

Original comment by wfvran...@gmail.com on 24 Nov 2009 at 10:18

[GoogleCodeExporter]

In the parsed file the tag does not occur.
In the converted file it is a key only to the parsed file not within the 
converted file.
"""
In any case, it's probably best to remove all foreign key settings for 
Parse_file_constraint_ID, I think.
"""
Settings in your software and/or in the dictionary? I think you're right to 
remove them because they can not exist 
in the same file.
Thanks for looking into this!

Original comment by jurge...@gmail.com on 24 Nov 2009 at 10:47

[GoogleCodeExporter]

Yep so the foreign key settings for Parse_file_constraint_ID have to be removed 
from
the NMR-STAR dictionary... . Can you confirm Eldon?

Original comment by wfvran...@gmail.com on 24 Nov 2009 at 10:49

[GoogleCodeExporter]

OK fixed. For this one, update:

recoord2/msd/linkNmrStarData.py
msd/nmrStar/IO/nmrStarDict.py

Let's get this over and done with!!! Not far to go any more, I think... 

Original comment by wfvran...@gmail.com on 24 Nov 2009 at 11:52

[GoogleCodeExporter]

What information is being captured in the Conv_err table?  
1) Is it, for the constraint_ID that I have created in this file there was a
conversion error? 

2) Or is it when I tried to convert the constraint with the ID xxx from the
constraint file ID xxx, I had this error.

Eldon

Original comment by webmas...@bmrb.wisc.edu on 24 Nov 2009 at 5:23

[GoogleCodeExporter]

The first. If a constraint can be converted, it goes into a constraint table, 
otherwise, it goes into a conversion 
error table.

Original comment by schulte....@gmail.com on 24 Nov 2009 at 6:29

[GoogleCodeExporter]

Jurgen,

Was this table intended to handle errors when trying to move a constraint from 
the
'parsed' file to the 'converted' (DOCR) file in the processing stream? 

Eldon

Original comment by Eldon.Ul...@gmail.com on 24 Nov 2009 at 6:44

[GoogleCodeExporter]

Correct

Original comment by jurge...@gmail.com on 24 Nov 2009 at 6:46

[GoogleCodeExporter]

Jurgen,

What does 'correct' refer to, Chris' comment or mine referring to the 
production of
DOCR files?

Thanks,
Eldon

Original comment by webmas...@bmrb.wisc.edu on 24 Nov 2009 at 8:55

[GoogleCodeExporter]

It answered your question in comment 12.

Original comment by jurge...@gmail.com on 25 Nov 2009 at 8:38

[GoogleCodeExporter]

This problem is not as simple as just removing the foreign key designations on 
the
covr_err. If this is done, the whole table becomes useless. I think the two tags
should be removed so that this becomes just a list of reported conversion errors
encounter in the data processing.

Does this agree with your final conclusion?

Thanks,
Eldon

Original comment by Eldon.Ul...@gmail.com on 1 Dec 2009 at 3:53

[GoogleCodeExporter]

Removing the tags, although they appear useless, takes away the ability to 
define
which file conversion produced the errors. Is a tag like
'_???_conv_err.Starting_file_name' needed to at least designate how the errors
originated?

Eldon

Original comment by Eldon.Ul...@gmail.com on 1 Dec 2009 at 3:56

[GoogleCodeExporter]

I think we should keep the tags in and redefine their meaning in the 
dictionary. The foreign key constraints 
(FKCs) probably need to be removed.
Eldon, please make an executive decision on this so we can move on. Thanks.

Original comment by jurge...@gmail.com on 2 Dec 2009 at 10:07

• Changed state: Started

[GoogleCodeExporter]

The 'parse_file_constraint_ID' can easily have the foreign key constraint 
removed.
Being a pointer to an ID in an external file, it is not clear that it is really 
of
any use.

The 'parse_file_ID' tag, however, is a pointer to the file that was attempted 
to be
converted. This tag must remain a foreign key to the table where a list of the 
files
that have been processed is provided. If you are not able to populate the file 
table
and want to just provide a file name, then a new tag needs to be defined. 
Something
like 'xxx.Parse_file_name'.

I do not have any preference. I just want to change this in a way that will 
work for
you guys.

Sorry, I have been ill and not always on line.

Original comment by Eldon.Ul...@gmail.com on 3 Dec 2009 at 5:22

[GoogleCodeExporter]

Thanks Eldon!
Wim can you take in the changes you need and close the issue?

Original comment by jurge...@gmail.com on 3 Dec 2009 at 8:49

[GoogleCodeExporter]

I already removed the foreign key pointer for 'parse_file_constraint_ID' in my
'derived dictionary', so if the name is fixed as well
('Parse_file_constraintaint_ID', see higher up) then next time I update from 
the core
NMR-STAR excel dictionary everything will remain functional.

As for 'parse_file_ID', I can and am handling this, no problems there.

Original comment by wfvran...@gmail.com on 3 Dec 2009 at 9:15

• Changed state: Fixed

[GoogleCodeExporter]

Excellent. Check on: Parse_file_constraintaint_ID It should probably read: 
Parse_file_constraint_ID.
When do you intend to push the code out for Chris? Couple of days?

Original comment by jurge...@gmail.com on 3 Dec 2009 at 9:26

[GoogleCodeExporter]

Original comment by schulte....@gmail.com on 4 Dec 2009 at 2:47

• Changed state: Accepted

[GoogleCodeExporter]

Can this be closed?

Original comment by jurge...@gmail.com on 5 Jan 2010 at 12:34

• Changed state: Started

[GoogleCodeExporter]

Almost - this just needs a recheck after generating files with the new NMR-STAR
dictionary.

Original comment by wfvran...@gmail.com on 5 Jan 2010 at 12:42

[GoogleCodeExporter]

I don't think we can close anything that requires a ccpn or recoord update, 
since we can't implement and test it 
on production yet.

Original comment by schulte....@gmail.com on 5 Jan 2010 at 2:14

[GoogleCodeExporter]

Can this be closed now?

Original comment by jurge...@gmail.com on 14 Apr 2010 at 2:16

[GoogleCodeExporter]

I just took a look at the entry and re-processed it, just to make sure. 
Everything looks OK on grunt and the 
public restraints grid.

I would say we can close it. Wim, you're the owner.  What do you say?

Original comment by schulte....@gmail.com on 14 Apr 2010 at 2:42

[GoogleCodeExporter]

I just rechecked with the new 'derived' NMR-STAR dictionary (which is not 
checked in
yet), and all looks fine, so let's close this issue.

Original comment by wfvran...@gmail.com on 14 Apr 2010 at 3:08

[GoogleCodeExporter]

Original comment by wfvran...@gmail.com on 14 Apr 2010 at 3:09

• Changed state: Verified