date:20171011

Re: [Wien] x lapw2 -p asking for password to nodes

2017-10-11 Thread Peter Blaha


You got:
*calculating QTL's from parallel vectors*!!! 

If I understand the message correctly, it happens ONLY ?? when you 
calculate the qtls, not during scf.


So your command is either   x lapw2 -p -qtl  or you have QTL instead of 
TOT (FOR) in case.in2  ???


In "qtl" mode, lapw2 runs actually always in single (sequential) mode, 
the -p is used only to indicate that it should use the parallel vectors, 
not the sequential vector.
And before lapw2 actually states, it executes a vec2old_lapw command to 
collect all parallel vector files.


Maybe here is the problem, because vec2old uses
set remotecp = scp
and most likely on your cluster scp is not allowed.

Edit vec2old and put in the proper remote copy command for your cluster.

If this does not help, put a -xf in the first line of lapw2para (and 
vec2old), which gives you a long output, but from that you can follow 
what commands are actually executed and where the problem is.


Am 12.10.2017 um 03:36 schrieb Maciej Polak:

Dear WIEN2k community,

I am faced with a problem, where the "*x lapw2 -p*" procedure on my 
cluster asks me for passwords to all the nodes it uses:

*
*
*calculating QTL's from parallel vectors*
*mpo...@wn0125.ib.trojan.kdm.wcss.pl's password:*

no matter what I do after i get:
*
*
*Received disconnect from 10.27.75.188: 2: Too many authentication 
failures for mpolak*


And it repeats for all the nodes that are used.

This only happens when i invoke "*x lapw2 -p*" by itself, the lapw2 
within the flow of "*run_lapw*" correctly uses the passwordless command 
for communicating between nodes that is specified as a part of the 
./siteconfig_lapw for compilaton.
I am not allowed to log in directly into nodes, so no password works, 
and even if it did, I want the job to run without my input, like all the 
other do, and use the ssh method provided with the compilation.


Is there a fix to this? If i'm not mistaken, this issue started with 
WIEN2k 16.1 and persists through version 17.1. All other parts i use 
(lapw0,1 and lapwso) work as expected with no problems.


I would really appreciate help in this matter.

Best regards

Maciej Polak




___
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



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


___
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] Reg: Parity analysis at TRIM points

2017-10-11 Thread sree parvathy

Dear all,

I have a basic question regarding parity analysis at particular TRIM point
with spin orbit coupling. At one of the TRIM point (0 0 0), i am getting
4-fold degeneracy , and in case.outputirso  we can see that few bands are
skipped because of degeneracy.  My doubt is regarding the total parity at
that TRIM point. Can i proceed with the listed bands in case.outputirso (
for each set of degenerate bands one band is considered in case.outputirso
) ? or do we need to consider each band ?

Thank you
___
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] x lapw2 -p asking for password to nodes

2017-10-11 Thread Maciej Polak

Sorry, the first sentence should read lapwso: why does "x lapw0 -p", "x lapw1 
-p" and "x lapwso -p" work every time?

W dniu 12/10/17 04:25 Maciej Polak  napisał:
> 
> Thank you for your answer, but do you know then why does "x lapw0 -p", "x 
> lapw1 -p" and "x lapw2 -p" work every time? run_lapw, also works very well. I 
> have set the "$REMOTE" variable to "pbs_remsh", which is what my cluster 
> uses, and everything works perfectly, except for "x lapw2 -p", which used to 
> run no problems on version 14.2.
> 
> Best regards
> 
> Maciej Polak
> 
> W dniu 11/10/17 21:12 Laurence Marks  napisał:
> > 
> > 
> > This is local to your cluster. You almost need to talk to your sysadmins. 
> > There are many possible solutions, but without knowing how your OS/ssh/jobs 
> > are setup nobody will be able to do more than guess.
> > 
> > 
> > 
> > On Oct 11, 2017 8:36 PM, "Maciej Polak"  > > wrote:
> > 
> > > 
> > > Dear WIEN2k community,
> > > 
> > > I am faced with a problem, where the "x lapw2 -p" procedure on my cluster 
> > > asks me for passwords to all the nodes it uses:
> > > 
> > > 
> > > 
> > > 
> > > calculating QTLs from parallel vectors
> > > 10.27.75.188(javascript:main.compose('new', 
> > > 't=mpo...@wn0125.ib.trojan.kdm.wcss.pl')" iwc-bad-attr="" 
> > > >mpo...@wn0125.ib.trojan.kdm.wcss.pls password:
> > > 
> > > 
> > > no matter what I do after i get:
> > > 
> > > 
> > > 
> > > Received disconnect from 
> > > 
> > > 
> > > And it repeats for all the nodes that are used.
> > > 
> > > 
> > > This only happens when i invoke "x lapw2 -p" by itself, the lapw2 within 
> > > the flow of "run_lapw" correctly uses the passwordless command for 
> > > communicating between nodes that is specified as a part of the 
> > > ./siteconfig_lapw for compilaton.
> > > 
> > > I am not allowed to log in directly into nodes, so no password works, and 
> > > even if it did, I want the job to run without my input, like all the 
> > > other do, and use the ssh method provided with the compilation.
> > > 
> > > Is there a fix to this? If im not mistaken, this issue started with 
> > > WIEN2k 16.1 and persists through version 17.1. All other parts i use 
> > > (lapw0,1 and lapwso) work as expected with no problems.
> > > 
> > > I would really appreciate help in this matter.
> > > 
> > > Best regards
> > > 
> > > Maciej Polak
> > > 
> > > 
> > > 
> > >
___
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] x lapw2 -p asking for password to nodes

