Hi All As I see the best available solution is to go for coordinates all in one. I.e. ligands description and the rest of structure in one file. It should be possible to do it with mmcif. then each ligand (apart from standard ones) will be property of a coordinate set and no conflict between ligands Then everybody should use mmcif and get used to it.
Regards Garib On 24 Jan 2012, at 22:12, Sheriff, Steven wrote: > All: > > At BMS, we use the same ligand identifier, e.g. LG1, for all compounds that > bind at overlapping sites. If we have multiple compounds bound in a single > structure, i.e. non-overlapping sites, then we would use LG2, etc. for them. > Using a common naming system makes it easy for upstream and downstream > programs and users to know what to look for. So, if I want to compare two > proprietary structures in COOT pre-0.7, then something along the lines that > Paul suggests is the easiest way to deal with this. Otherwise I have to > modify both the PDB file and relevant CIF restraint file. Someday some of > these structures do end up in the wwPDB and they do a good job of > disambiguating them and assigning unique 3-character identifiers (BTW, the > PDB as far as I know is still using only capital letters, so this translates > into only 36**3 (46656) unique 3-character names of which >8000 have been > assigned as of the last time I paid attention). > > And, yes, companies do have unique “names” for their compounds. At BMS, they > consist of 9 characters, but I have seen other companies naming schemes use > 11 characters. Neither of which is easily translated into 3 characters. > > Steven > > From: Mailing list for users of COOT Crystallographic Software > [mailto:[email protected]] On Behalf Of Seth Harris > Sent: Tuesday, January 24, 2012 4:53 PM > To: [email protected] > Subject: Re: New restraints, same name > > Hi all, > > Working in industry, we do end up with conventions that just give a generic > name to whatever small molecule happens to be in that structure, typically > LIG or DRG or XXX, e.g.. Makes it easy to navigate solved structures en masse > without having to figure out what arbitrary name it has in structure X vs Y > vs Z and the benefits of the convention outweigh the potential drawbacks, so > far. Generally I don't find conflict between different structures because at > that stage I'm done with refinement and the viewer programs don't care about > the restraint dictionaries. I'm assuming coot can still draw the atoms based > on coordinates and only creates the tangles if you try to refine those with > the restraints, yes?? > So then the issue of multiple small molecules in one structure, Carsten's > point is spot on for me as well, where there's no point in having a > coot-specific solution since the other refinement packages are going to choke > as soon as you have two different ligands sharing the residue name so you > might as well fix it on the pdb side. I think Paul's original question was > really around the issue of loading two separate structures which have a > common residue name identifier despite being different chemical entities. I > guess I am wondering more and more about the opening statement of "Now that > Coot uses the restraints dictionary to render ligands..." as i have not kept > up with the latest...Nonetheless for my particular workflow I have scripts > that launch an instance of Coot with a given structure and maps and it is > rare that I bring in a second one. If I did, and Coot is going to not display > the ligand correctly because its name is already taken then true it would be > handy if Coot could sort this out and keep the separate restraints > definitions appropriately sorted by molecule number of some internal > identifier. If the molecules look fine and it's only when one attempts real > space refinement or such that it would get scrambled (current behavior in my > admittedly-not-the-most-recent version of Coot, 0.6.1) then I wouldn't bother > as that situation is rare for me (and I imagine for others(?)) and I agree > with the votes that the fix should be on the user to sort out. Perhaps Paul > you can clarify if we're talking even simple display is affected or just > refinement operations as past? > > On a side note, during yesterday's run by the bay here I passed a grazing > flock or two of what must surely have been coots given their striking > resemblance to the splash screen icon. Watching my step, I can attest that > there is certainly quite a mess in their internals, but I imagine Paul's coot > is better kept...! > > Cheers, > Seth > > > On Tue, Jan 24, 2012 at 12:46 PM, Ed Pozharski <[email protected]> wrote: > On Tue, 2012-01-24 at 15:26 -0500, Kendall Nettles wrote: > > That didn't come out right. What I meant to say was that he are often > > comparing structures from a series of closely related compounds. > > But isn't it true that non-identical compounds should have different > names? Paul also refers to refinement (i.e. when dictionary is needed), > not comparison (the latter should be fine with identical names). > > Cheers, > > Ed. > > -- > Oh, suddenly throwing a giraffe into a volcano to make water is crazy? > Julian, King of Lemurs > > > This message (including any attachments) may contain confidential, > proprietary, privileged and/or private information. The information is > intended to be for the use of the individual or entity designated above. If > you are not the intended recipient of this message, please notify the sender > immediately, and delete the message and any attachments. Any disclosure, > reproduction, distribution or other use of this message or any attachments by > an individual or entity other than the intended recipient is prohibited.
