CSN restraint parsing

[eisoab]

Hi Olivier,

Was trying your code to display NOE restraints in pymol, and happened to see
that your quite active at the moment...

I'm getting these error messages for a valid unambig.tbl

Can't find HG* in structure complexfit_1 because : Wrong segment / chain
Selection issue with constraint :
 ( RESID 49 AND NAME HG++ ) ( RESID 501 AND NAME  HG+ ) 3.52 3.52 0.00
Can't find HG in structure complexfit_1 because : Atom name not found
Selection issue with constraint :
 ( RESID 53 AND NAME HG++ ) ( RESID 501 AND NAME  HG+ ) 3.41 3.41 0.00
Can't find HG in structure complexfit_1 because : Atom name not found
Selection issue with constraint :
 ( RESID 53 AND NAME HG++ ) ( RESID 501 AND NAME  HG+ ) 3.44 3.44 0.00
Can't find HD in structure complexfit_1 because : Atom name not found
Selection issue with constraint :
 ( RESID 67 AND NAME HD++ ) ( RESID 501 AND NAME  HH1 ) 3.24 3.24 0.00
Can't find HD in structure complexfit_1 because : Atom name not found
Selection issue with constraint :
 ( RESID 67 AND NAME HD++ ) ( RESID 501 AND NAME  HG+ ) 3.37 3.37 0.00

Does you wildcard specification correspond to the one defined in
http://structure.usc.edu/cns/tutorial/language/scripting/text.html

Wildcards

Another special case of a word is a wildcard which can take the following forms:

* | % | # | +

where

    * matches any string.
    % matches a single character.
    # matches any number.
    + matches any digit.

[oserve]

Hi,
First of all, thank you (trying) using my plugin and for the feedback !
I was not aware of the « + » wildcard, I’ll try to implement its support ASAP. In fact, I was aware only of the "*", which is property supported (AFAIK). As it was the only one I ever used, which I realized now was a small mistake. I'll try to implement the other wildcards support as well. I think it should pretty straightforward, I need to check pymol selection syntax. If I can't, I guess it would possible to convert them to .
So, I guess HG++ would match equally HG11, HG12, HG22 ... but not HG1, am I right ?
One thing you should be aware is that, for now, HB are usually not correctly supported due to difference in pdb and CNS nomenclature (HB1 --> HB2, HB2--> HB3), unless you work directly with the structure you generated, that should work.

[eisoab]

Olivier Serve wrote:

Hi, First of all, thank you (trying) using my plugin and for the feedback ! I was not aware of the « + » wildcard, I’ll try to implement its support ASAP. In fact, I was aware only of the "*", which is property supported (AFAIK). As it was the only one I ever used, which I realized now was a small mistake. I'll try to implement the other wildcards support as well. I think it should pretty straightforward, I need to check pymol selection syntax. If I can't, I guess it would possible to convert them to /. So, I guess HG++ would match equally HG11, HG12, HG22 ... but not HG1, am I right ? /

yep, correct.

/One thing you should be aware is that, for now, HB/ are usually not correctly supported due to difference in pdb and CNS nomenclature (HB1 --> HB2, HB2--> HB3), unless you work directly with the structure you generated, that should work.

yes, for that reason I almost always use HB+ instead of HB1,HB2 or HB3 in the restraints. To be honest I think you should not worry about this in your parsing, and just match exactly what the restraint defines. and let the user supply matching restraint and pdb files. separately one could switch the prochiral atoms like (HB1<->HB2) or switch nomenature (HB1->HB2,HB2->HB3) in either the structure or in the restraints. Eiso

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZStTrQv81xfYFfyUGgYXVV_etcppo5jks5rnRpegaJpZM4MhtTf>.

[eisoab]

another comment: not all restraint selections use the segid ( see my restrains above).
If they are absent restraints should match all chains or segids not none.

If I include a segid in my restraints above I start seeing restraint lines displayed.

Eiso

[oserve]

I have checked pymol documentation and base code (python and cpp), check pymol itself, but I couldn't find any supplementary wildcard, so i guess I will to have to work with "*" for now. My guess is that on the same residue you can not have both H_X and H_XX, so in practice it should not a problem to replace + and ++ by a '*', since there is also a residue selection that should prevent misinterpretations.
Regarding your last comment, the (expected) current behavior is to assign the restraints without segid to chain "A", as it is the default name for structure with one un-named chain. So, there must be a bug in my code, that I have to check, everything should be displayed.
I see the point in your recommandation and doing so would not change the expected behavior for a one chain un-named structure. I'll work on that as well.

[oserve]

