Re: [Wien] analyse_phonon--"pos case not found" error

2015-10-12 Thread Peter Blaha 
When you initialized the case_3, did you obey the rule, that changes 
from sgroup MUST NOT be taken into account. When sgroup changes the 
lattice tape (eg. introduces some centering, ...) the analysis will not 
work.


On 10/09/2015 01:42 PM, Battal Gazi Yalçın wrote:

Dear Prof. Blaha and wien2k users,

I want to calculate phonon properties of CuBS2 chalcopyrite structure by
means of PHONON 6.10 software.

After created case.d45 file, scf calcultaion for all cases have finished
without error. (convergence criteria: ec :0.0001 Ry cc :0.001 e and fc
:0.1 mRy/a.u and RKmax:6 and 8-kpoint)


in terminal, : one can see:

yalcin@yalcin-superpc:~/Desktop/phon610_64/run/CuBS2_2x2x1$ grep "Sum"
*_8K.scf
case_1_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
-0.006465023 0.005725508 0.002114469
case_2_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.0 0.0 0.004102549
case_3_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.0 0.0-0.017363207
case_4_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.000457910-0.038465946 0.017802203
case_5_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.003561049-0.011319303-0.006378147
case_6_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.037181721-0.020520483-0.000281537
case_7_PBE_RKM6.00_8K.scf::FCHECK:   Sum of forces
0.0 0.0 0.008966570

But, When I used the  command "analyse_phonon" or "analyse_phonon case.d45"

*
Should the analysis be made using   case_*/case_*_lda_rkm6.00_8k.scf
-files ? (Y/n)
n
Enter the part of the filename which identifies the scf-files uniquely
(e.g. enter "_gga_rkm7.5_100k" for  case_*/case_*_gga_rkm7.5_100k.scf)
_PBE_RKM6.00_8K
  Program generates  Phonon-Hellman-Feynman file from WIEN calculations

  Filename of phonon file:
  CuBS2_2x2x1.d45
Sum of forces (should be zero) for case   1:   -0.00650.00570.0021
Sum of forces (should be zero) for case   2:0.0.0.0041
_*pos_case not found*_
The HF-force file CuBS2_2x2x1.dat for phonon has been produced.
The symmetrized HF-force file CuBS2_2x2x1.dsy for phonon has been produced.

**
The sum of forces are created for only case 1 and 2, and then "pos case
not found". I m not sure this error is important or not. But, using the
created case.hff file, phonon software is not working.

( First, I have tested for "Si" element and PHONON worked without error.)



What is your recommendation?

Battal Gazi Yalcin
Sakarya University Department of Physics
Sakarya TURKEY


___
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



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--
___
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] CHARGE DENSITY --> TOTAL CHARGE

2015-10-12 Thread Laurence Marks 
Rather than giving the answer to the original question, I think it is
better to try and encourage people to solve problems themselves -- perhaps
I am being too much of an teacher, but that is my approach.

So, let me pose a question in response to the original question. What is
the relationship between summing a set of values on a grid and the integral
of a function sampled at a set of grid points. Think about this, and the
reason why the numbers are very different will be obvious.

If they still do not completely agree (they wont), then think about the
accuracy of numerical integration. It is quite important in DFT codes to
remember that numerical integrations are never exact, and this leads to
many small limitations.

On Mon, Oct 12, 2015 at 3:39 AM, Elias Assmann 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/08/2015 07:34 PM, prasenjit roy wrote:
> > I want to obtain the total number of electron in the unit cell, by
> > summing over the total charge density within that unitcell and then
> > match that number to the "atomic numbers times the respective
> > multiplicity". Since WIen2K is full electron code, I expect these
> > two be equal.
>
> I have never tried that, but I would expect the number to depend quite
> sensitively on your mesh of r-points.  At least, this is what I saw
> when I looked at normalization of Wannier functions on an r-grid.
> Since you want also the core electrons, you could actually expect even
> larger spikes.
>
> > The system I worked on is : Mn6Fe6Si2P4 (total electron 394 in
> > unitcell). When I summed up all the densities over the mesh (I
> > chose 74*74*80 points), I obtained ~257050.
>
> However, this I would say sounds more like some missing factor …
> Units?  dV?
>
>
> Elias
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJWG3HAAAoJEE/4gtQZfOqPmxoP/2pSiQe7vm2b5q9eyjN9X5VN
> pQvq+RUE8F5pjgSK8W86YlRCFK34TIw3b8g7OvRW6noaeUGLqszWpFArfF0ToRE7
> +kS9+YcVLzoogCSoan5demVARHdP5oyKcv08NOpQBwndPYgvCAlPm+nN+Wg9T/m+
> b6znR2WzoXdLaMxK3uQW94fK+D/T2k4fDRSrd0rU5BU7FztzJ/qnbiywtZqnJbZ5
> mXUJCQuC+E5Uw1XGEvWR8XIisW5n/ZY1d27PHRStSG3utFbZxfdhxYpHHSAWX0di
> SIO/DSfp1UGte3sfcjmtc41QFNBod1El6frLxNehmEhY4jMgsJRWST4qEblLdfk4
> fSz0cSRplff4WAQkiNUnFK2wiHtB/ZceiXDM1dxZmo76ItkyBMu0oDUpwpw75r3f
> s+otHS2XPsMnd9knD0D7SXf5Ko3qNNR/Sj0hWBfpdPwHmDpg8k0clu23vGc6srWK
> ISJrtABNcSDBuJp9IhURLc7VpbUCfKJ0WFXSLLorTXM5eb2oNJT+MPm4EDxK9zyQ
> gaMcnV3nxoYYsNjgVwG4Du8XZO90T+Zc8AAdP7t1VW88QAMy85g9q1CH21AS3nnk
> HSna4W7R3vTd2XP2cTQ2UYIKBzyBQYj/9HbNV7F0e5FlzMfirgPj3j2HVvTJLVYm
> murT9xCL6Q8O0PH6SZHw
> =Gwas
> -END PGP SIGNATURE-
> ___
> 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
>



