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

[Dr. Seth Olsen]

Hi Kirk,

Actually, I have always used NOORIENT (it's in the output file I 
attached),  however, your comment motivated me to test something - it 
seems that NOORIENT does not do this if it follows NOSYMM as in

geometry={nosymm;noorient;angstrom;

This is the format that I used in the output I sent previously (and the 
one I have always used).  However,

geometry={noorient;nosymm;angstrom;

works fine, leaving the order unaltered and keeping everything in the C1 
symmetry group. 

Many thanks.  I have apparently never tested the possibility that the 
ordering of these directives could matter.  A handful of scripts that I 
have written over the years to fix the problem the long way are now 
obsolete - and I am happy to see them go.   Cheers!

Best Regards,

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>
>
>