[Molecularmechanics] Recycling CML

[Peter Murray-Rust]

At 17:21 05/11/2003 +0100, Konrad Hinsen wrote:
>On Wednesday 05 November 2003 16:38, Peter Murray-Rust wrote:
>
> > If you are prepared to expand this *internally* into a connection table
> > then there probably isn't a problem. If you wish to hold the higher level
> > formalism as the internal data structure it may be more difficult.
>
>Yes, internally this will be expanded (at least in my code).

Fine

>I don't think
>it's a good idea to base exchange formats on particular internal data
>structures.

I agree.

> > If you are only ever dealing with linear peptides it isn't a problem. If
> > you are dealing with a variety of small fragments which may be joined in a
> > variety of ways you need to think about the grammar. Crystallographers have
> > a dictionary of fragments - I hear regular moans about the hassle of
> > creating new fragments.
>
>What are the difficulties? I am using a rather similar approach in my code,
>and haven't had any difficulties in defining new fragments, nor have others
>who have worked on very different systems.

Fine. If you think that there is communal agreement about representations 
that everyone feels happy about implementing then that's great. I rather 
suspect that in small-molecule software there is less communality. In which 
case this may be useful for CML as well if it can be transferred downwards. 
The important thing is to make sure that it can be implemented and is 
generic and extensible.

>In my approach, a fragment can
>include

include?

>any other fragment and then add bonds to any atoms inside that
>fragment by using explicit paths to refer to them. There is no limit to the
>number or kind of links that can be created.

Does this mean a structure of the form:
<fragment>
   <fragment>
     <fragment>
     </fragment>
     <fragment>
     < /fragment>
     <bond/>s
   </fragment>
   <fragment>
   </fragment>
   <bond/>s
</fragment>

etc.?

>In the context of the representation we are discussing here, all that is
>required is a notation to refer to a sequence of elements defining ultimately
>one atom. This could be a list of ids, for example.
>
> > >I am not aware of any force field that requires such information as
> > >input. Moreover, the rare program that does need the information can
> > > figure it out for itself.
> >
> > To do this it probably has to expand the complete connection table.
>
>Yes, certainly. But that is not difficult to do.

Fine.