Ok, commit 9331494 should add support for all wildcards (# was already supported in fact). Let me know about that. I just made a quick test.

[eisoab]

Olivier Serve wrote:

I have checked pymol documentation and base code (python and cpp), check pymol itself, but I couldn't find any supplementary wildcard, so i guess I will to have to work with "/" for now. /

not sure about pymol wildcards. are they relevant? or are you translating xplor to pymol wildcards instead of matching the atom names directly?

/My guess is that on the same residue you can not have both H_X and H_XX, so in practice it should not a problem to replace + and ++ by a '/', since there is also a residue selection that should prevent misinterpretations.

note that for ligand atom names (my use case) there are in practice no conventions, so anything can happen. so e.g. H2 and H22 could both occur in the same residue.

Regarding your last comment, the (expected) current behavior is to assign the restraints without segid to chain "A", as it is the default name for structure with one un-named chain. So, there must be a bug in my code, that I have to check, everything should be displayed.

that would fail for most of my restraints, because I prefer the restraints to be without segid and usually take care that the residue nrs of both partners in a complex don't overlap. That gives more flexibility because some programs modify/strip the segids and in this way I don't have to worry about them.

I see the point in your recommendation and doing so would not change the expected behavior for a one chain un-named structure. I'll work on that as well.

E

[oserve]

Hello,
Your last comments (especially "matching the atom names directly") pointed out design flaws in old part of the code. Fortunately, I made some changes in the last few months that might allow me to implement a long term solution without too much pain. I have started to implement it, but it may take some time anyway.
I'll let you know when it's ready.

[oserve]

Hi,
Commit cbd79b3 should provide you with that you need. I added support for #, * and + and also corrected the segid issue you mentioned.
If you can give it a try and tell me if that works out for you, that'll be nice.
Since they are more tests, it's slower, I will check if I can improve that point.

[eisoab]

The restraints are still not accepted without segid.

Can't find HG* in structure complexfit_1 because : Wrong segment / chain
Selection issue with constraint :
( RESID 49 AND NAME HG* ) ( RESID 51 AND NAME HG* ) 3.52 3.52 0.00

ps how can I be sure pymol takes the new pyNMR version ?

[oserve]

Your question is a good one, since this error message should not appear anymore as I erased it from the code.There should not be a version problem with this update (it can happen only when modifying the main file, which I did not do for a while).  Maybe you can try erasing all .pyc files for a start ?  Envoyé depuis Yahoo Mail pour Android Le ven., mars 24, 2017 à 13:58, eisoab<notifications@github.com> a écrit : The restraints are still not accepted without segid. Can't find HG* in structure complexfit_1 because : Wrong segment / chain Selection issue with constraint : ( RESID 49 AND NAME HG* ) ( RESID 51 AND NAME HG* ) 3.52 3.52 0.00 ps how can I be sure pymol takes the new pyNMR version ? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[eisoab]

On Fri, Mar 24, 2017 at 2:34 PM, Olivier Serve ***@***.***> wrote: Your question is a good one, since this error message should not appear anymore as I erased it from the code.There should not be a version problem with this update (it can happen only when modifying the main file, which I did not do for a while). Maybe you can try erasing all .pyc files for a start ?

were should they be found, in the pymol installation tree? are the other py files in your distribution (NOE.py etc) also installed somewhere? E

…

Envoyé depuis Yahoo Mail pour Android Le ven., mars 24, 2017 à 13:58, ***@***.***> a écrit : The restraints are still not accepted without segid. Can't find HG* in structure complexfit_1 because : Wrong segment / chain Selection issue with constraint : ( RESID 49 AND NAME HG* ) ( RESID 51 AND NAME HG* ) 3.52 3.52 0.00 ps how can I be sure pymol takes the new pyNMR version ? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZStTvc2cqiT0gbAQatxujo3BP9GqGbDks5ro8ZTgaJpZM4MhtTf> .

[oserve]

Hi, The .pyc files should be in the same directory as the .py files (i.e. pymolNMR.py —> pymolNMR.pyc). They might be hidden though depending on your OS. Those files are created by python (in our case by the python embedded in pymol) each time the script is run and contain the code which is actually used by python. In theory, those files should be generated each time you run the plugin, however I have encountered situations where old versions were kept and therefore I could not use the new version of the script (it is rare). So here are the solutions I can think of, either you erased those files if you can see them (using a terminal for example), either, and I think it is simpler, you remove the folder containing all the files and re-download them from GitHub. Please, let me know if that help you out. I’ll be glad to help you more.

…

Le 28 mars 2017 à 20:01, eisoab ***@***.***> a écrit : On Fri, Mar 24, 2017 at 2:34 PM, Olivier Serve ***@***.***> wrote: > Your question is a good one, since this error message should not appear > anymore as I erased it from the code.There should not be a version problem > with this update (it can happen only when modifying the main file, which I > did not do for a while). > Maybe you can try erasing all .pyc files for a start ? > were should they be found, in the pymol installation tree? are the other py files in your distribution (NOE.py etc) also installed somewhere? E > Envoyé depuis Yahoo Mail pour Android > > Le ven., mars 24, 2017 à 13:58, ***@***.***> a écrit > : > The restraints are still not accepted without segid. > > Can't find HG* in structure complexfit_1 because : Wrong segment / chain > Selection issue with constraint : > ( RESID 49 AND NAME HG* ) ( RESID 51 AND NAME HG* ) 3.52 3.52 0.00 > > ps how can I be sure pymol takes the new pyNMR version ? > > — > You are receiving this because you were assigned. > > Reply to this email directly, view it on GitHub, or mute the thread. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#26 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AZStTvc2cqiT0gbAQatxujo3BP9GqGbDks5ro8ZTgaJpZM4MhtTf> > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABbLEXFnukQfLRw6bSrtDpBlJhnfBiHoks5rqUsDgaJpZM4MhtTf>.