Re: [Wien] Jeff=1/2 and 3/2 states using case.cf files

2019-02-06 Thread William Lafargue-Dit-Hauret 

Thanks for the explanations.

However, according to my tests and the UG 8.19.2, it seems such format 
is deprecated since the qtl version of Wien2k07.


Indeed, the qtlmain.f file does not accept the stars. In such a way, it 
seems the summation is done over all states.


W.

Le 6/02/19 à 15:41, Peter Blaha a écrit :
I'm not the full expert in relativistic qtl, but to my understanding 
the * indicates the end of a summation.


Consider the p-states, splitted into 1/2 and 3/2: The cf file looks 
like: (SRC_templates)

 -.81649658 0.  0. 0.  0. 0.  0. 0.  .57735027 0.  0. 0.
*0. 0.  -.57735027 0.  0. 0.  0. 0.  0. 0.  .81649658 0.
 0. 0.  0. 0.  0. 0.  1. 0.  0. 0.  0. 0.
 .57735027 0.  0. 0.  0. 0.  0. 0.  .81649658 0.  0. 0.
 0. 0.  .81649658 0.  0. 0.  0. 0.  0. 0.  .57735027 0.
*0. 0.  0. 0.  1. 0.  0. 0.  0. 0.  0. 0.

There are 6 lines, and obviously, p-1/2 is obtained by summation over 
the first 2 lines, p-3/2 over the following 4 lines.


Another example is the case.cf_f_mm2   example, where the f-states are 
splitted/summed according to mm2 Symmetry and the * indicate the 
summations.


If you don't want any summation, just start each line with a *.


On 1/30/19 1:59 AM, William Lafargue-dit-Hauret wrote:

Dear Wien2k users,

I am studying the Jeff = 1/2 and 3/2 states of an iridate compound. 
More specifically, I would like to evidence them into bandstructure 
and/or DOS.


I found in the mailing-list the following messages, posted 5 years ago :

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



which mentionned that it is possible to specify (explicitly) the 
splitting into case.cfXX files (XX being the atom with qsplit = 6 
into the case.inq file).


I need your help to know whether I have written it in a proper way.

For example, let's consider the state |1/2,1/2> = [ 2i/sqrt(6) Y_2^-1 
] + [ i/sqrt(6) (Y_2^-2 - Y_2^2) ]. The first and second terms are 
associated to spin down and up, respectively.


In such a case, I would describe this state as :

=>  0. 1/sqrt(6)  0. 0.  0. 0. 0. 0. 0. -1/sqrt(6)     0. 0. 0. 
2/sqrt(6) 0. 0.  0. 0.  0. 0.



Moreover, some * marks are present into the example files. The 
comment file, located in the SRC_qtl directory, mentions that they 
"have meaning when SUMA is in line 1 case.inq". But such line seems 
to be deprecated, isn't it ?


Thank you for your help.

Cheers,

William

___
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] Jeff=1/2 and 3/2 states using case.cf files

2019-01-29 Thread William Lafargue-dit-Hauret 

Dear Wien2k users,

I am studying the Jeff = 1/2 and 3/2 states of an iridate compound. More 
specifically, I would like to evidence them into bandstructure and/or DOS.


I found in the mailing-list the following messages, posted 5 years ago :

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

which mentionned that it is possible to specify (explicitly) the 
splitting into case.cfXX files (XX being the atom with qsplit = 6 into 
the case.inq file).


I need your help to know whether I have written it in a proper way.

For example, let's consider the state |1/2,1/2> = [ 2i/sqrt(6) Y_2^-1 ] 
+ [ i/sqrt(6) (Y_2^-2 - Y_2^2) ]. The first and second terms are 
associated to spin down and up, respectively.


In such a case, I would describe this state as :

=>  0. 1/sqrt(6)  0. 0.  0. 0. 0. 0. 0. -1/sqrt(6)     0. 0. 0. 
2/sqrt(6) 0. 0.  0. 0.  0. 0.



Moreover, some * marks are present into the example files. The comment 
file, located in the SRC_qtl directory, mentions that they "have meaning 
when SUMA is in line 1 case.inq". But such line seems to be deprecated, 
isn't it ?


