[molpro-user] Overriding geometry (and basis) reordering in molpro?

[Dr. Seth Olsen]

Hi Molpro-Users,

I recind my joy.  Upon looking back at the output, it does not seem that 
'noorient' does this.  I believe that it just leaves the molecule fixed 
in the spatial orientation in which it was input.  It does not seem to 
fix the sorting of the atomic centers according to element.  Until I 
figure out a hidden switch or a magic word, I'm probably just going to 
chalk this up to one of those quirky things that MolPro does in the name 
of efficiency which end up getting in the way if you don't need them 
(like, for example, unlinked temporary files).  I'm quite sure that if 
symmetry is used, than this sorting can come in handy.  My tough luck 
that I don't use symmetry often. 

Probably sometime soon I'll write up a python script to do the orbital 
splicing automatically from ASCII files that matrop writes out.  This 
will save a little effort and inconvience by eliminating the need for 
complicated offset jockeying in the merge deck.  When I have this 
working to my satisfaction, I'll post it to the list.

Cheers,

Seth

Kirk Peterson wrote:

> Hi Seth,
>
> I believe you need the "noorient" command:
>
> geometry={noorient;
> ...
> }
>
> You just have to make sure your geometry input reflects the full  
> symmetry correctly, otherwise
> it may not be detected. The other related option is to add dummy  
> atoms in the monomer
> calculations so that the geometry block is ordered just like the  
> dimer calculation. I generally
> use this in Merge situations.
>
> best wishes,
>
> Kirk
>
> On Mar 23, 2006, at 9:05 PM, Dr. Seth Olsen wrote:
>
>>
>> Hi Molpro-Users,
>>
>> Is there any way to override MolPro's default tendency of  reordering 
>> the atoms in a molecule to group all members of a given  element 
>> together?  I've been trying to use MERGE to splice together  orbitals 
>> of benzene dimer from monomer calculations, and everything  gets 
>> mangled because as soon as the dimer geometry is read in, the  basis 
>> is reordered and the merged orbitals become useless.  I have  turned 
>> all symmetry and extra symmetry mechanisms off, and given  the 
>> carbons and hydrogens from each monomer their own basis group  
>> number, but it doesn't seem to turn off the default of reordering  so 
>> that all C's are in one block and all H's in another.  I've  attached 
>> the output, which also displays the output of MERGE before  and after 
>> orthonormalization (I've gzipped the file).
>>
>> I think that I can get this done with MERGE or MATROP by the end of  
>> the day, now that I know what the problem is.  However, this issue  
>> also comes up regularly when (for example) MOLEKEL or GABEDIT is  
>> used to visualize MOLDEN output created by MolPro.  Neither MOLEKEL  
>> nor GABEDIT seem capable of mapping basis to atoms if the ordering  
>> of the atoms is changed relative to the ordering of the basis (as  in 
>> MolPro-output MOLDEN files, where the atoms are rearranged but  the 
>> basis is not - although there is a number attached to each  function 
>> to identify it's atom, it seems that neither MOLEKEL nor  GABEDIT pay 
>> attention).
>> Can this behavior be turned off?
>>
>> Cheers,
>>
>> Seth
>>
>> <dimer-frags-rohf-631p.out.gz>
>
>


-- 
ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms

Dr Seth Olsen, PhD
Postdoctoral Fellow, Biomolecular Modeling Group
Centre for Computational Molecular Science
Chemistry Building,
The University of Queensland
Qld 4072, Brisbane, Australia

tel (617) 33653732
fax (617) 33654623
email: s.olsen1 at uq.edu.au
Web: www.ccms.uq.edu.au 

ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms