Re: [Wien] a doubt from threads in case.InM

2017-08-04 Thread Gavin Abo 
Ok, thanks.  I know see in the WIEN2k usersguide [1] for the NEWT method 
that the friction parameter ETA should effect the speed of movement when 
the atom is moving by the non-zero steps sizes Delta(1), Delta(2), 
and/or Delta(3) of the input values:


Delta(1) Delta(2) Delta(3) ETA

[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf 
(Section "8.15.3 Input" on page 174 of the WIEN2k 17.1 usersguide)
[2] 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/Optimization-Notes.pdf


On 8/4/2017 1:22 AM, Peter Blaha wrote:
It is NOT a divisor ! (does not make sense here). Depending on the 
method the 4th value is not used or is eg. a friction term for damped 
newton dynamics.


On 08/04/2017 02:26 AM, Gavin Abo wrote:

Currently too lazy to check, are the data values x y z div (where div is
the divisor)?

So (x y z)/div:

0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a
divide by zero error [2], it sounds like the code is able to handle it
and may be setting any of these divisions to 0.

0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.

[1] https://en.wikipedia.org/wiki/Division_by_zero

[2]
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/392791 



On 8/3/2017 9:26 AM, fatima DFT wrote:

Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0
0.0 1.0

So I was worried to repeat the calculation by fixing the position with
0.0. 0.0 0.0 1.0.

On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks
> wrote:

Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT > wrote:

Dear Prof. Peter, Oleg and Marks,

I have two queries for case.inM

First:

I stuck on case.inM file where I want to fix the positions of
the heavier atom for which I do not want to relax the 
structure.



A comment: fixing atoms does not do what people think, in general
it does not make the convergence of QM methods faster (it can for
CG). The convergence depends upon the number and density of the
elastic eigenvectors  (PORT) and the elastic-electronic system
(MSR1a).


In one thread Prof Peter

mentioned keeping 0 0 0 0 in the respective row of atom that I
want to constrain. But this four zeros means the entire line
should be zero

0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess >>> Say
it is for La atom.

As per Prof Marks
and
Prof. Oleg


The only first three number should be zero

0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess

Could you please clear my doubt that:

How the results will differ if I will use "0.0 0.0 0.0 0.0
#Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?


I am 99% confident that they are equivalent.


Second:

If I use "x pairhess" to generate the case.inM then does it
copy the case.inM according to the structure files? I just
tested it for two different structures and I saw two different
kind of case.inM.


Yes, different structures with different symmetries have different
symmetry constrained sites so different case.inM.



Thank you in advance

regards
Fatima




--
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu
 ; Corrosion in 4D:
MURI4D.numis.northwestern.edu 


Partner of the CFW 100% program for gender
equity, www.cfw.org/100-percent 
Co-Editor, Acta Cryst A
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

Re: [Wien] a doubt from threads in case.InM

2017-08-04 Thread fatima DFT 
So, it does not effect the results if one uses all zeros in respective row
or zero at first three places (x, y, z) and 1.0 at the last place. Correct?



On Fri, Aug 4, 2017 at 12:52 PM, Peter Blaha 
wrote:

> It is NOT a divisor ! (does not make sense here). Depending on the method
> the 4th value is not used or is eg. a friction term for damped newton
> dynamics.
>
> On 08/04/2017 02:26 AM, Gavin Abo wrote:
>
>> Currently too lazy to check, are the data values x y z div (where div is
>> the divisor)?
>>
>> So (x y z)/div:
>>
>> 0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a
>> divide by zero error [2], it sounds like the code is able to handle it
>> and may be setting any of these divisions to 0.
>>
>> 0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.
>>
>> [1] https://en.wikipedia.org/wiki/Division_by_zero
>>
>> [2]
>> https://software.intel.com/en-us/forums/intel-fortran-compil
>> er-for-linux-and-mac-os-x/topic/392791
>>
>> On 8/3/2017 9:26 AM, fatima DFT wrote:
>>
>>> Thank you very much Sir.
>>> I feel relax now.
>>> I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0
>>> 0.0 1.0
>>>
>>> So I was worried to repeat the calculation by fixing the position with
>>> 0.0. 0.0 0.0 1.0.
>>>
>>> On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks
>>> > wrote:
>>>
>>> Inlined
>>>
>>> On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT >> > wrote:
>>>
>>> Dear Prof. Peter, Oleg and Marks,
>>>
>>> I have two queries for case.inM
>>>
>>> First:
>>>
>>> I stuck on case.inM file where I want to fix the positions of
>>> the heavier atom for which I do not want to relax the structure.
>>>
>>>
>>> A comment: fixing atoms does not do what people think, in general
>>> it does not make the convergence of QM methods faster (it can for
>>> CG). The convergence depends upon the number and density of the
>>> elastic eigenvectors  (PORT) and the elastic-electronic system
>>> (MSR1a).
>>>
>>>
>>> In one thread Prof Peter
>>> >> mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_
>>> msg03285.html=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_
>>> d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=
>>> lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU=-6101yYtzjIzQW
>>> csyC0Zc5AQTUAs08Rf0kz5Ifefu7I=>
>>> mentioned keeping 0 0 0 0 in the respective row of atom that I
>>> want to constrain. But this four zeros means the entire line
>>> should be zero
>>>
>>> 0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say
>>> it is for La atom.
>>>
>>> As per Prof Marks
>>> >> mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_
>>> msg12403.html=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_
>>> d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=
>>> lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU=0fcEvAFHmpT7Za
>>> hxBQYrqD0Xr0DEsgKPFE0Nk-fLeLM=>and
>>> Prof. Oleg
>>> >> mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_
>>> msg01858.html=DwMFaQ=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_
>>> d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=
>>> lMntW40NGNoDrUMHYVU-vXvlVw2pGHikT4XpBt9gMhU=GJxC2Mi9-
>>> Fts6rULojSPz0X_acMQL2Oe5Ie7WXILcr0=>
>>>
>>> The only first three number should be zero
>>>
>>> 0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess
>>>
>>> Could you please clear my doubt that:
>>>
>>> How the results will differ if I will use "0.0 0.0 0.0 0.0
>>> #Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?
>>>
>>>
>>> I am 99% confident that they are equivalent.
>>>
>>>
>>> Second:
>>>
>>> If I use "x pairhess" to generate the case.inM then does it
>>> copy the case.inM according to the structure files? I just
>>> tested it for two different structures and I saw two different
>>> kind of case.inM.
>>>
>>>
>>> Yes, different structures with different symmetries have different
>>> symmetry constrained sites so different case.inM.
>>>
>>>
>>>
>>> Thank you in advance
>>>
>>> regards
>>> Fatima
>>>
>>>
>>>
>>>
>>> --
>>> Professor Laurence Marks
>>> "Research is to see what everybody else has seen, and to think
>>> what nobody else has thought", Albert Szent-Gyorgi
>>> www.numis.northwestern.edu
>>>  ; Corrosion in 4D:
>>> MURI4D.numis.northwestern.edu 
>>> Partner of the CFW 100% program for gender
>>> equity, www.cfw.org/100-percent 
>>> Co-Editor,

Re: [Wien] a doubt from threads in case.InM

2017-08-04 Thread Peter Blaha 
It is NOT a divisor ! (does not make sense here). Depending on the 
method the 4th value is not used or is eg. a friction term for damped 
newton dynamics.


On 08/04/2017 02:26 AM, Gavin Abo wrote:

Currently too lazy to check, are the data values x y z div (where div is
the divisor)?

So (x y z)/div:

0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a
divide by zero error [2], it sounds like the code is able to handle it
and may be setting any of these divisions to 0.

0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.

[1] https://en.wikipedia.org/wiki/Division_by_zero

[2]
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/392791

On 8/3/2017 9:26 AM, fatima DFT wrote:

Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0
0.0 1.0

So I was worried to repeat the calculation by fixing the position with
0.0. 0.0 0.0 1.0.

On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks
> wrote:

Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT > wrote:

Dear Prof. Peter, Oleg and Marks,

I have two queries for case.inM

First:

I stuck on case.inM file where I want to fix the positions of
the heavier atom for which I do not want to relax the structure.


A comment: fixing atoms does not do what people think, in general
it does not make the convergence of QM methods faster (it can for
CG). The convergence depends upon the number and density of the
elastic eigenvectors  (PORT) and the elastic-electronic system
(MSR1a).


In one thread Prof Peter


mentioned keeping 0 0 0 0 in the respective row of atom that I
want to constrain. But this four zeros means the entire line
should be zero

0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say
it is for La atom.

As per Prof Marks

and
Prof. Oleg



The only first three number should be zero

0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess

Could you please clear my doubt that:

How the results will differ if I will use "0.0 0.0 0.0 0.0
#Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?


I am 99% confident that they are equivalent.


Second:

If I use "x pairhess" to generate the case.inM then does it
copy the case.inM according to the structure files? I just
tested it for two different structures and I saw two different
kind of case.inM.


Yes, different structures with different symmetries have different
symmetry constrained sites so different case.inM.



Thank you in advance

regards
Fatima




--
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu
 ; Corrosion in 4D:
MURI4D.numis.northwestern.edu 
Partner of the CFW 100% program for gender
equity, www.cfw.org/100-percent 
Co-Editor, Acta Cryst A

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html





___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:

Re: [Wien] a doubt from threads in case.InM

2017-08-03 Thread Gavin Abo 
Currently too lazy to check, are the data values x y z div (where div is 
the divisor)?


So (x y z)/div:

0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a 
divide by zero error [2], it sounds like the code is able to handle it 
and may be setting any of these divisions to 0.


0.0. 0.0 0.0 1.0 => (0, 0, 0)/1 = (0, 0, 0) <- This may be safer to use.

[1] https://en.wikipedia.org/wiki/Division_by_zero

[2] 
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/392791


On 8/3/2017 9:26 AM, fatima DFT wrote:

Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0 
0.0 1.0


So I was worried to repeat the calculation by fixing the position with 
0.0. 0.0 0.0 1.0.


On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks 
> wrote:


Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT > wrote:

Dear Prof. Peter, Oleg and Marks,

I have two queries for case.inM

First:

I stuck on case.inM file where I want to fix the positions of
the heavier atom for which I do not want to relax the structure.


A comment: fixing atoms does not do what people think, in general
it does not make the convergence of QM methods faster (it can for
CG). The convergence depends upon the number and density of the
elastic eigenvectors  (PORT) and the elastic-electronic system
(MSR1a).


In one thread Prof Peter


mentioned keeping 0 0 0 0 in the respective row of atom that I
want to constrain. But this four zeros means the entire line
should be zero

0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say
it is for La atom.

As per Prof Marks

and
Prof. Oleg



The only first three number should be zero

0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess

Could you please clear my doubt that:

How the results will differ if I will use "0.0 0.0 0.0 0.0  
#Atom1 Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?



I am 99% confident that they are equivalent.


Second:

If I use "x pairhess" to generate the case.inM then does it
copy the case.inM according to the structure files? I just
tested it for two different structures and I saw two different
kind of case.inM.


Yes, different structures with different symmetries have different
symmetry constrained sites so different case.inM.



Thank you in advance

regards
Fatima




-- 
Professor Laurence Marks

"Research is to see what everybody else has seen, and to think
what nobody else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu  ;
Corrosion in 4D: MURI4D.numis.northwestern.edu

Partner of the CFW 100% program for gender equity,
www.cfw.org/100-percent 
Co-Editor, Acta Cryst A

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html





___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at

Re: [Wien] a doubt from threads in case.InM

2017-08-03 Thread fatima DFT 
Thank you very much Sir.
I feel relax now.
I did a heavy calculation using 0.0. 0.0 0.0 0.0 instead of 0.0. 0.0 0.0 1.0

So I was worried to repeat the calculation by fixing the position with 0.0.
0.0 0.0 1.0.

On Thu, Aug 3, 2017 at 8:31 PM, Laurence Marks 
wrote:

> Inlined
>
> On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT  wrote:
>
>> Dear Prof. Peter, Oleg and Marks,
>>
>> I have two queries for case.inM
>>
>> First:
>>
>> I stuck on case.inM file where I want to fix the positions of the heavier
>> atom for which I do not want to relax the structure.
>>
>
> A comment: fixing atoms does not do what people think, in general it does
> not make the convergence of QM methods faster (it can for CG). The
> convergence depends upon the number and density of the elastic eigenvectors
>  (PORT) and the elastic-electronic system (MSR1a).
>
>>
>> In one thread Prof Peter
>> 
>> mentioned keeping 0 0 0 0 in the respective row of atom that I want to
>> constrain. But this four zeros means the entire line should be zero
>>
>> 0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say it is for La
>> atom.
>>
>> As per Prof Marks
>> and
>> Prof. Oleg
>> 
>>
>> The only first three number should be zero
>>
>> 0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess
>>
>> Could you please clear my doubt that:
>>
>> How the results will differ if I will use "0.0 0.0 0.0 0.0   #Atom1
>> Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?
>>
>
> I am 99% confident that they are equivalent.
>
>>
>> Second:
>>
>> If I use "x pairhess" to generate the case.inM then does it copy the
>> case.inM according to the structure files? I just tested it for two
>> different structures and I saw two different kind of case.inM.
>>
>
> Yes, different structures with different symmetries have different
> symmetry constrained sites so different case.inM.
>
>>
>>
>> Thank you in advance
>>
>> regards
>> Fatima
>>
>
>
>
> --
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> www.numis.northwestern.edu ; Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
>
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/index.html
>
>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] a doubt from threads in case.InM