Thank you for your help.

Cheers,

William

___
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] Error in Hub-U calculation

2018-08-07 Thread William Lafargue Dit Hauret 
Did you already try to run an L(S)DA+U calculation without restarting from a 
previous L(S)DA one ? 
Also, I am not sure the -dm option is necessary in this case. 
W. 



De: "shaymlal dayananda"  
À: "A. Mailing List for WIEN2k Users"  
Envoyé: Mardi 7 Août 2018 14:49:33 
Objet: [Wien] Error in Hub-U calculation 



On Tuesday, August 7, 2018 12:41 PM, shaymlal dayananda 
 wrote: 


Dear Developers and users 

I am in a trouble that I could not recover my problem yet. 

I tried all of your suggestions. I am summarizing them below. 

1. I finished runsp_lapw -NI -p -ec 0.0001 correctly and saved the files. 
2. I added case.indmc and case.inorb files ( I have copied them one of previous 
emails) 
3. submitted the job runsp_lapw -NI -p -dm -orb -ec 0.0001 
4. This job stopped with the same previous errors. Anyway I am coping them 
again along with case.vorbdef 

STDOUT 
cp: cannot create regular file '/localscratch//.tmp_lapw1para.30532': 
Permission denied 
cp: cannot stat '/localscratch//.tmp_lapw1para.30532': No such file or 
directory 
/localscratch//.tmp_testpara_new.30532_2: Permission denied. 
grep: /localscratch//.tmp_lapw1para.30532: No such file or directory 
cut: /localscratch//.tmp_testpara_new.30532_2: No such file or directory 
forrtl: severe (24): end-of-file during read, unit 7, file 
/scratch/WIEN2k17/TEST/T-hubU/T-hubU.vorbup 
Image PC Routine Line Source 
lapw1c 00461858 Unknown Unknown Unknown 
lapw1c 00497DDA Unknown Unknown Unknown 
lapw1c 0042C543 inilpw_ 276 inilpw.f 
lapw1c 0042F302 MAIN__ 42 lapw1_tmp_.F 
lapw1c 00403FEE Unknown Unknown Unknown 
libc.so.6 2AD5081B12E0 Unknown Unknown Unknown 
lapw1c 00403EEA Unknown Unknown Unknown 


5. next I tried: energyup/dn copied to energyup_1/dn_1, all dmat* removed and 
then tried runsp_lapw -NI -p -dm -orb -ec 0.0001 
But it gave me the same error. I has changed the energyup_1/dn_1 (empty now) 

6. I tried running x lapw1 with deleting dmat* as William as sugested, but this 
also leads for the same error as I have given in 5. above. 


I am very much appreciate if anyone give the correct way to do hubbard U 
included PARALLEL calculation with Wien2k 17.1. 

I have asked our supercomputers to install the latest version. But due to 
internal issue this will be late more than two months more. I cannot wait that 
long. 

Thank you 

Daya 




On Tuesday, June 26, 2018 2:52 PM, William Lafargue-dit-Hauret 
 wrote: 


Did you try to add "-s lapw1" in your command line dedicated to the DFT+U 
calculation ? Remove any *dmat* files before. 
W. 

Le 26/06/2018 à 22:46, shaymlal dayananda a écrit : 



Dear William 

It is a error (messed up with another case.dayfile ) in the mail when I copy 
the day file to the mail, other than that , the problem and the errors are the 
same. 

Thank you 
Daya 


___
Wien mailing list [ mailto:Wien@zeus.theochem.tuwien.ac.at | 
Wien@zeus.theochem.tuwien.ac.at ] [ 
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien | 
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 | 
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ] 



-- 
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: [ mailto:william.lafargue-dit-hau...@univ-rennes1.fr | 
william.lafargue-dit-hau...@univ-rennes1.fr ] 
___ 
Wien mailing list 
[ mailto:Wien@zeus.theochem.tuwien.ac.at | Wien@zeus.theochem.tuwien.ac.at ] 
[ http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien | 
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 | 
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
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] Error in DOS calculation with WIEN2k 17.1