2017-10-11 Thread Maciej Polak

Thank you for your answer, but do you know then why does "x lapw0 -p", "x lapw1 
-p" and "x lapw2 -p" work every time? run_lapw, also works very well. I have 
set the "$REMOTE" variable to "pbs_remsh", which is what my cluster uses, and 
everything works perfectly, except for "x lapw2 -p", which used to run no 
problems on version 14.2.

Best regards

Maciej Polak

W dniu 11/10/17 21:12 Laurence Marks  napisał:
> 
> 
> This is local to your cluster. You almost need to talk to your sysadmins. 
> There are many possible solutions, but without knowing how your OS/ssh/jobs 
> are setup nobody will be able to do more than guess.
> 
> 
> 
> On Oct 11, 2017 8:36 PM, "Maciej Polak"  > wrote:
> 
> > 
> > Dear WIEN2k community,
> > 
> > I am faced with a problem, where the "x lapw2 -p" procedure on my cluster 
> > asks me for passwords to all the nodes it uses:
> > 
> > 
> > 
> > 
> > calculating QTLs from parallel vectors
> > 10.27.75.188(javascript:main.compose('new', 
> > 't=mpo...@wn0125.ib.trojan.kdm.wcss.pl')" iwc-bad-attr="" 
> > >mpo...@wn0125.ib.trojan.kdm.wcss.pls password:
> > 
> > 
> > no matter what I do after i get:
> > 
> > 
> > 
> > Received disconnect from 
> > 
> > 
> > And it repeats for all the nodes that are used.
> > 
> > 
> > This only happens when i invoke "x lapw2 -p" by itself, the lapw2 within 
> > the flow of "run_lapw" correctly uses the passwordless command for 
> > communicating between nodes that is specified as a part of the 
> > ./siteconfig_lapw for compilaton.
> > 
> > I am not allowed to log in directly into nodes, so no password works, and 
> > even if it did, I want the job to run without my input, like all the other 
> > do, and use the ssh method provided with the compilation.
> > 
> > Is there a fix to this? If im not mistaken, this issue started with 
> > WIEN2k 16.1 and persists through version 17.1. All other parts i use 
> > (lapw0,1 and lapwso) work as expected with no problems.
> > 
> > I would really appreciate help in this matter.
> > 
> > Best regards
> > 
> > Maciej Polak
> > 
> > 
> > 
> >
___
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] x lapw2 -p asking for password to nodes

2017-10-11 Thread Laurence Marks

This is local to your cluster. You almost need to talk to your sysadmins.
There are many possible solutions, but without knowing how your OS/ssh/jobs
are setup nobody will be able to do more than guess.

On Oct 11, 2017 8:36 PM, "Maciej Polak"  wrote:

> Dear WIEN2k community,
>
> I am faced with a problem, where the "*x lapw2 -p*" procedure on my
> cluster asks me for passwords to all the nodes it uses:
>
> *calculating QTL's from parallel vectors*
> *mpo...@wn0125.ib.trojan.kdm.wcss.pl
> 's password:*
>
> no matter what I do after i get:
>
> *Received disconnect from 10.27.75.188 : 2: Too many
> authentication failures for mpolak*
>
> And it repeats for all the nodes that are used.
>
> This only happens when i invoke "*x lapw2 -p*" by itself, the lapw2
> within the flow of "*run_lapw*" correctly uses the passwordless command
> for communicating between nodes that is specified as a part of the
> ./siteconfig_lapw for compilaton.
> I am not allowed to log in directly into nodes, so no password works, and
> even if it did, I want the job to run without my input, like all the other
> do, and use the ssh method provided with the compilation.
>
> Is there a fix to this? If i'm not mistaken, this issue started with
> WIEN2k 16.1 and persists through version 17.1. All other parts i use
> (lapw0,1 and lapwso) work as expected with no problems.
>
> I would really appreciate help in this matter.
>
> Best regards
>
> Maciej Polak
>
>
>
___
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] x lapw2 -p asking for password to nodes

