DMACRYS interface

From Docswiki
Jump to navigation Jump to search

The interface

The current idea of the interface is to use the dmacrys main code (routine CASCAD) to parse the input files and initialize all variables. At the point the parser reaches STOP in the input, it thinks the DMACRYS job is done and exits. That is the point were GMIN comes into play.

Remarks on the DMACRYS code

  • PLUTO is the minimizer, interesting for the interface it the initialization till the first call of FRCNST. Parts of this code were copied to the GMIN interface
  • The routine to calculate energies is FRCNST
  • FRCNST need 3 field which have to be initialized. In DMACRYS that is done in CASCAD and it's local fields (jbarr, ibarr, iarr). To access these from the GMIN interface, they were moved to the module CASCAD_EXPORT
  • The gradients of rigid bodies are stored in gstiff. The first 3*NRIGID are the translational coordinates, then 3*NRIGID orientational coordinates, then 6 lattice vectors. The orientational gradients for small rotations around the unrotated molecule (in lab frame). To convert these to angle axis use dTheta = RkR(-p), dpk = \sum_i dTheta_i dU/dTheta_

Remarks on interfacing DMACRYS and GMIN

  • I'm quite impressed how bad PGI is at checking naming conflicts. If two routines with the same name are defined in different libraries (.a files), PGI linker will not complain. As a way out, I completely skipped libraries and added all source files directly to executable. That revealed 2 naming conflicts for the subroutines INPUT and QUAD. These have to be renamed in DMACRYS! UPDATE: the new PGI is slightly better, but as Davids recommends, don't use PGI!
 sed -ie "s/INPUT(/INPUTDMA(/" *.f90
 sed -ie "s/QUAD(/QUADDMA(/" qextra.f90 qinter.f90 quad.f90
  • Another naming conflict I'm much more worried about: In the file <dmacrys>/include/phox is a common block REST. REST is also a subroutine defined in GMIN. The compiler didn't complain at all, but a segfault appeared at a completely different place. I renamed REST now to RESTDMA -> works. There is definitively a better solution needed for interfacing / detecting conflicts. Tried NAG compiler, it found quite a few problems in DMACRYS code.--Vr274 16:49, 28 October 2011 (UTC).

Moves via XML

This idea has been cancelled, use new Python interface instead I'm thinking of implementing a move protocol using an xml file a possible layout would be

<moves>
  <block n="100">
    <translate dX="0.3" dY="0.3" dZ="0.3"/>
    <angleaxis dTheta="0.5"/>     
    <lattice dE1="0.5" dE2="0.5" dE3="0.5" dE4="0.0" dE5="0.0" dE6="0.0"/>
  </block>
  <block n="100">
    <expand dE1="2.0" dE2="2.0" dE4="2.0"/>
    <translate dX="0.2" dY="0.2" dZ="0.2"/>
  </block>
</moves>

One could also add an option to only move a subset of molecules.