2018-07-31 Thread William Lafargue-dit-Hauret 
case.vector* files are located into the SCRATCH directory. If you would 
like to redefine it for a specific job, you can add the option "-scratch 
directory_name" to the run_lapw command (Section 5.1.4 UG).


Best,

William


Le 31/07/2018 à 20:16, prasad jayasena a écrit :

Dear William


Thank you. The calculation is running now. Hope it will finish smoothly


Is there a way to set this vector files to generate in the proper 
place instead of in the working directory? (Or to set DOS to get the 
files from working directory?)


Thank you again for the prompt reply

Prasad

On Tuesday, July 31, 2018, 12:01:33 p.m. CST, William 
Lafargue-dit-Hauret  wrote:



Dear Prasad,

case.vectorup/dn must be present in the scratch directory, not in the 
working directory.


Best,

William


Le 31/07/2018 à 19:55, prasad jayasena a écrit :

Dear developers and users

I am using wien2k 17.1 version. I recently completed scf calculation 
without any error (runsp_lapw -p  -i 140 -ec 0.1 -cc 0.0001 -NI).


Now I tried calculation of DOS. But when I try *x lapw2 -p -up -qtl 
*I am getting the following error.


running in single mode
forrtl: severe (24): end-of-file during read, unit 10, file 
/home/scratch/UB-8.5-5000-SCF.vectorup


However, in the working directory, there are two none-empty case. 
vectorup and case.vectordn files. I cannot solve this error. The 
other thing is, if I did parallel mode scf calculation I believe it 
needs to create several vectorup/dn_x files. But here it is a single 
file.


Can someone please let me know what is wrong here.

Thank you

Prasad


___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at <mailto: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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email:william.lafargue-dit-hau...@univ-rennes1.fr 
<mailto:william.lafargue-dit-hau...@univ-rennes1.fr>

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at <mailto: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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Error in DOS calculation with WIEN2k 17.1

2018-07-31 Thread William Lafargue-dit-Hauret 

Dear Prasad,

case.vectorup/dn must be present in the scratch directory, not in the 
working directory.


Best,

William


Le 31/07/2018 à 19:55, prasad jayasena a écrit :

Dear developers and users

I am using wien2k 17.1 version. I recently completed scf calculation 
without any error (runsp_lapw -p  -i 140 -ec 0.1 -cc 0.0001 -NI).


Now I tried calculation of DOS. But when I try *x lapw2 -p -up -qtl *I 
am getting the following error.


running in single mode
forrtl: severe (24): end-of-file during read, unit 10, file 
/home/scratch/UB-8.5-5000-SCF.vectorup


However, in the working directory, there are two none-empty case. 
vectorup and case.vectordn files. I cannot solve this error. The other 
thing is, if I did parallel mode scf calculation I believe it needs to 
create several vectorup/dn_x files. But here it is a single file.


Can someone please let me know what is wrong here.

Thank you

Prasad


___
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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Error in Hub-U calculation

2018-06-26 Thread William Lafargue-dit-Hauret 
Did you try to add "-s lapw1" in your command line dedicated to the 
DFT+U calculation ? Remove any *dmat* files before.


W.


Le 26/06/2018 à 22:46, shaymlal dayananda a écrit :

Dear William

It is a error (messed up with another case.dayfile ) in the mail when 
I copy the day file to the mail, other than that , the problem and the 
errors are the same.


Thank you
Daya


___
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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Error in Hub-U calculation

2018-06-26 Thread William Lafargue-dit-Hauret 

Hi,

I noticed in your dayfile your filenames and directory name are 
inconsistent.


--

case.dayfile is ;