2017-10-11 Thread Maciej Polak

Dear WIEN2k community,

I am faced with a problem, where the "x lapw2 -p" procedure on my cluster asks 
me for passwords to all the nodes it uses:



calculating QTL's from parallel vectors
mpo...@wn0125.ib.trojan.kdm.wcss.pl's password:


no matter what I do after i get:



Received disconnect from 10.27.75.188: 2: Too many authentication failures for 
mpolak


And it repeats for all the nodes that are used.


This only happens when i invoke "x lapw2 -p" by itself, the lapw2 within the 
flow of "run_lapw" correctly uses the passwordless command for communicating 
between nodes that is specified as a part of the ./siteconfig_lapw for 
compilaton.

I am not allowed to log in directly into nodes, so no password works, and even 
if it did, I want the job to run without my input, like all the other do, and 
use the ssh method provided with the compilation.

Is there a fix to this? If i'm not mistaken, this issue started with WIEN2k 
16.1 and persists through version 17.1. All other parts i use (lapw0,1 and 
lapwso) work as expected with no problems.

I would really appreciate help in this matter.

Best regards

Maciej Polak
___
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] Bug with lapwso_mpi and ifort 18

2017-10-11 Thread MCDERMOTT Eamon 250772

Neither of these suggestions help (I had tried error trapping as Prof. Marks 
had suggested already). More debugging just gets me more and more confused. 
I've inserted a few print statements, and now in a properly working binary 
built with ifort 15, I get something like (when running with lapwso_mpi 
lapwso_1.def):

call to get_nloat(   3 1921000 )
 i=   1 ii=   1 nloat=   0 mist=  -106685467
 ios=  67 -> exit
 i=   2 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
 i=   3 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
 i=   4 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
 i=   5 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
 i=   6 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
 i=   7 ii=   4 nloat=   4 mist=  -106685467
 ios=  67 -> exit
...

While with the broken version it's always terminating after the first set of 
reads:

call to get_nloat(   3 1921000 )
 i=   1 ii=   1 nloat=   0 mist=  -106685467
 ios=  -1 -> exit
forrtl: severe (24): end-of-file during read, unit 9, file 
/path/to/case/./case.vector_1
Image  PCRoutineLineSource
lapwso_mpi 00490758  Unknown   Unknown  Unknown
lapwso_mpi 004B4BF5  Unknown   Unknown  Unknown
lapwso_mpi 0048AAA2  get_nloat_ 16  get_nloat.f
lapwso_mpi 0044A127  MAIN__144  lapwso.F
lapwso_mpi 00406B9E  Unknown   Unknown  Unknown
libc-2.12.so   003352C1ED5D  __libc_start_main Unknown  Unknown
lapwso_mpi 00406AA9  Unknown   Unknown  Unknown

Iostat = -1 indicates EOF, whereas 67 is "Input statement requires too much 
data". So somehow the second read in get_nloat.f:

read(9,iostat=ios) elo(0:lomax,1:ii) 

is just running off the end of a 659MB vector file with ifort 18. Maybe they've 
changed the concept of how records are delimited, but this vector file is 
written with an ifort 18 compiled lapw1! This is very surprising for me, since 
ifort 18 is otherwise working very well for me with respect to optimization. 
Lapw1 works fine with -O3 -mavx, for example.

I get the same error with an ifort 18 non-mpi lapwso:

TiC x lapwso
forrtl: severe (24): end-of-file during read, unit 9, file 
/path/to/TiC/./TiC.vector
Image  PCRoutineLineSource
lapwso 00457328  Unknown   Unknown  Unknown
lapwso 0047BCB5  Unknown   Unknown  Unknown
lapwso 00450926  get_nloat_ 16  get_nloat.f
lapwso 0042779C  MAIN__144  lapwso.F
lapwso 0040595E  Unknown   Unknown  Unknown
libc-2.12.so   003352C1ED5D  __libc_start_main Unknown  Unknown
lapwso 00405869  Unknown   Unknown  Unknown

So it's something special about the way the vector is being read in 
get_nloat.f...

--
Eamon

-Original Message-
From: Wien [mailto:wien-boun...@zeus.theochem.tuwien.ac.at] On Behalf Of 
Laurence Marks
Sent: Wednesday, October 11, 2017 17:12
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Bug with lapwso_mpi and ifort 18

Also, maybe try

read(9,err=999)mist
999  continue

