The ABINIT Users Mailing List ( CLOSED )

[Masayoshi Mikami <mmikami@rc.m-kagaku.co.jp>]

Dear Sun,

Thanks for following the spirit of our Netiquette and
Problem report format. Still, we would like to confirm
your ifc version. (ifc v.7.1 or  v.8.1 or v.9.x ? ...
you can check with "ifc -V" or "efc -V" or "ifort -V" etc.)
In passing, your abinis is compiled on your PC,
or downloaded from ABINIT WEB site ?

I noticed that your input can run on some platforms
(still with something strange !) -- "Case-A"-- and
cannot run (with segmentation faults) on others,
-- "Case-B" -- with v.4.6.5.

Case-A: It run ... but numerical difference observed:
- ifc v.7.1 (Build 2003081) on Itanium2
 ETOT  1  -50.702500962382
 ETOT 15  -51.450857397678

- Fujitsu VPP700 series (VERRRRY OLD machine)
 ETOT  1  -50.081522427799
 ETOT 15  -52.664132599664

The above was obtained with 80hg.12.hgh & 16s.6.hgh,
retrieved from ABINIT web site. If 80hg.2.hgh is used,
the numerical difference disappeared practically.

- ifc v.7.1 (Build 2003081) on Itanium2 (kernel  2.4.24)
 ETOT  1  -11.439210903938
 ETOT 15  -11.479759001623

- Fujitsu VPP700 series (VERRRRY OLD machine)
 ETOT  1  -11.439210903937
 ETOT 15  -11.479759001622

Hmm ... something should be there ...

Case-B: It failed with "segmentation fault":
- ifc v.8.1(Build 20040922, l_fc_pc_8.1.019) on the Itanium2
- MacOSX (10.3.9),  xlf 8.1
  The log file (on the Itanium2) read like this:
-------------------
- pspatm: opening atomic psp file    80hg.12.hgh
 Hartwigsen-Goedecker-Hutter psp for Hg,  from PRB58, 3641 (1998)
  80.00000  12.00000     10605                znucl, zion, pspdat
    3    1    2    0      2001   0.00000      
pspcod,pspxc,lmax,lloc,mmax,r2well

 pspatm: WARNING -
  Pseudopotential file pspxc=       1,
  not equal to input ixc=       2.
  These parameters must agree to get the same xc
  in ABINIT code as in psp construction.
  Action : check psp design or input file.
  Assume experienced user. Execution will continue.

 rloc=   0.5700000
 cc1 =   2.1345720; cc2 =   0.0000000; cc3 =   0.0000000; cc4 =   
0.0000000
 rrs =   0.5218020; h11s=   3.2939200; h22s=   4.6610010; h33s=   
0.0000000
 rrp =   0.6216480; h11p=   2.1009600; h22p=   1.6899880; h33p=   
0.0000000
                    k11p=   0.0849890; k22p=   0.0727710; k33p=   
0.6533480
 rrd =   0.4018940; h11d=  -1.6698860; h22d=  -2.4732650; h33d=   
0.0000000
                    k11d=   0.1557590; k22d=  -0.1222820; k33d=   
0.0000000
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        
Source

abinis             4000000000F82C30  Unknown               Unknown  
Unknown
abinis             4000000000DE5710  Unknown               Unknown  
Unknown
abinis             4000000000DDF1A0  Unknown               Unknown  
Unknown
abinis             4000000000DC5E30  Unknown               Unknown  
Unknown
abinis             4000000000DB5630  Unknown               Unknown  
Unknown
abinis             4000000000047E10  Unknown               Unknown  
Unknown

Stack trace terminated abnormally.
-------------------

So I think that your case may be included in
"known_problems*" in ~ABINIT/Infos directory.
Thank you for your contribution !

About the HGH PP : in principle, they should work
for solids as well (because "transferbility" should be expected),
but, practically, the PPs should be examined for well-known
simple cases (bulk, binary compounds, ... etc.) before starting
your own projects.  I am not so familiar with HGH PPs due to
the much higher energy cutoff than other PPs such as TM-type.

Incidentally, please let me wish a Merry Christmas
("Joyeux No¥"el", or "Happy Holidays"... ) and
a Happy New Year to all of you. ;-)

Best wishes,
Masayoshi

On 2005/12/21, at 20:57, Sun ShaoRui wrote:

> Dear Masayoshi Mikami:
>     I have use ver. 4.5.2 to calculate with 80hg.12.hgh, and there is 
> no
> problem. The problem occurs with ver.4.6.5 My system is redhat linux 
> 7.3, the
> cpu is pentium, and the complier is intel ifc.
>     The input file is shown as follows:
>   kptopt   1
> nshiftk 4
> shiftk  0.5 0.5 0.5
>          0.5 0.0 0.0
>          0.0 0.5 0.0
>          0.0 0.0 0.5
> ngkpt  4 4 4
> prtden  1
>   tolvrs   1.0d-18
>     iscf   5
> acell 3*11.07
> rprim  0.0  0.5  0.5
>        0.5  0.0  0.5
>        0.5  0.5  0.0
> ntypat 2
> znucl 80 16
> natom 2
> typat 1 2
> xred
>    0.0  0.0  0.0
>    0.25 0.25 0.25
> nband  30
>  nspinor  2
>  pspso    2 1
> ixc 2
>  ecut    40.0
> nstep 15
> diemac 1000
> -----------------------------------------------
> another question:
> In the paper(PRB, 58, 3641), the authors pointed it out that the 
> accuracy of
> the pseudopotential is illustrated by an extensive series of
> molecular calculations. Is it also right in crystal calculation?
>    Thanks in advance!
>                                    Shaorui Sun
> --
> Open WebMail Project (http://openwebmail.org)