2017-08-03 Thread Laurence Marks 
Inlined

On Thu, Aug 3, 2017 at 9:49 AM, fatima DFT  wrote:

> Dear Prof. Peter, Oleg and Marks,
>
> I have two queries for case.inM
>
> First:
>
> I stuck on case.inM file where I want to fix the positions of the heavier
> atom for which I do not want to relax the structure.
>

A comment: fixing atoms does not do what people think, in general it does
not make the convergence of QM methods faster (it can for CG). The
convergence depends upon the number and density of the elastic eigenvectors
 (PORT) and the elastic-electronic system (MSR1a).

>
> In one thread Prof Peter
> 
> mentioned keeping 0 0 0 0 in the respective row of atom that I want to
> constrain. But this four zeros means the entire line should be zero
>
> 0.0 0.0 0.0 0.0   #Atom1 Generated by pairhess   >>> Say it is for La
> atom.
>
> As per Prof Marks
> and
> Prof. Oleg
> 
>
> The only first three number should be zero
>
> 0.0 0.0 0.0 1.0   #Atom1 Generated by pairhess
>
> Could you please clear my doubt that:
>
> How the results will differ if I will use "0.0 0.0 0.0 0.0   #Atom1
> Generated by pairhess" instead of 0.0 0.0 0.0 1.0 ?
>

I am 99% confident that they are equivalent.

>
> Second:
>
> If I use "x pairhess" to generate the case.inM then does it copy the
> case.inM according to the structure files? I just tested it for two
> different structures and I saw two different kind of case.inM.
>

Yes, different structures with different symmetries have different symmetry
constrained sites so different case.inM.

>
>
> Thank you in advance
>
> regards
> Fatima
>



-- 
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu ; Corrosion in 4D: MURI4D.numis.northwestern.edu
Partner of the CFW 100% program for gender equity, www.cfw.org/100-percent
Co-Editor, Acta Cryst A
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html