On Wed, Oct 11, 2017 at 9:59 AM, Peter Blaha  
wrote:
> Looks very strange.
>
> It happens only in mpi mode ?
>
> Just one try:
>
> replace
>
> read(9)
> read(9) mist
>
> In fact, all what that statement should do is skipping one line 
> (record) in this unformatted vector file (which contains the same 
> numbers (E-parameters for LAPW) as the first line in the energy files).
>
> You may also print*, i,mist
>
> to see if it happens already for the first atom.
>
> PS: Naively, I would have expected that it has to do with this -assume  
> bufferedio which is (sometimes) broken in ifort17. And clearly, this 
> file has been read before, then rewinded and then is read again.
>
> On 10/11/2017 04:38 PM, MCDERMOTT Eamon 250772 wrote:
>> Dear all,
>>
>>
>>
>> I have noticed a bug with the combination of lapwso_mpi (WIEN2k 17.1) 
>> and ifort 18.0.0 (20170811).
>>
>>
>>
>> On a well-formed case that works properly when lapwso_mpi is compiled 
>> with ifort  15.0.6, I get crashes on each process shortly after 
>> startup like the following:
>>
>>
>>
>> forrtl: severe (24): end-of-file during read, unit 9, file
>> /path/case/./case.vector_1
>>
>> Image  PCRoutineLineSource
>>
>> lapwso_mpi

Re: [Wien] Bug with lapwso_mpi and ifort 18

2017-10-11 Thread Laurence Marks

Also, maybe try

read(9,err=999)mist
999  continue

On Wed, Oct 11, 2017 at 9:59 AM, Peter Blaha
 wrote:
> Looks very strange.
>
> It happens only in mpi mode ?
>
> Just one try:
>
> replace
>
> read(9)
> read(9) mist
>
> In fact, all what that statement should do is skipping one line (record)
> in this unformatted vector file (which contains the same numbers
> (E-parameters for LAPW) as the first line in the energy files).
>
> You may also print*, i,mist
>
> to see if it happens already for the first atom.
>
> PS: Naively, I would have expected that it has to do with this
> -assume  bufferedio
> which is (sometimes) broken in ifort17. And clearly, this file has been
> read before, then rewinded and then is read again.
>
> On 10/11/2017 04:38 PM, MCDERMOTT Eamon 250772 wrote:
>> Dear all,
>>
>>
>>
>> I have noticed a bug with the combination of lapwso_mpi (WIEN2k 17.1)
>> and ifort 18.0.0 (20170811).
>>
>>
>>
>> On a well-formed case that works properly when lapwso_mpi is compiled
>> with ifort  15.0.6, I get crashes on each process shortly after startup
>> like the following:
>>
>>
>>
>> forrtl: severe (24): end-of-file during read, unit 9, file
>> /path/case/./case.vector_1
>>
>> Image  PCRoutineLineSource
>>
>> lapwso_mpi 004916D8  Unknown   Unknown  Unknown
>>
>> lapwso_mpi 004B6065  Unknown   Unknown  Unknown
>>
>> lapwso_mpi 0048ABB6  get_nloat_ 16
>> get_nloat.f
>>
>> lapwso_mpi 0044A361  MAIN__144  lapwso.F
>>
>> lapwso_mpi 00406C5E  Unknown   Unknown  Unknown
>>
>> libc-2.12.so   003FA401ED5D  __libc_start_main Unknown  Unknown
>>
>> lapwso_mpi 00406B69  Unknown   Unknown  Unknown
>>
>>
>>
>> in get_nloat.f this line is simply “read(9)”, so I’m guessing there has
>> been some change in raw file access in this ifort version.
>>
>>
>>
>> This crash does not seem to be dependent on optimizations, as I can
>> reproduce it with
>>
>> FPOPT=-O0 -g -FR -traceback -I$(MKLROOT)/include
>>
>>
>>
>> Adding –assume bufferedio (or –assume nobufferedio) does not make a
>> difference.
>>
>>
>>
>> Trapping the IO error on this line and exiting simply causes a later
>> segfault, so there is something more complicated happening here than
>> just reading off the end of the file at the end of the routine:
>>
>>
>>
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>
>> Image  PCRoutineLineSource
>>
>> lapwso_mpi 0047358D  Unknown   Unknown  Unknown
>>
>> libpthread-2.12.s  003BE880F7E0  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF045B23D  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF045B040  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF045AF6E  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF045C039  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF045D7CB  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF0454F6E  Unknown   Unknown  Unknown
>>
>> libiomp5.so2AAEF0455B6C  Unknown   Unknown  Unknown
>>
>> lapwso_mpi 0049F07B  Unknown   Unknown  Unknown
>>
>> lapwso_mpi 0040C4CC  rotmat_mp_init_ro 229
>> modules.F
>>
>> lapwso_mpi 0043027E  MAIN__146  lapwso.F
>>
>> lapwso_mpi 00406D5E  Unknown   Unknown  Unknown
>>
>> libc-2.12.so   003BE7C1ED5D  __libc_start_main Unknown  Unknown
>>
>> lapwso_mpi 00406C69  Unknown   Unknown  Unknown
>>
>>
>>
>>
>>
>>
>>
>> Any ideas? I may be forced to upgrade soon (some Intel cluster license
>> SNAFU)…
>>
>>
>>
>>
>>
>> --
>>
>> Eamon McDermott
>>
>> CEA Grenoble
>>
>> DRT/LETI/DTSI/SCMC
>>
>>
>>
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIF-g=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=EDg4I6trPWK2mIBefpClkOk5bKR-5w9NGNYvXcx69ao=8kfWzu6CNQoi1dRXdiAMIqzLhKkUNdkGS4Zz4irSzJI=
>> SEARCH the MAILING-LIST at:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwIF-g=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=EDg4I6trPWK2mIBefpClkOk5bKR-5w9NGNYvXcx69ao=68wHJWSDHYVvqyiqT35vq86sV15y2J5YGqFiu2iMHPw=
>>
>
> --
>
>P.Blaha
> --
> Peter BLAHA, Inst.f.