Calculating *U3O8-8.5-5000* in /scratch/WIEN2k17/*UB-8.5-5000*
on gra144 with PID 28448

...

--

William


Le 26/06/2018 à 21:29, shaymlal dayananda a écrit :

Dear Prof. Blaha

Thank you for your reply, I tried your instructions, but I am afraid that I am
still getting the same error.
This is what I did1. I copied case.energyup/dn as case.energyup_1/dn_12 copied
case.dmatup_old and case.dmatup_old to case.dmatup and case.dmatup3. removed
*.bro*  ( But there were no files)
And rerun the job script. But again I got the same error I got before. I
noticed that now the energyup_1 file is empty again and case.enegydn_1 is
missing.
I repeated this in fresh directory, but nothing changes. My lapw with spin
polarization runs without any problem. Only this hubard U inclusion gives
troubles. Can this be an issue with my job script (attached in the previous
reply) or installation?

Thank you and I appreciate your valuable advice and support.I am re-sending 
this mail since I didn't get any reply yet. My apology about that.
Daya


___
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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Problem regarding case.inq file

2018-06-25 Thread William Lafargue-dit-Hauret 

Dear Bushra,

As mentioned by the error, you have to reduce your number of studied 
atoms. After briefly looking at your input file, you can restrict this 
number to 3 and only specify cases for atoms number 7, 11 and 12.


Best,

William


Le 26/06/2018 à 01:11, BUSHRA SABIR a écrit :

Respected Peter Blaha and wien2k users

I am working on 30 atom structure with no symmetry present. when i am 
trying to calculate d states splitting for Ru with following case.inq 
file (x qtl -band -up)

-9.0   3.0   Emin  Emax
  30 number of atoms
   1  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   2  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   3  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   4  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   5  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   6  -2  0  0   iatom,qsplit,symmetrize,locrot
4   0  1  2  3   nL, l-values
   7   2  1  2   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
-0.6795  -0.2185 0.1643
-.1921   0.517  -0.1568
   8  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
   9  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  10  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  11   2  1  2   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
-0.2203 -0.7218 -0.1529
-0.4813 -0.1829 -0.1806
  12   2  1  2   iatom,qsplit,symmetrize,locrot
3   0  1  2  nL, l-values
0.6715 0.4586 -0.1752
-0.220 -0.7217 -0.1528
  13  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  14  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  15  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  16  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  17  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  18  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  19  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  20  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  21  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  22  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  23  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  24  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  25  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  26  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  27  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  28  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  29  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values
  30  -2  0  0   iatom,qsplit,symmetrize,locrot
2   0  1 nL, l-values

it give me error

ERROR: more than 25 atoms not supported
0.005u 0.038s 0.00.09 33.3%  0+0k 0+16io 0pf+0w

what should i do?

Bushra
UC Davis,CA



___
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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Transition-State/NEB Calculations

2018-06-15 Thread William Lafargue-dit-Hauret 
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
<mailto:Wien@zeus.theochem.tuwien.ac.at>

https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIFAw=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=M0UybH2-gJMze3tSI4Kh1ezEr54mB7Q2FdhXL7yxSW4=Ee0zsmG3LVm50umzwlug_XAYvuKha_lG1H9uUdZQlNI=

<https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwIFAw=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=M0UybH2-gJMze3tSI4Kh1ezEr54mB7Q2FdhXL7yxSW4=Ee0zsmG3LVm50umzwlug_XAYvuKha_lG1H9uUdZQlNI=>
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=DwIFAw=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=M0UybH2-gJMze3tSI4Kh1ezEr54mB7Q2FdhXL7yxSW4=NfajgiBSfBEAqcHcnDRizCluWrlYKa_vX-RHicaZuMs=

<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwIFAw=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=M0UybH2-gJMze3tSI4Kh1ezEr54mB7Q2FdhXL7yxSW4=NfajgiBSfBEAqcHcnDRizCluWrlYKa_vX-RHicaZuMs=>




--
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 <http://www.numis.northwestern.edu> ; 
Corrosion in 4D: MURI4D.numis.northwestern.edu 
<http://MURI4D.numis.northwestern.edu>
Partner of the CFW 100% program for gender equity, 
www.cfw.org/100-percent <http://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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Cif2Struct again

2018-05-27 Thread William Lafargue-dit-Hauret 

Dear Sherif,

Just open your cif file using a Notepad or a terminal, and you will see 
more than one cell parameters and/or atomic coordinates are present, as 
Xavier said.


You can modify it by hand, but I recommend you to use a crystallographic 
software to generate it safely (Endavour for example).


Cheers,

William


Le 27/05/2018 à 22:49, Sherif Yehia a écrit :

Dear users  and expert

 I put question before on how to change cif to struct files   I got 
kindly  help  on changing cif to struct from


Xavier Rocquefelte 
<https://www.mail-archive.com/search?l=wien@zeus.theochem.tuwien.ac.at=from:%22Xavier+Rocquefelte%22> 
Tue, 06 Mar 2018 
<https://www.mail-archive.com/search?l=wien@zeus.theochem.tuwien.ac.at=date:20180306> 



Your cif file contains 3 settings explaining why cif2struct cannot work.

unfortunately  I didn't   understand   what he did to change it to one 
setting   (my mistake)



I am attaching another one for YFe3

 Can I get some help with explanation on how to change .cif to struct  
to work right


Thank you in advance



___
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


--
William LAFARGUE-DIT-HAURET
PhD Student
--
Institut des Sciences Chimiques de Rennes UMR 6226
Equipe Chimie Théorique Inorganique
Université de Rennes 1 - Campus de Beaulieu
35042 Rennes, France
Building 10B, Desk 211
Phone: +33 (0)2.23.23.57.91
Email: william.lafargue-dit-hau...@univ-rennes1.fr

___
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] Wien Digest, Vol 147, Issue 4

2018-02-24 Thread William Lafargue-dit-Hauret 
Dear Victor,
If you remove the space between « print » and the first parenthesis, you can do 
it in python 3 ; this is the print function.

Best regards,
William

> Le 25 févr. 2018 à 08:04, Badis Bennecer  a écrit :
> 
> Dear Victor,
> I must confess,  that when I wrote the answer I did not even think about 
> using a correct fortran language, i mean using correct fortran statements. 
> 
> Thank you very much for correcting me.
> 
> All the best and have a nice day
> 
> Badis
> 
> 
> 
> 
> From: Wien  on behalf of Víctor 
> Luaña Cabal 
> Sent: Sunday, February 25, 2018 5:39 AM
> To: A Mailing list for WIEN2k users
> Cc: Victor Luaña
> Subject: Re: [Wien] Wien Digest, Vol 147, Issue 4
>  
> On Sun, Feb 25, 2018 at 06:06:39AM +, Badis Bennecer wrote:
> > Dear Victor,
> > 
> > 
> > It is minus signs
> 
> Badis,
> 
> Sorry, but my main question was the language (computer language).
> Otherwise
> 
> print (( 2.8*2)*2+(-0.31749*2)+( -0.98948))
> 
> the result is 6.82026
> 
> Maybe you were using some form of lisp? The odd number of parenthesis:
> open 5, close 4, were my main trouble. I had to add an extra ")".  Of
> course,  minus signs obtained from web pages may cause awful errors so
> it is important to prevent that.
> 
> 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 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] Magnetocrystalline anisotropy

2018-01-17 Thread William Lafargue-dit-Hauret 

Dear Prof. Blaha and Marks,

Thank you for your comments and suggestions.

Looking at the SRC_orb/main.f, orb seems to read potential files to mix 
with old vorb files.


William


Le 17/01/2018 à 08:03, Peter Blaha a écrit :

Just a few comments:

In many posts to this topic I saw the   -c  switch. This is not 
necessary and prone to errors. Don't use   -c . It will be done 
automatically.


I think, the orb program reads   case.dmat* files, and produces 
case.vorb* files. It is not reading  vorb files.

And it does read the complex part !!!

And third:    the vorb* potential should be applied only once.

It can be done in   x lapw1 -orb -up/dn  OR in
    x lapwso -orb -up
but not in both.

Application in lapwso also includes cross terms between spin-up and 
dn, while in lapw1 it excludes them.


When reporting differences between wien2k_16 and 17, you have to find 
out, what causes these differences.
a) compare case.vorbup/dn in both cases. Are they the same/similar ? 
In particular with respect to symmetry (+m and -m terms symmetric ???)

b) run lapwso of 17 with vorbs of 16 and vice versa.

If nothing helps, send me your struct file + some details (inputs) and 
I'll check it myself.


Peter


Am 16.01.2018 um 17:57 schrieb William Lafargue-dit-Hauret:

Dear Profs. Blaha and Marks,

Thank you for your advices. I have a question regarding your comment 
on the EECE case.


The resulting effective potential of LDA+U and EECE corrections is 
decomposed in vorb files, but I don't understand why the 
spin-coupling file case.vorbud shouldn't appear in the second case.


I have a second question regarding the reading of these orbital 
potential files. We noticed the orb program read only the real part, 
neglecting the imaginary one (Prof. Marks already noticed it in the 
source code). Due to our energy scale which is tiny, could we expect 
an impact of such approximation ? Considering your last comments, it 
seems not due to the execution of the orb program only in lapw1 and 
not during the perturbative procedure.


Thank you by advance.

All the best,

William Lafargue-dit-Hauret


Le 16/01/2018 à 17:05, Xavier Rocquefelte a écrit :

I was not clear Peter. I clarify the way we proceed.

We do runsp_lapw -eece -p -ec 0.1 -NI

Then for larger EMAX and kmesh without SO we do :

x lapw1 -up -c -orb
x lapw1 -dn -c -orb

And for the different magnetization directions we do:

x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c




Le 16/01/2018 à 16:58, Peter Blaha a écrit :

Hups: If this is true, you are counting the orbital potential twice !

-orb should only be present in the lapwso step.
(And in fact, the lapw1 steps need to be done just once for the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for 
EECE.


You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

Dear Peter

You are totally correct. We are doing SO non-selfconsistent by 
using a standard procedure for EECE calculations:


runsp_lapw -eece -p -ec 0.1 -NI

and then we estimate the MAE using this non-SCF procedure :

Increase EMAX in case.in1c - increase kmesh if needed 

x lapw1 -up -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

Hallo Xavier,

Looks rather strange.

Eventually I would have expected problems both, in 16.1 and 17.1 
(but not 14.2) due to the off-diagonal density matrices. But this 
should concern ONLY LDA+U, not -eece.


Just to be sure:

I expect you do SO non-selfconsistent, so vorbup/dn(du) files are 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

Here is a document showing the results graphically.

https://filesender.renater.fr/?s=download=8ac3a214-edfa-4894-fa1f-27aba5a5522f 



It really looks like the problem we had before (using bad kmesh).

We test it on two different compounds and in both cases 
WIEN2k_16 gives a correct picture and not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


Dear All

Finally the problem is not completely solved.

More precisely, when we are doing GGA+SO calculations and using 
a correct kmesh (no temporal symmetry), we obtain a symmetric 
magnetocrystalline anisotropy, namely same MAE along [0 1 0] 
and [0 -1 0].


In contrast, when we are doing GGA+U+SO or EECE+SO with a 
correct kmesh we still obtain non-symmetric MAE, namely MAE 
along [0 1 0] and [0 -1 0] are different.


In addition, the so obtained MAE looks

Re: [Wien] Magnetocrystalline anisotropy

2018-01-16 Thread William Lafargue-dit-Hauret 

Dear Profs. Blaha and Marks,

Thank you for your advices. I have a question regarding your comment on 
the EECE case.


The resulting effective potential of LDA+U and EECE corrections is 
decomposed in vorb files, but I don't understand why the spin-coupling 
file case.vorbud shouldn't appear in the second case.


I have a second question regarding the reading of these orbital 
potential files. We noticed the orb program read only the real part, 
neglecting the imaginary one (Prof. Marks already noticed it in the 
source code). Due to our energy scale which is tiny, could we expect an 
impact of such approximation ? Considering your last comments, it seems 
not due to the execution of the orb program only in lapw1 and not during 
the perturbative procedure.


Thank you by advance.

All the best,

William Lafargue-dit-Hauret


Le 16/01/2018 à 17:05, Xavier Rocquefelte a écrit :

I was not clear Peter. I clarify the way we proceed.

We do runsp_lapw -eece -p -ec 0.1 -NI

Then for larger EMAX and kmesh without SO we do :

x lapw1 -up -c -orb
x lapw1 -dn -c -orb

And for the different magnetization directions we do:

x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c




Le 16/01/2018 à 16:58, Peter Blaha a écrit :

Hups: If this is true, you are counting the orbital potential twice !

-orb should only be present in the lapwso step.
(And in fact, the lapw1 steps need to be done just once for the 
increased k-mesh; but not when changing the M-direction in case.inso)


Please check the presence of case.vorbud. It must not be there for EECE.

You could also test Laurence suggestion, running:

x lapw1 -up/dn -orb
x lapwso -up  (no -orb !!!)

and see of it makes a difference.

On 01/16/2018 04:52 PM, Xavier Rocquefelte wrote:

Dear Peter

You are totally correct. We are doing SO non-selfconsistent by using 
a standard procedure for EECE calculations:


runsp_lapw -eece -p -ec 0.1 -NI

and then we estimate the MAE using this non-SCF procedure :

Increase EMAX in case.in1c - increase kmesh if needed 

x lapw1 -up -c -orb
x lapw1 -dn -c -orb
x lapwso -c -up  -orb
x lapw2 -so -up  -c
x lapw2 -so -dn  -c

Such a procedure was working nicely in previous WIEN2k versions.
Best Regards
Xavier



Le 16/01/2018 à 16:34, Peter Blaha a écrit :

Hallo Xavier,

Looks rather strange.

Eventually I would have expected problems both, in 16.1 and 17.1 
(but not 14.2) due to the off-diagonal density matrices. But this 
should concern ONLY LDA+U, not -eece.


Just to be sure:

I expect you do SO non-selfconsistent, so vorbup/dn(du) files are 
always the same ??  (just running lapwso and lapw2 -so)


Did you make sure that for -eece -so, case.vorbud is NOT present 
(from previous LDA+U).


Peter


On 01/16/2018 02:50 PM, Xavier Rocquefelte wrote:

Here is a document showing the results graphically.

https://filesender.renater.fr/?s=download=8ac3a214-edfa-4894-fa1f-27aba5a5522f 



It really looks like the problem we had before (using bad kmesh).

We test it on two different compounds and in both cases WIEN2k_16 
gives a correct picture and not WIEN2k_17.


We are now comparing the two versions of the code.

Regards

Xavier


Le 16/01/2018 à 12:10, Xavier Rocquefelte a écrit :


Dear All

Finally the problem is not completely solved.

More precisely, when we are doing GGA+SO calculations and using a 
correct kmesh (no temporal symmetry), we obtain a symmetric 
magnetocrystalline anisotropy, namely same MAE along [0 1 0] and 
[0 -1 0].


In contrast, when we are doing GGA+U+SO or EECE+SO with a correct 
kmesh we still obtain non-symmetric MAE, namely MAE along [0 1 0] 
and [0 -1 0] are different.


In addition, the so obtained MAE looks similar to the ones 
obtained in GGA+SO with a bad kmesh (including temporal symmetry).


At this moment, we are checking all the recent modifications in 
SRC_ORB and SRC_LAPW2 related to the manipulation of case.vorbup, 
case.vorbdn and case.vorbud files.


Surprisingly, the EECE+SO calculations in WIEN2k_16 are 
symmetric, while not in WIEN2k_17.


Next soon ... I hope.

Xavier


Le 10/01/2018 à 15:10, Xavier Rocquefelte a écrit :


Dear All

The problem is solved and was related to one stupid human mistake.

It was necessary to generate a kmesh without adding inversion 
(time-inversion symmetry).

Indeed, as mentionned in the userguide when using kgen program:

# *"add inversion" ?* This is asked only when inversion is NOT 
present.


  * Say *"YES"* in all cases except when you do *spin-polarized
    (magnetic) calculations WITH spin-orbit coupling * (this breaks
    time-inversion symmetry and thus one MUST NOT add inversion
    symmetry (eigenvalues at +k and -k may be different).

If you properly generate the kmesh for the spin-orbit 
calculations by doing : x kgen -fbz, then you obtain a symmetric 
magnetic anisotrop. In conclusion the asymmetry I obtained was 
due to an improper definition of the kmesh (adding artificially 
time-inversion).