[Molecularmechanics] Recycling CML

[Pengyu Ren]

I agree that intermolecular bonds are force field dependent. For example, MM3 and some force fields have special hydrogen bond inter- or intramolecularly, others don't. 

It certainly would be nice if the more information may be included such ring,ring overlaps (many supramolecular parts), backbone and side chain atoms (polymers), ionic/colvalent bond, transition metal ligand-field.... But I think we should worry about the common denominator. Each forcefield has to do some parsing for their corresponding model.  

About the atom ID, can we assign a _global_ label to each atom (smallest unit), like 1,2,3,4... for easy acess?


Regards,
Pengyu


======= 2003-11-05 15:44:08 original messages===

>At 17:39 05/11/2003 +0100, Konrad Hinsen wrote:
>>On Tuesday 04 November 2003 22:03, Peter Murray-Rust wrote:
>>
>>
>> > changed do all the others?) CML also has an inheritance mechanism:
>> >
>> > <molecule ref="ala" mode="inherit">
>> >    <atomArray>
>> >      <atom ref="calpha" x3="12.3" y3="10.2" z3="2.3"/>
>> > ...
>>
>>What are the modifications that are possible with that mechanism? I am
>>thinking of the modifications that David presented in his proposal, for
>>defining variants of fragments (e.g. the N-terminal variant of an amino acid
>>residue). Such a modification involves adding and removing atoms and bonds.
>
>There are 3 main modes:
>- override/overwrite (replace existing values with new ones, but keep those 
>without replacement values)
>- merge - add in new information where is does not conflict with previous
>- replace - replace existing molecule with the new information without 
>retaining any of the old info
>
>Therefore bonds could be deleted by using the last mode.
>
>The design was intended to provide different snapshots (for whatever 
>reason) of a molecule. The initial impetus was dynamics and conformations - 
>things like element type and bonds would be kept constant. But there is no 
>reason why bonds should not be changed.
>
>The design was originally to create different instances of the same 
>molecule, but there is no reason in principle why it shouldn't be used to 
>clone them as well.
>
>This could be promising.
>
>BTW - I may seem overcautious  - feel free to ignore this:-). So long as 
>designs are matched by software implementations (especially if they reflect 
>existing ones) things are fine. But I have seen too many paper specs that 
>were surprisingly hard to implement. There are several early designs in CML 
>(admittedly forced by the lack of Schemas rather than DTDs) which have 
>caused much more effort than originally expected.
>
>Best
>
>P.
>
>
>>Konrad.
>>--
>>-------------------------------------------------------------------------------
>>Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
>>Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
>>Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
>>45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
>>France                                   | Nederlands/Francais
>>-------------------------------------------------------------------------------
>>
>>_______________________________________________
>>Molecularmechanics mailing list
>>Molecularmechanics@tddft.org
>>http://www.tddft.org/mailman/listinfo/molecularmechanics
>
>_______________________________________________
>Molecularmechanics mailing list
>Molecularmechanics@tddft.org
>http://www.tddft.org/mailman/listinfo/molecularmechanics

= = = = = = = = = = = = = = = = = = = =