Re: [Wien] Bug with lapwso_mpi and ifort 18

2017-10-11 Thread Peter Blaha


Looks very strange.

It happens only in mpi mode ?

Just one try:

replace

read(9)
read(9) mist

In fact, all what that statement should do is skipping one line (record) 
in this unformatted vector file (which contains the same numbers 
(E-parameters for LAPW) as the first line in the energy files).


You may also print*, i,mist

to see if it happens already for the first atom.

PS: Naively, I would have expected that it has to do with this
-assume  bufferedio
which is (sometimes) broken in ifort17. And clearly, this file has been 
read before, then rewinded and then is read again.


On 10/11/2017 04:38 PM, MCDERMOTT Eamon 250772 wrote:

Dear all,



I have noticed a bug with the combination of lapwso_mpi (WIEN2k 17.1)
and ifort 18.0.0 (20170811).



On a well-formed case that works properly when lapwso_mpi is compiled
with ifort  15.0.6, I get crashes on each process shortly after startup
like the following:



forrtl: severe (24): end-of-file during read, unit 9, file
/path/case/./case.vector_1

Image  PCRoutineLineSource

lapwso_mpi 004916D8  Unknown   Unknown  Unknown

lapwso_mpi 004B6065  Unknown   Unknown  Unknown

lapwso_mpi 0048ABB6  get_nloat_ 16
get_nloat.f

lapwso_mpi 0044A361  MAIN__144  lapwso.F

lapwso_mpi 00406C5E  Unknown   Unknown  Unknown

libc-2.12.so   003FA401ED5D  __libc_start_main Unknown  Unknown

lapwso_mpi 00406B69  Unknown   Unknown  Unknown



in get_nloat.f this line is simply “read(9)”, so I’m guessing there has
been some change in raw file access in this ifort version.



This crash does not seem to be dependent on optimizations, as I can
reproduce it with

FPOPT=-O0 -g -FR -traceback -I$(MKLROOT)/include



Adding –assume bufferedio (or –assume nobufferedio) does not make a
difference.



Trapping the IO error on this line and exiting simply causes a later
segfault, so there is something more complicated happening here than
just reading off the end of the file at the end of the routine:



forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image  PCRoutineLineSource

lapwso_mpi 0047358D  Unknown   Unknown  Unknown

libpthread-2.12.s  003BE880F7E0  Unknown   Unknown  Unknown

libiomp5.so2AAEF045B23D  Unknown   Unknown  Unknown

libiomp5.so2AAEF045B040  Unknown   Unknown  Unknown

libiomp5.so2AAEF045AF6E  Unknown   Unknown  Unknown

libiomp5.so2AAEF045C039  Unknown   Unknown  Unknown

libiomp5.so2AAEF045D7CB  Unknown   Unknown  Unknown

libiomp5.so2AAEF0454F6E  Unknown   Unknown  Unknown

libiomp5.so2AAEF0455B6C  Unknown   Unknown  Unknown

lapwso_mpi 0049F07B  Unknown   Unknown  Unknown

lapwso_mpi 0040C4CC  rotmat_mp_init_ro 229
modules.F

lapwso_mpi 0043027E  MAIN__146  lapwso.F

lapwso_mpi 00406D5E  Unknown   Unknown  Unknown

libc-2.12.so   003BE7C1ED5D  __libc_start_main Unknown  Unknown

lapwso_mpi 00406C69  Unknown   Unknown  Unknown







