Orbital Occupation and Restarting OT calculations

[Matt W]

I think you have to fix multiplicity.

I'd think that it would likely be more efficient to relax/perform MD in one 
spin state, then check whether other spin states were competitive in many 
cases. This is where it really is annoying that currently you can't restart 
easily from the orbitals of a different spin state.

Matt

On Wednesday, August 12, 2015 at 8:46:00 PM UTC+1, Christopher O'Brien 
wrote:
>
> So is it still possible to use OT with ADDED_MOS or must multiplicity be 
> fixed. I am modeling a molecule interacting with a surface, I wanted to let 
> the spin state be allowed to change during the interaction if needed. I 
> don't want to give up on OT since it is so fast compared to diagonalization 
> for my large system.
>
> On Wednesday, August 12, 2015 at 10:45:28 AM UTC-6, Matt W wrote:
>>
>> I can confirm what you say, but I'm pretty sure it is incorrect behaviour 
>> of cp2k to run with OT and relax_multiplicity.  
>>
>> The relax_multiplicity flag must be getting ignored when the code does an 
>> atomic guess.
>>
>> Matt
>>
>> On Wednesday, August 12, 2015 at 4:51:07 PM UTC+1, Christopher O'Brien 
>> wrote:
>>>
>>> Matt,
>>> Thanks for you response.  Although I don't exactly understand how the OT 
>>> minimizer works, there is no error generated by CP2K or any mention of a 
>>> conflict between changing multiplicity in the documentation for the OT 
>>> minimizer.  
>>>
>>> However, I don't think there is a conflict with using OT and varying 
>>> multiplicity because using the same input, without the WFN file used as an 
>>> initial guess, runs without error.   
>>>
>>> On Wednesday, August 12, 2015 at 12:58:06 AM UTC-6, Matt W wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think the problem is coming from the relax multiplicity keyword in 
>>>> your input - that only seems to make sense to me using extra MOs and not 
>>>> the OT optimizer as it requires having extra MOs it can put electrons into 
>>>> to vary the multiplicity.
>>>>
>>>> Matt
>>>>
>>>> On Tuesday, August 11, 2015 at 8:05:28 PM UTC+1, Christopher O'Brien 
>>>> wrote:
>>>>>
>>>>> OT calculations cannot be restarted in CP2K.
>>>>>
>>>>> The error listed below results from using an existing WFN file and the 
>>>>> appropriate coordinates from another CP2K MD run to start a new 
>>>>> METADYNAMICS run. In my DFT section I have:
>>>>> &FORCE_EVAL
>>>>>
>>>>>  METHOD QS 
>>>>>  &DFT 
>>>>>
>>>>>     BASIS_SET_FILE_NAME BASIS_MOLOPT 
>>>>>     POTENTIAL_FILE_NAME GTH_POTENTIALS 
>>>>>     WFN_RESTART_FILE_NAME XXX-RESTART.wfn 
>>>>>     UKS
>>>>>     RELAX_MULTIPLICITY 0.15
>>>>>
>>>>>   &SCF
>>>>>
>>>>>     &OT 
>>>>>
>>>>>       PRECONDITIONER FULL_SINGLE_INVERSE
>>>>>       MINIMIZER CG
>>>>>
>>>>>     &END OT
>>>>>
>>>>>     EPS_SCF 1.0E-6
>>>>>     SCF_GUESS RESTART
>>>>>     MAX_SCF 100
>>>>>
>>>>>   &END SCF
>>>>>
>>>>>  &END DFT
>>>>>
>>>>>  &SUBSYS ...
>>>>>
>>>>> &END FORCE_EVAL
>>>>>
>>>>> However, after searching the manual I can't find an option to add MOs 
>>>>> to OT calculations. I also don't understand why I need to considering that, 
>>>>> in the output of the calculation I am starting from, all spins are already 
>>>>> paired. 
>>>>>
>>>>>  Spin 1 
>>>>>
>>>>>
>>>>>  Number of electrons: 1993 
>>>>>
>>>>>  Number of occupied orbitals: 1993 
>>>>>
>>>>>  Number of molecular orbitals: 1993 
>>>>>
>>>>>
>>>>>  Spin 2 
>>>>>
>>>>>
>>>>>  Number of electrons: 1993 
>>>>>
>>>>>  Number of occupied orbitals: 1993 
>>>>>
>>>>>  Number of molecular orbitals: 1993 
>>>>>  
>>>>>
>>>>>  Number of orbital functions: 15770 
>>>>>
>>>>>  Number of independent orbital functions: 15770 
>>>>>
>>>>>
>>>>>  Extrapolation method: initial_guess 
>>>>>
>>>>>
>>>>>  *** 04:08:41 WARNING in qs_mo_types:set_mo_occupation_2 :: All alpha 
>>>>> MOs *** 
>>>>>
>>>>>  *** are occupied. Add more alpha MOs to allow for a higher 
>>>>> multiplicity ***
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20150812/26d48b42/attachment.htm>