-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
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] CHARGE DENSITY --> TOTAL CHARGE

2015-10-12 Thread Elias Assmann 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/08/2015 07:34 PM, prasenjit roy wrote:
> I want to obtain the total number of electron in the unit cell, by
> summing over the total charge density within that unitcell and then
> match that number to the "atomic numbers times the respective
> multiplicity". Since WIen2K is full electron code, I expect these
> two be equal.

I have never tried that, but I would expect the number to depend quite
sensitively on your mesh of r-points.  At least, this is what I saw
when I looked at normalization of Wannier functions on an r-grid.
Since you want also the core electrons, you could actually expect even
larger spikes.

> The system I worked on is : Mn6Fe6Si2P4 (total electron 394 in
> unitcell). When I summed up all the densities over the mesh (I
> chose 74*74*80 points), I obtained ~257050.

However, this I would say sounds more like some missing factor …
Units?  dV?


Elias


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJWG3HAAAoJEE/4gtQZfOqPmxoP/2pSiQe7vm2b5q9eyjN9X5VN
pQvq+RUE8F5pjgSK8W86YlRCFK34TIw3b8g7OvRW6noaeUGLqszWpFArfF0ToRE7
+kS9+YcVLzoogCSoan5demVARHdP5oyKcv08NOpQBwndPYgvCAlPm+nN+Wg9T/m+
b6znR2WzoXdLaMxK3uQW94fK+D/T2k4fDRSrd0rU5BU7FztzJ/qnbiywtZqnJbZ5
mXUJCQuC+E5Uw1XGEvWR8XIisW5n/ZY1d27PHRStSG3utFbZxfdhxYpHHSAWX0di
SIO/DSfp1UGte3sfcjmtc41QFNBod1El6frLxNehmEhY4jMgsJRWST4qEblLdfk4
fSz0cSRplff4WAQkiNUnFK2wiHtB/ZceiXDM1dxZmo76ItkyBMu0oDUpwpw75r3f
s+otHS2XPsMnd9knD0D7SXf5Ko3qNNR/Sj0hWBfpdPwHmDpg8k0clu23vGc6srWK
ISJrtABNcSDBuJp9IhURLc7VpbUCfKJ0WFXSLLorTXM5eb2oNJT+MPm4EDxK9zyQ
gaMcnV3nxoYYsNjgVwG4Du8XZO90T+Zc8AAdP7t1VW88QAMy85g9q1CH21AS3nnk
HSna4W7R3vTd2XP2cTQ2UYIKBzyBQYj/9HbNV7F0e5FlzMfirgPj3j2HVvTJLVYm
murT9xCL6Q8O0PH6SZHw
=Gwas
-END PGP SIGNATURE-
___
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] CHARGE DENSITY --> TOTAL CHARGE

2015-10-12 Thread Víctor Luaña Cabal 
On Mon, Oct 12, 2015 at 04:43:24AM -0500, Laurence Marks wrote:
> Rather than giving the answer to the original question, I think it is
> better to try and encourage people to solve problems themselves -- perhaps
> I am being too much of an teacher, but that is my approach.
> 
> So, let me pose a question in response to the original question. What is
> the relationship between summing a set of values on a grid and the integral
> of a function sampled at a set of grid points. Think about this, and the
> reason why the numbers are very different will be obvious.
> 
> If they still do not completely agree (they wont), then think about the
> accuracy of numerical integration. It is quite important in DFT codes to
> remember that numerical integrations are never exact, and this leads to
> many small limitations.

Laurence,

I love your approach. May I continue?

There are two main strategies in doing a numerical integration. The
first is designing the geometry of the grid by simplicity and providing
each grid point an equal weight. The alternative approach is far more
complex, but it can also be more successful. The position and weight
of grid points can be used to improve the quality of the integration.

Best regards,
 Víctor Luañ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] analyse_phonon--"pos case not found" error

2015-10-12 Thread Battal Gazi Yalçın 
Dear Prof. Blaha,

It is solved by means of your advice.

Thanks


Battal Gazi Yalcin
Sakarya University Department of Physics
Sakarya TURKEY
___
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