Any ideas? I may be forced to upgrade soon (some Intel cluster license
SNAFU)…





--

Eamon McDermott

CEA Grenoble

DRT/LETI/DTSI/SCMC





___
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/TC_Blaha
--
___
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] Bug with lapwso_mpi and ifort 18

2017-10-11 Thread MCDERMOTT Eamon 250772

Dear all,

 

I have noticed a bug with the combination of lapwso_mpi (WIEN2k 17.1) and
ifort 18.0.0 (20170811).

 

On a well-formed case that works properly when lapwso_mpi is compiled with
ifort  15.0.6, I get crashes on each process shortly after startup like the
following:

 

forrtl: severe (24): end-of-file during read, unit 9, file
/path/case/./case.vector_1

Image  PCRoutineLineSource

lapwso_mpi 004916D8  Unknown   Unknown  Unknown

lapwso_mpi 004B6065  Unknown   Unknown  Unknown

lapwso_mpi 0048ABB6  get_nloat_ 16
get_nloat.f

lapwso_mpi 0044A361  MAIN__144  lapwso.F

lapwso_mpi 00406C5E  Unknown   Unknown  Unknown

libc-2.12.so   003FA401ED5D  __libc_start_main Unknown  Unknown

lapwso_mpi 00406B69  Unknown   Unknown  Unknown

 

in get_nloat.f this line is simply "read(9)", so I'm guessing there has been
some change in raw file access in this ifort version. 

 

This crash does not seem to be dependent on optimizations, as I can
reproduce it with 

FPOPT=-O0 -g -FR -traceback -I$(MKLROOT)/include

 

Adding -assume bufferedio (or -assume nobufferedio) does not make a
difference.

 

Trapping the IO error on this line and exiting simply causes a later
segfault, so there is something more complicated happening here than just
reading off the end of the file at the end of the routine:

 

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image  PCRoutineLineSource

lapwso_mpi 0047358D  Unknown   Unknown  Unknown

libpthread-2.12.s  003BE880F7E0  Unknown   Unknown  Unknown

libiomp5.so2AAEF045B23D  Unknown   Unknown  Unknown

libiomp5.so2AAEF045B040  Unknown   Unknown  Unknown

libiomp5.so2AAEF045AF6E  Unknown   Unknown  Unknown

libiomp5.so2AAEF045C039  Unknown   Unknown  Unknown

libiomp5.so2AAEF045D7CB  Unknown   Unknown  Unknown

libiomp5.so2AAEF0454F6E  Unknown   Unknown  Unknown

libiomp5.so2AAEF0455B6C  Unknown   Unknown  Unknown

lapwso_mpi 0049F07B  Unknown   Unknown  Unknown

lapwso_mpi 0040C4CC  rotmat_mp_init_ro 229
modules.F

lapwso_mpi 0043027E  MAIN__146  lapwso.F

lapwso_mpi 00406D5E  Unknown   Unknown  Unknown

libc-2.12.so   003BE7C1ED5D  __libc_start_main Unknown  Unknown

lapwso_mpi 00406C69  Unknown   Unknown  Unknown

 

 

 

Any ideas? I may be forced to upgrade soon (some Intel cluster license
SNAFU).

 

 

--

Eamon McDermott

CEA Grenoble

DRT/LETI/DTSI/SCMC

 



smime.p7s
Description: S/MIME cryptographic 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] Optical properties with SO coupling

2017-10-11 Thread Peter Blaha


Dear Gerhard,

You are right.

I'll modify optic.pl such that it gives a hint what to do for a 
spin-polarized SO calculation (namely run  x kram -up from "single 
program"). I'm not going to offer a more convenient solution with a 
single "click", as I consider this already an option for "experts".


Regards

On 10/06/2017 09:58 AM, Fecher, Gerhard wrote:

maybe I was still not clear enough:
x kram -up might work on the commandline
but it does NOT work in w2web when using TASKS OPTIC !


Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Jaroslav 
Hamrle [ham...@karlov.mff.cuni.cz]
Gesendet: Freitag, 6. Oktober 2017 09:41
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] Optical properties with SO coupling

Dear Gerhard, dear Gavin,

as written in last email of Gavin, I think:

In case of spin-polarized case without so, the optical transitions for
up, down spins are written in case.jointup, case.jointdn, each one
containing only optical transitions for corresponding up/down electrons.
Program kram then sums up contributions from optical transitions from
both electrons spins.

In case of spin-polarized case with so, up and down spins are not
described separately and written only to file 'up', like case.jointup.
That is why in case with so coupling, all optical transitions should be
contained with file case.jointup.

