On 24 January 2012 17:53, Paul Emsley <[email protected]> wrote:
> Now that Coot uses the restraints dictionary to render ligands it has become
> apparent that the method of doing so is problematic for typical working
> situations.
>
> Say for example your read in
> complex-XYZ00123456.pdb in which the ligand is called LIG
> You read in the dictionary for XYZ00123456 and the ligand looks fine.
>
> Now read in
> complex-XYZ00123457.pdb in which the ligand is called LIG
> Different compound, same name, so same dictionary is used to render
> XYZ00123457.
> Result: tangled mess
>
> Read in dictionary for XYZ00123457 and now complex-XYZ00123457 looks fine
> but XYZ00123456 is a tangled mess because the restraints for LIG have been
> overwritten.
>
> So I am considering adding in a hack to Coot to make this situation less
> problematic.
>
> A potential hack is to specify that it is to be used for molecule number N
> (or a set of Ns) only.
>
> Doing this would make Coot internals messy so I have make this request for
> comments before I spend time reworking things and producing a solution that
> no-one will use.
Paul, the situation you describe never arises for us (Astex) simply
because we don't allow users to directly access to the filesystem
containing the data, so they simply cannot load arbitrary files from
refinements into WinCoot. However I can see it might be a problem for
users who do load files from their filesystem. We have a CGI script
running on the webserver which uses a unique refinement ID to identify
all the session files needed (MTZ + protein & ligand PDBs), does the
necessary security checks to ensure that the user is allowed to see
and modify the data, and if so fetches them from our Oracle DB. The
script makes any changes to the ligand residue IDs necessary to make
them unique for the session (we use 'L01', 'L02', ... 'L99'),
generates a unique CIF for each ligand, then passes the whole lot
through to a Java linking applet ('CootLink') running in the browser,
which finally loads and fires up a Coot script on the user's PC. At
the end of the session any changed PDBs are passed back through
CootLink and stored back in the DB as a new version ID under the same
refinement ID. Of course the price of this automation is that someone
(i.e. me) has to maintain the scripts (such as if/when you change the
way Coot works!). So far this has been relatively straightforward
because we only ever use Coot for building individual structures, we
never use it as a viewer, say for comparing different structures (we
only use AstexViewer for that).
So I would only ask that wherever possible changes are made in a
backwards-compatible manner, for example would it be possible that any
additional user input is optional and is only needed to resolve
ambiguities such as those you describe? In that way the changes you
propose would be completely transparent as far as we are concerned.
Of course I appreciate that most other users do things differently and
it may not be possible to make the changes completely transparent. If
that turns out to be the case then so be it.
Cheers
-- Ian