That is why I think the current version of program joint should be
corrected in the way that case.jointup should contain all optical
transitions. However, now, output in case.jointup is somewhat
artificially divided by too. Of course, it can be corrected in code
kram, but I think it is not good idea. It should be corrected in the
joint program.

Then, x kram -up is just fine.

With my regards

Jaroslav



On 05/10/17 15:14, Fecher, Gerhard wrote:

Hi Jaroslav,
if you check only case.jointup it has possibly only half the value because the 
other half is supposed to be in case.jointdn
(with SO they should be the same)

Did you try to copy case.jointup to case.jointdn (or run in addition everything 
for dn)
and then addjoint
then the factor 2 is included in the case.joint

The problem with spinpolarisation and SO is that case.jointup is the only 
necessary and produced, however, kram expects that case.joint exists
that's why one has to do the copy by hand (not rename, then the factor 2 will 
be missing, again !)
(one might also run optic and joint both in addition for dn, before addjoint)

Indeed, it would be nice if this behaviopur could be changed (maybe by some 
switch(es) to kram : e.g.: -so -up)




Just for curiosity, I wonder whether and how crossterms are respected, the 
selcction rules on the total angular momentum j' = j, j+-1 together with those 
on the magnetic quantum number mj
allow spin flip transitions even though the dipole operator does not act on the 
spin !

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz
and
Max Planck Institute for Chemical Physics of Solids
01187 Dresden

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Jaroslav 
Hamrle [ham...@karlov.mff.cuni.cz]
Gesendet: Donnerstag, 5. Oktober 2017 09:57
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] Optical properties with SO coupling

Dear Gavin,

I will describe my observation:
I have calculated optical (epzz) and magneto-optical (K, for example K=epxy for 
M001) spectra of permittivity elements for bcc Fe.
The electronic structure calculations are spin polarized, with spin-orbit, run 
by commands:

runsp_lapw -p
runsp_lapw -p -so -cc 0.01 -ec 0.001 -s lapw1
x lapw2 -p -fermi -up -so
x optic -p -up -so
x joint -p -up

For w2k version 16.1, the calculated spectra corresponds to the experimental 
spectra (for both epzz and K).
For w2k version 17.1, the calculated spectra are half-value for both epzz and 
K, compared to the experiment.

Figures comparing spectra are here:

http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_Imepzz_compare.pdf
http://alma.karlov.mff.cuni.cz/hamrle/w2kfig/Fe_ReK_compare.pdf

In this example, I used permittivity spectra read directly from case.jointup 
files (I do not use output of kram).
In the figures:
   - solid (noisy) line is output from case.jointup
   - the symbols are

Re: [Wien] Optical properties with SO coupling

2017-10-11 Thread Peter Blaha


Dear wien2k users,

Unfortunately, I forgot my own advise, namely that in spin-polarized 
calculations + SO we need to run only spin-up to get everything.


Therefore in WIEN2k_17 spin-polarized spin-orbit calculations would need 
to be run for both spins (x optic -up/-dn; x joint -up/-dn) and then 
addjoint-updn would be needed.


This is of course not really necessary and against what is written in 
the UG.


The attached joint.f should correct for that and the following sequences 
should be ok again (assuming identical k-mesh as in scf):


run_lapw# non-spinpolarized case
x optic
x joint
x kram

runsp_lapw  # spin-polarized case
x optic -up
x optic -dn
x joint -up
x joint -dn
addjoint-updn
x kram   (no -up !)

run -so# non-spinpolarized + SO (with inversion symmetry)
x optic -so
x joint
x kram

without inversion, please follow the UG or set up from the beginning a 
spin-polarized case (with zero magnetization):

runsp_c -so
x optic -up -so
x joint -up
x kram -up

runsp -so # spin-polarized + SO
x optic -up -so
x joint -up
x kram -up(no addjoint-updn)



On 10/07/2017 08:48 AM, Gavin Abo wrote:

First, WIEN2k 14.1 is expected to essentially give incorrect results for
optical property calculations (because the normalization was not
correct).  Thus, the bug reports:

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15724.html

Thus, to use the corrected code, you would have to use WIEN2k 17.1.
However, there seems to still be a slight bug in WIEN2k 17.1 with just a
spin-polarized SO optic calculation as was recently discussed (where the
results are off by a factor of 2):

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16524.html

Second, see section "5.10.12 addjoint-updn_lapw" of the WIEN2k 17.1
usersguide on page 102.  It states there that this is only used with a
spin-polarized calculation (runsp_lapw) when it says:

"It should be called for spin-polarized optics calculations ..."

So, you don't use it with a non-spin polarized calculation (run_lapw).

The addjoint-updn_lapw is also not used with SO calculations [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07551.html
]:

run_lapw -so
runsp_lapw -so

I suggest that you read the post about how Imag(epsilon) can be plotted
separately, but not the Real(epsilon):

https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12116.html

On 10/6/2017 11:34 PM, lokanath patra wrote:

So what I understood is:
If I want to calculate the total optical properties of the compound, I
have to run addjoint_updn -lapw then I should proceed with x kram.
If I want to calculate the spin resolved optical properties, then I
have to run x joint -up/dn and then x kram -up/dn. No need to run
addjoint_updn -lapw.
(I am using Wien2k version 14.1)

Correct me if I am wrong.

Regards,
Lokanath.

___
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/TC_Blaha
--
!cad
!cad J O I N T  D E N S I T Y  O F  S T A T E S
!cad
!cadACTUAL VERSION  with BLOECHL SCHEME
!cad
!cad written by Robert Abt startind from TETRA
!cad modifications by cad, November 1998  
!cad modifications by Jan Kunes, May 1999
!cad modifications by cad, May-August 1999 
!cad modifications by cad, August 2002 
!cad
!cad
!cadFILE  3   case.outmat   MOMENTUM MATRIX ELEMENTS
!cadFILE  4   case.weight   ENERGY BANDS, WHEIGHTS
!cadFILE  5   case.injoint  INPUT
!cadFILE  6   case.outputjoint  OUTPUT
!cadFILE  7   case.jointDOS, JDOS IM(EPSILON) 
!cadFILE  8   case.sigma_intra  intraband contributions
!cadFILE 14   case.kgen TETRAHEDRA
!cadFILE 20   case.struct   STRUCTURAL DATA
!cad
!cadfor band analysis further files are usd
!cad
  PROGRAM JOINT
  use felder
  IMPLICIT REAL*8 (A-H,O-Z)
!  INCLUDE 'param.inc'
  PARAMETER (NPF=10)
  PARAMETER (RYDeV=13.605698)
  PARAMETER (E=1.602E-19)
  PARAMETER (H=6.625E-34)
  PARAMETER (C=2.99793E8)
!ad
  CHARACTER*2  aif,HINTRA(MG0),aso
  CHARACTER*4  ECV
  CHARACTER*6  ECV1
  CHARACTER*6

Re: [Wien] problem with MPI parallization of LAWP1: FERMI - Error

2017-10-11 Thread Gavin Abo


Your .machines file seems okay.


The error indicates that LAPW1 failed.  Other than that, the error 
message doesn't look much more helpful.



I'm guessing that is from the standard output/error file for the job.


What about the case.dayfile, *.error files, or hidden dot files [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15549.html 
], any additional error messages in them that would help indicate 
further why it failed?



You can search the mailing list archive [ 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/maillist.html 
] for the "orte_base_help_aggregate" or other keywords.



For example, perhaps lapw1_mpi was compiled with the wrong blacs library:


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07254.html


On 10/11/2017 2:27 AM, saqib wrote:


Dear WIEN2K users,


I am currently trying to run a calculation for large organic molecule 
on WIEN 14.2. Due to nature of my system, K-point parallization is 
useless so I have to use MPI parallization.


I am using following .machines file to run on node 'fermi' with 4 cores:


lapw0:fermi:4
1:fermi:4
granularity:1
extrafine:1

While lapw0 runs without any problem, LAPW1/LAPW2 crashes with 
following message:

.
.
[fermi:119828] 3 more processes have sent help message 
help-mpi-api.txt / mpi-abort
[fermi:119828] Set MCA parameter "orte_base_help_aggregate" to 0 to 
see all help / error messages

mptest.scf1_1: No such file or directory.
grep: *scf1*: No such file or directory
FERMI - Error
cp: cannot stat `.in.tmp': No such file or directory

The same calculation runs without any problem for a single core. I 
will really appreciate if someone can help me resolve this issue.


with best regards
Saqib Javaid
UNIST, Korea.
___
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] x lapw2 -p asking for password to nodes

[Wien] Reg: Parity analysis at TRIM points

Re: [Wien] x lapw2 -p asking for password to nodes

Re: [Wien] x lapw2 -p asking for password to nodes

Re: [Wien] x lapw2 -p asking for password to nodes

[Wien] x lapw2 -p asking for password to nodes

Re: [Wien] Bug with lapwso_mpi and ifort 18

Re: [Wien] Bug with lapwso_mpi and ifort 18

Re: [Wien] Bug with lapwso_mpi and ifort 18

[Wien] Bug with lapwso_mpi and ifort 18

Re: [Wien] Optical properties with SO coupling

Re: [Wien] Optical properties with SO coupling

Re: [Wien] problem with MPI parallization of LAWP1: FERMI - Error

13 matches

Site Navigation

Mail list logo

Footer information