Re: [Wien] segmentation fault in lapwso

[Luis Ogando]

Dear Wien2k Community,
   I have just sent the "problematic" directory to Prof. Pavel Ondračka.
   It is too large to be sent through the list, but if you are interested
in, please let me know and I will send you a copy.
   Feel free to distribute the directory to anyone and test it in any way.
   All the best,
   Luis


Em qua., 18 de ago. de 2021 às 15:01, Pavel Ondračka <
pavel.ondra...@email.cz> escreveu:

> Right, I think that the reason deallocate is failing because the memory
> has been corrupted at some earlier point is quite clear, the only other
> option why it should crash would be that it was not allocated at all,
> which seem not to be the case here... The question is what corrupted
> the memory and even more strange is why does it work if we disable MKL
> multithreading?
>
> It could indeed be that we are doing something wrong. I can imagine the
> memory could be corrupted in some BLAS call if the number of
> columns/rows passed to the specific BLAS call is more than the actual
> size of the matrix, than this could easily happen (and the
> multithreading is somehow influencing what the final value of the
> corrupted memory, and depending on the final value the deallocate could
> fail or pass somehow). This should be possible to diagnose with
> valgrind as suggested.
>
> Luis, can you upload the testcase somewhere, or recompile with
> debuginfo as suggested by Laurence earlier, run "valgrind --track-
> origins=yes lapwso lapwso.def" and send the output? Just be warned,
> there is a massive slowdown with valgrind (up to 100x) and the logfile
> can get very large.
>
> Best regards
> Pavel
>
>
> On Wed, 2021-08-18 at 12:10 -0500, Laurence Marks wrote:
> > Correction, I was looking at an older modules.F. It looks like it
> > should be
> >
> > DEALLOCATE(vect,stat=IV) ; if(IV .ne. 0)write(*,*)IV
> >
> >
> > On Wed, Aug 18, 2021 at 11:23 AM Laurence Marks
> >  wrote:
> > > I do wonder about this. I suggest editing module.F and changing
> > > lines 118 and 119 to
> > >  DEALLOCATE(en,stat=Ien) ; if(Ien .ne. 0)write(*,*)'Err en
> > > ',ien
> > >  DEALLOCATE(vnorm,stat=Ivn ; ) if(Ivn .ne. 0)write(*,*)'Err
> > > vnorm ',Ivn
> > >
> > > There is every chance that the bug is not in those lines, but
> > > somewhere completely different. SIGSEV often means that the code
> > > has been overwritten, for instance arrays going out of bounds.
> > >
> > > You can also recompile with -g (don't change other options)
> > > added, and/or -C. Sometimes this is better. Or use other things
> > > like debuggers or valgrind.
> > >
> > > On Wed, Aug 18, 2021 at 10:47 AM Pavel Ondračka
> > >  wrote:
> > > > I'm CCing the list back as the crash was now diagnosed to a
> > > > likely
> > > > MKL
> > > > problem, see below for more details.
> > > > >
> > > > >
> > > > > > So just to be clear, explicitly setting OMP_STACKSIZE=1g does
> > > > not
> > > > > > help
> > > > > > to solve the issue?
> > > > > >
> > > > >
> > > > >
> > > > > Right! OMP_STACKSIZE=1g with OMP_NUM_THREADS=4 does not solve
> > > > > the
> > > > > problem!
> > > > >
> > > > > >
> > > > > > The problem is that the OpenMP code in lapwso is very simple,
> > > > so I'm
> > > > > > having problems seeing how it could be causing the problems.
> > > > > >
> > > > > > Could you also try to see what happens if run with:
> > > > > > OMP_NUM_THREADS=1
> > > > > > MKL_NUM_THREADS=4
> > > > > >
> > > > >
> > > > >
> > > > > It does not work with these values, but I checked and it works
> > > > > reverting them:
> > > > > OMP_NUM_THREADS=4
> > > > > MKL_NUM_THREADS=1
> > > >
> > > > This was very helpfull and IMO points to a problem with MKL
> > > > instead
> > > > of
> > > > Wien2k.
> > > >
> > > > Unfortunatelly setting MKL_NUM_THREADS=1 globally will reduce the
> > > > OpenMP performance, mostly in lapw1 but also at other places. So
> > > > if
> > > > you
> > > > want to keep the OpenMP BLAS/lapack level parallelism you have to
> > > > either find some MKL version that works (if you do please report
> > > > it
> > > > here), link with OpenBLAS (using it for lapwso is enough) or
> > > > create
> > > > a
> > > > simple wrapper that sets the MKL_NUM_THREADS=1 just for lapwso,
> > > > i.e.,
> > > > rename lapwso binary in WIENROOT to lapwso_bin and create new
> > > > lapwso
> > > > file there with:
> > > >
> > > > #!/bin/bash
> > > > MKL_NUM_THREADS=1 lapwso_bin $1
> > > >
> > > > and set it to executable with chmod +x lapwso.
> > > >
> > > > Or maybe MKL has a non-OpenMP version which you could link with
> > > > just
> > > > lapwso and use standard one in other parts, but dunno, I mostly
> > > > use
> > > > OpenBLAS. If you need some further help, let me know.
> > > >
> > > > Reporting the issue to intel could be also nice, however I never
> > > > had
> > > > any real luck there and it is also a bit problematic as you can't
> > > > provide testcase due to Wien2k being proprietary code...
> > > >
> > > > Best regards
> > > > Pavel
> > > >
> > > > >
> > > 

Re: [Wien] segmentation fault in lapwso

[Luis Ogando]

Dear Wien2k Community,

   Just adding two points:

1) Dear Prof. Fecher, in my case, restarting the machine did not solve the
problem and all the executables were compiled with the same Intel oneAPI
version.

2) Dear Prof. Ondračka, in my case, I used the lapwso serial version. In
fact, it was a very simple system, named, InP in the zinc blende symmetry.

   If someone needs/wants more information, please let me know.
   All the best,
 Luis

Em qua., 18 de ago. de 2021 às 04:32, Pavel Ondračka <
pavel.ondra...@email.cz> escreveu:

> Dear Luis,
>
> one very easy thing to try could be to set environment variable
> OMP_STACKSIZE to something large like "1g", i.e., "export
> OMP_STACKSIZE=1g" before run_lapw. Small OpenMP stacksize caused issues
> for us previously so could be the case here as well. The only explicit
> omp loop in hsocalc.F does allocates all private variables on the stack
> and few of them are arrays, it is feasible this could be the case.
>
> 2 prof. Blaha:
> from a very brief visual inspection of the OpenMP code in lapwso, I
> believe there could be another small issue with combined MPI OpenMP. At
> lines hsocalc.F:159 and hsocalc.F:160 the variables ibf_local and
> ibi_local should be probably private. This should not be the cause of
> the here reported problems though as that would only influence the
> lapwso_mpi. The rest seems OK though (at first glance).
>
> Best regards
> Pavel
>
> On Tue, 2021-08-17 at 18:18 -0300, Luis Ogando wrote:
> > Dear Wien2k Community,
> >Greetings!
> >This message is only to inform that I also had a fragmentation
> > problem with lapwso and Wien2k-21.
> >It was a very strange case. After a converged SCF cycle with mBJ
> > and SO, I could not run "run_lapw -NI -so ...". In this case, I
> > always got the following error after lapwso:
> >
> > forrtl: severe (174): SIGSEGV, segmentation fault occurred
> > Image  PCRoutineLine
> >  Source
> > lapwso 0046A0EA  Unknown   Unknown
> >  Unknown
> > libpthread-2.28.s  1530B217B730  Unknown   Unknown
> >  Unknown
> > libiomp5.so1530B1D132FB  Unknown   Unknown
> >  Unknown
> > libiomp5.so1530B1D13049  Unknown   Unknown
> >  Unknown
> > libiomp5.so1530B1D14B59  Unknown   Unknown
> >  Unknown
> > libiomp5.so1530B1D161E8  Unknown   Unknown
> >  Unknown
> > libiomp5.so1530B1D0C926  Unknown   Unknown
> >  Unknown
> > lapwso 0049CA86  Unknown   Unknown
> >  Unknown
> > lapwso 0040D77F  hmsout_mp_finit_h 119
> >  modules.F
> > lapwso 0042B94E  MAIN__622
> >  lapwso.F
> > lapwso 00404D22  Unknown   Unknown
> >  Unknown
> > libc-2.28.so   1530A3E3609B  __libc_start_main Unknown
> >  Unknown
> > lapwso 00404C2A  Unknown   Unknown
> >  Unknown
> > 0.167u 0.051s 0:00.10 210.0% 0+0k 0+1976io 0pf+0w
> > error: command   /home/ogando/Wien/Wien21/lapwso lapwso.def   failed
> >
> >The solution was to change OMP_NUM_THREADS from 4 to 1.
> >I checked and it also worked with OMP_NUM_THREADS equal to 2 but
> > not 3.
> >If someone is interested in the compilation options or any other
> > information, please ask.
> >All the best,
> >   Luis
> >
> >
> >
> > Em qui., 10 de jun. de 2021 às 08:17, Fecher, Gerhard
> >  escreveu:
> > > Dear all,
> > > while running a -so calculation I hit a segmentation fault in
> > > lapwso
> > > (see below) with the latest version Wien2k21.1 that does NOT appear
> > > in 19.2.
> > > (appeared for two different systems in fresh directories)
> > >
> > > Did someone experience the same, or did I miss a report and may be
> > > not up to date?
> > >
> > > I used all settings the same (mostly default values), and the same
> > > compilers and options (Intel OneAPI 2021 2.0 and Parallel Studio XE
> > > 2017.4.056) for both versions, 21.1 and 19.2
> > >
> > > forrtl: severe (174): SIGSEGV, segmentation fault occurred
> > > Image  PCRoutineLine
> > > Source
> > > lapwso 0046CE0A  Unknown   Unknown
> > > Unknown
> > > libpthread-2

Re: [Wien] Mixing

[Luis Ogando]

Dear Prof. Marks,
   I got the reference for future publications!
   Thank you one more time!
   All the best,
Luis

Em ter., 17 de ago. de 2021 às 18:59, Laurence Marks <
laurence.ma...@gmail.com> escreveu:

> If any is interested, the current mixer (21.1) is described in
> https://doi.org/10.1021/acs.jctc.1c00630 , which is also the appropriate
> reference if needed.
>
> --
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought" Albert Szent-Györgyi
> ___
> 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] segmentation fault in lapwso

[Luis Ogando]

Dear Wien2k Community,
   Greetings!
   This message is only to inform that I also had a fragmentation problem
with lapwso and Wien2k-21.
   It was a very strange case. After a converged SCF cycle with mBJ and SO,
I could not run "run_lapw -NI -so ...". In this case, I always got the
following error after lapwso:

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

lapwso 0046A0EA  Unknown   Unknown  Unknown
libpthread-2.28.s  1530B217B730  Unknown   Unknown  Unknown
libiomp5.so1530B1D132FB  Unknown   Unknown  Unknown
libiomp5.so1530B1D13049  Unknown   Unknown  Unknown
libiomp5.so1530B1D14B59  Unknown   Unknown  Unknown
libiomp5.so1530B1D161E8  Unknown   Unknown  Unknown
libiomp5.so1530B1D0C926  Unknown   Unknown  Unknown
lapwso 0049CA86  Unknown   Unknown  Unknown
lapwso 0040D77F  hmsout_mp_finit_h 119
 modules.F
lapwso 0042B94E  MAIN__622  lapwso.F
lapwso 00404D22  Unknown   Unknown  Unknown
libc-2.28.so   1530A3E3609B  __libc_start_main Unknown  Unknown
lapwso 00404C2A  Unknown   Unknown  Unknown
0.167u 0.051s 0:00.10 210.0% 0+0k 0+1976io 0pf+0w
error: command   /home/ogando/Wien/Wien21/lapwso lapwso.def   failed

   The solution was to change OMP_NUM_THREADS from 4 to 1.
   I checked and it also worked with OMP_NUM_THREADS equal to 2 but not 3.
   If someone is interested in the compilation options or any other
information, please ask.
   All the best,
  Luis



Em qui., 10 de jun. de 2021 às 08:17, Fecher, Gerhard 
escreveu:

> Dear all,
> while running a -so calculation I hit a segmentation fault in lapwso (see
> below) with the latest version Wien2k21.1 that does NOT appear in 19.2.
> (appeared for two different systems in fresh directories)
>
> Did someone experience the same, or did I miss a report and may be not up
> to date?
>
> I used all settings the same (mostly default values), and the same
> compilers and options (Intel OneAPI 2021 2.0 and Parallel Studio XE
> 2017.4.056) for both versions, 21.1 and 19.2
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLine
> Source
> lapwso 0046CE0A  Unknown   Unknown  Unknown
> libpthread-2.22.s  2AFBCC6DAB10  Unknown   Unknown  Unknown
> libiomp5.so2AFBCCF2C8E8  Unknown   Unknown  Unknown
> lapwso 0049F7A6  Unknown   Unknown  Unknown
> lapwso 00421E9E  hmsec_926  hmsec.F
>
> line 926 is;   deallocate(meigve)
> indeed, if  this is the correct line at all.
>
> indeed in 21.2 (I have seen that hmsec.F is different in 19.2)
>
> Thanks for any suggestions that help
>
> 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 Physics
> Johannes Gutenberg - University
> 55099 Mainz
> ___
> 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] In the calculation of elastic properties why ​​​​​rhombohedral lattice parameter needs same k-mesh as used in pristine case

[Luis Ogando]

Dear Bhamu,

Please, check if init_lpaw did not rotate your cell. Perhapes 18.184512
is now at y axis, b parameter.
   All the best,
 Luis

Em sex, 17 de mai de 2019 às 07:49, Dr. K. C. Bhamu 
escreveu:

> Dear Wien2k users,
>
> I am running a cubic (F) system having a=b=c=10.446600Bohr. The default
> k-mesh size is 14 14 14 (3000kpt in FBZ).
> I applied tetragonal and rhombohedral strain on optimized lattice
> parameters (on above a,b,c) and the resultant strained a/b/c are 10.429247
> /10.429247/10.481393 Bohr for tetragonal strain and 7.386862/7.386862/
> 18.184512 Bohr for rhombohedral strain.
>
> My script advise me to use 20 20 8 kmesh size for the rhombohedral case
> and "14 14 14" (as there is only slight change in a/b/c) for tetragonal
> case.
>
> But for the rhombohedral case I am not able to use 20 20 8 mesh size and
> the kgen program suggest me to use equal mesh in x and z direction (see
> below in blue).
>
> Could you someone please advice me why I can not use the mesh size  20 20
> 8 for the rhombohedral case?
>
> I may be convinced about my doubt because I am having  equal "length of
> reciprocal lattice vectors:   1.041   1.041   1.041".  Am I right? If so,
> then also I need to know why a lattice parameter which is almost double in
> one direct wrt original cubic latice need the same k-points as used in case
> of cubic case. The answer may be somewhere in symmetry operations but I
> could not completely understand it.
>
>
>
>6  symmetry operations without inversion
>  inversion added (non-spinpolarized non-so calculation)
>   NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
> 0
>  length of reciprocal lattice vectors:   1.041   1.041   1.041   0.000
> 0.000   0.000
>   Specify 3 mesh-divisions (n1,n2,n3):
> 20 20 8
>  Lattice symmetry requires equal mesh in x and z direction
>   Specify 3 mesh-divisions (n1,n2,n3):
>
>
> regards
> Bhamu
>
>
> ___
> 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] MKL error

[Luis Ogando]

Dear Yundi,

   Thank you for your help !
   I am now discussing this with the TI team.
   All the best,
  Luis


Em qui, 30 de ago de 2018 às 18:18, Yundi Quan  escreveu:

> The input parameters for DSTEIN2 can be found here
>
> http://www.netlib.org/scalapack/explore-html/dc/deb/dstein2_8f_source.html
>
> Parameter 4 and 6 are M and IBLOCK respectively. The number of MPI
> processes probably is too large.
>
>
>
>
>
> On Thu, Aug 30, 2018 at 12:01 PM, Luis Ogando  wrote:
>
>> Dear Wien2k community,
>>
>>I am calculating a large system (100 atoms) with only one K-point.
>>When I try the job with 288 MPI processes, it goes smoothly but
>> exceeds the allowed calculation time.
>>On the other hand, when I try the same calculation with 1152 MPI
>> processes, I get the following message during lapw1 execution:
>>
>> Intel MKL ERROR: Parameter 6 was incorrect on entry to DSTEIN2.Intel MKL
>> ERROR: Parameter 4 was incorrect on entry to DSTEIN2.
>>
>>Does anyone have any hint to solve this problem ?
>>All the best,
>>   Luis
>>
>> ___
>> 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

[Wien] MKL error

[Luis Ogando]

Dear Wien2k community,

   I am calculating a large system (100 atoms) with only one K-point.
   When I try the job with 288 MPI processes, it goes smoothly but exceeds
the allowed calculation time.
   On the other hand, when I try the same calculation with 1152 MPI
processes, I get the following message during lapw1 execution:

Intel MKL ERROR: Parameter 6 was incorrect on entry to DSTEIN2.Intel MKL
ERROR: Parameter 4 was incorrect on entry to DSTEIN2.

   Does anyone have any hint to solve this problem ?
   All the best,
  Luis
___
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] Core electron energy with hybrid functional

[Luis Ogando]

Dear Prof. Rubel and Wien2k community,

   Are you aware of this paperhttps://www.nature.com/articles/srep33914
?
   It is InP instead of GaP and does not use hybrids, but I hope it can be
useful in your research.
   All the best,
   Luis


2018-07-24 18:08 GMT-03:00 Oleg Rubel :

> Dear Wien2k Community,
>
> I am trying to get a band offset for a semiconductor heterostructure GaP
> wurtzite/zinc blende using 1S electron core states of Ga and P as a
> reference. Wurtzite and zinc blende phases are calculated separately using
> the following command:
> run_lapw -ec 0.1 -cc 0.0001  -hf -p
>
> When I look into the SCF file, I see alternating gaps (hybrid and PBE)
> which is normal according to the UG. Below is the output from a GaP-zb SCF
> file:
>
> [rubel@gra-login1 GaP-zb]$ grep -e :GAP -e :1S *scf
> 
> :GAP (global)   :  0.166773 Ry = 2.269 eV (accurate value if proper
> k-mesh)
> :GAP (global)   :  0.116847 Ry = 1.590 eV (accurate value if proper
> k-mesh)
> :1S 001: 1S-750.971786386 Ry
> :1S 002: 1S-152.344610161 Ry
> :GAP (global)   :  0.167674 Ry = 2.281 eV (accurate value if proper
> k-mesh)
> :GAP (global)   :  0.116729 Ry = 1.588 eV (accurate value if proper
> k-mesh)
> :1S 001: 1S-750.972092838 Ry
> :1S 002: 1S-152.343860783 Ry
> :GAP (global)   :  0.167731 Ry = 2.282 eV (accurate value if proper
> k-mesh)
>
> However, I do not see a second set of eigenvalues for core states. Those
> shown in SCF file are from PBE, if I am not mistaken. I wonder if core
> states are computed self-consistently using hybrids, where the
> corresponding eigenvalues can be found?
>
>
> Thank you in advance
> Oleg
>
> --
> Oleg Rubel (PhD, PEng)
> Department of Materials Science and Engineering
> McMaster University
> JHE 359, 1280 Main Street West, Hamilton, Ontario L8S 4L8, Canada
> 
> Email: rub...@mcmaster.ca
> Tel: +1-905-525-9140, ext. 24094
> Web: http://olegrubel.mcmaster.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/wi
> e...@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] Fwd: Phonon dispersion for wurtzite ZnO

[Luis Ogando]

Dear Wien2k community,

   Some days ago, I sent the the message below, but I got no answer.
   I would really appreciate if someone could take a look and point if some
parameter looks like inadequate. Obviously, I would thank any hint.
   Thank you again !
   All the best,
 Luis



-- Forwarded message --
From: Luis Ogando 
Date: 2018-06-05 12:19 GMT-03:00
Subject: Phonon dispersion for wurtzite ZnO
To: A Mailing list for WIEN2k users 


Dear Wien2k Community,

   I have no experience in calculating phonon dispersion, but I am trying
to calculate it using Wien2k 17.1 and Phonopy.
   I am getting "strange" results  for wurtzite ZnO and I would highly
appreciate your comments. Basically, I got a nice plot for the 2x2x2
supercell with negligible negative frequencies for the acoustic modes at
gamma. Trying to check convergence, I increased the supercell to 3x3x2, but
the negative frequencies became not negligible. The next step was to
increase the cell to 4x4x3 with more k-points, but the negative frequencies
are still there. Moreover, some of the optical modes look like not
converging.
   LO-TO splitting are not taken into account.
   Well, I will describe my steps and, please, give me some suggestions or
indicate the errors.

1) Structural optimization:
   1.1) I optimized the wurtzite ZnO cell using the "[5]  VARY A and C
(2D-case)" option.
   1.2) 3% of RMT reduction (1.65 for Zn and 1.42 for O)
   1.3) non-magnetic configuration
   1.4) LSDA
   1.5) Core/valence separation energy : -7.0 Ry (valence states for Zn: 3P
(local orbital), 3D and 4S // valence states for O: 2S (local orbital) and
2P)
   1.6) RKmax: 8.0 and 8.5 (convergence tests)
   1.7) K-grid :  (8 8 4) and (9 9 4) (convergence tests)
   1.8) Emax: 1.5 Ry (no SOC)
   1.9) Gmax: 14
   1.10) MSR1a
   1.11) tolf : 0.05 (case.inM)
   1.12) run_lapw -ec 0.0001 -cc 0.0001 -fc 0.01 -i 200

Results:
   Sigma ~ 1.7x10^{-3}
   Differences in optimized "a" and "c" for the two RKmax and K-grid sets ~
0.004%
   When optimizing "u" with the optimized "a" and "c", the residual forces
where lower than 3.2x10^{-3} mRy/Bohr

2) Supercell:
   2.1)0% of RMT reduction (1.97 for Zn and 1.69 for O)
   2.2) non-magnetic configuration
   2.3) LSDA
   2.4) Core/valence separation energy : -7.0 Ry (valence states for Zn: 3P
(local orbital), 3D and 4S // valence states for O: 2S (local orbital) and
2P)
   2.5) RKmax: 8.0
   2.6) K-grid : (4 4 2) for the 2x2x2 supercell
 (3 3 2) for the 3x3x2 supercell
 (4 4 2) for the 4x4x3 supercell (trying to check if
the k-grid plays a role)
   2.7) Emax: 1.5 Ry (no SOC)
   2.8) Gmax: 14
   2.9) run_lapw -p -it -ec 0.0001 -cc 0.0001 -fc 0.01 -i 200

=> All the K-grids had "no shift" !

   Finally, two questions:

1) When I built the P1 1x1x1 supercell, I simply separated the equivalent
atoms, preserving positions and the gamma angle equal to 120. Phonopy finds
the correct original space group. Is this the correct procedure ?

2) There is a paper where the authors (Prof. Blaha among them) calculate
the phonon dispersion for wurtzite ZnO using Wien93 (PRB 53, 11425 (1996)).
In this calculation, the 3P states for Zn are core states. Do you believe
that this is relevant ?

   I am sorry for the huge email !
   Thank you !
   All the best,
 Luis
___
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] Phonon dispersion for wurtzite ZnO

[Luis Ogando]

Dear Wien2k Community,

   I have no experience in calculating phonon dispersion, but I am trying
to calculate it using Wien2k 17.1 and Phonopy.
   I am getting "strange" results  for wurtzite ZnO and I would highly
appreciate your comments. Basically, I got a nice plot for the 2x2x2
supercell with negligible negative frequencies for the acoustic modes at
gamma. Trying to check convergence, I increased the supercell to 3x3x2, but
the negative frequencies became not negligible. The next step was to
increase the cell to 4x4x3 with more k-points, but the negative frequencies
are still there. Moreover, some of the optical modes look like not
converging.
   LO-TO splitting are not taken into account.
   Well, I will describe my steps and, please, give me some suggestions or
indicate the errors.

1) Structural optimization:
   1.1) I optimized the wurtzite ZnO cell using the "[5]  VARY A and C
(2D-case)" option.
   1.2) 3% of RMT reduction (1.65 for Zn and 1.42 for O)
   1.3) non-magnetic configuration
   1.4) LSDA
   1.5) Core/valence separation energy : -7.0 Ry (valence states for Zn: 3P
(local orbital), 3D and 4S // valence states for O: 2S (local orbital) and
2P)
   1.6) RKmax: 8.0 and 8.5 (convergence tests)
   1.7) K-grid :  (8 8 4) and (9 9 4) (convergence tests)
   1.8) Emax: 1.5 Ry (no SOC)
   1.9) Gmax: 14
   1.10) MSR1a
   1.11) tolf : 0.05 (case.inM)
   1.12) run_lapw -ec 0.0001 -cc 0.0001 -fc 0.01 -i 200

Results:
   Sigma ~ 1.7x10^{-3}
   Differences in optimized "a" and "c" for the two RKmax and K-grid sets ~
0.004%
   When optimizing "u" with the optimized "a" and "c", the residual forces
where lower than 3.2x10^{-3} mRy/Bohr

2) Supercell:
   2.1)0% of RMT reduction (1.97 for Zn and 1.69 for O)
   2.2) non-magnetic configuration
   2.3) LSDA
   2.4) Core/valence separation energy : -7.0 Ry (valence states for Zn: 3P
(local orbital), 3D and 4S // valence states for O: 2S (local orbital) and
2P)
   2.5) RKmax: 8.0
   2.6) K-grid : (4 4 2) for the 2x2x2 supercell
 (3 3 2) for the 3x3x2 supercell
 (4 4 2) for the 4x4x3 supercell (trying to check if
the k-grid plays a role)
   2.7) Emax: 1.5 Ry (no SOC)
   2.8) Gmax: 14
   2.9) run_lapw -p -it -ec 0.0001 -cc 0.0001 -fc 0.01 -i 200

=> All the K-grids had "no shift" !

   Finally, two questions:

1) When I built the P1 1x1x1 supercell, I simply separated the equivalent
atoms, preserving positions and the gamma angle equal to 120. Phonopy finds
the correct original space group. Is this the correct procedure ?

2) There is a paper where the authors (Prof. Blaha among them) calculate
the phonon dispersion for wurtzite ZnO using Wien93 (PRB 53, 11425 (1996)).
In this calculation, the 3P states for Zn are core states. Do you believe
that this is relevant ?

   I am sorry for the huge email !
   Thank you !
   All the best,
 Luis
___
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] Optimization convergence for phonon calculations.

[Luis Ogando]

Dear Prof. Blaha,

   Thank you very much!
   Luis

Em 26/01/2018 13:25, "Peter Blaha" <pbl...@theochem.tuwien.ac.at> escreveu:

> Yes, of course for phonon calculations you have first to optimize the
> structure. And for that, TOLF should be reduced, because for phonons you
> should start with a structure which has "zero" (typically 0.1 to 0.01)
> forces.
> tolf tells the code when to stop moving atoms.
> -fc xx  tells the code to stop the scf when forces are converged to xx mRy.
>
>
> On 01/26/2018 02:30 PM, Luis Ogando wrote:
>
>> Dear Wien2k community,
>>
>> I would like to calculate phonon dispersion in a wurtzite system.
>> What convergence values (-ec , -cc and -fc) do you suggest to perform the
>> structure optimization before the forces calculation in the distorted cells
>> ? And for these forces calculation ?
>>
>> Just a curiosity, when optimizing internal parameters with MSR1a,
>> does "tolf" (case.inM) have any effect ?
>> All the best,
>>  Luis
>>
>>
>>
>> ___
>> 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/wi
>> e...@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/wi
> e...@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] Optimization convergence for phonon calculations.

[Luis Ogando]

Dear Wien2k community,

   I would like to calculate phonon dispersion in a wurtzite system. What
convergence values (-ec , -cc and -fc) do you suggest to perform the
structure optimization before the forces calculation in the distorted cells
? And for these forces calculation ?

   Just a curiosity, when optimizing internal parameters with MSR1a, does
"tolf" (case.inM) have any effect ?
   All the best,
Luis
___
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] Intel compilers and MPI versions

[Luis Ogando]

Dear Gavin

   Thank you very much for your complete explanation.
   Best wishes,
  Luis


2017-11-23 3:15 GMT-02:00 Gavin Abo <gs...@crimson.ua.edu>:

> Students, Classroom Educators (Professors), and Open-Source Contributors
> might be able to get a free license for some Intel tools:
>
> https://software.intel.com/en-us/parallel-studio-xe/choose-download
>
> For WIEN2k, I believe commercial researchers have to buy a commercial
> license.  Professors doing research are paid a salary and student
> researchers are paid a stipend or are working on a funded research project
> typically, such that they usually have to buy an academic license:
> https://software.intel.com/en-us/articles/non-commercial-software-faq
> https://software.intel.com/en-us/articles/academic-pricing
>
> The old non-commerical license that was less restrictive on who could use
> it or what it could be used for was discontinued:
>
> https://software.intel.com/en-us/forums/intel-fortran-
> compiler-for-linux-and-mac-os-x/topic/533638
>
> For WIEN2k 17.1, if you use a ifort/mkl version older than update 2 of the
> 2013 composer xe, you need to patch the code to use the -Dold_scalapack
> switch:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16487.html
>
> However, it is recommend to use a ifort/mkl version newer than that, which
> uses the new pzheevr function.  This is because there were cases were the
> old Scalapack diagonalization failed:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16484.html
>
> You probably do NOT want to use the 16.0.3.210 version due to the serious
> bug that it has:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16520.html
>
> Some, or perhaps all, of the 2016 and 2017 versions are known to be
> problematic with large arrays and using -assume nobuffered_io may help
> resolve this:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16232.html
>
> There are known file IO problems with 2018, but there may be fixes in the
> mailings list for that:
>
> https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16589.html
>
> Depending on your Linux operating system version, you might want to check
> the Intel Release Notes to determine which version has matching support
> with the ifort/mkl version that you are using:
>
> https://software.intel.com/en-us/articles/intel-parallel-
> studio-xe-release-notes-and-new-features
> For example, the 2018 update 1 version of ifort/mkl has "4.3 Operating
> System Requirements":
>
> Debian* 8, 9
> Fedora* 25, 26
> Red Hat Enterprise Linux* 6, 7 (equivalent CentOS versions supported, but
> not separately tested)
> SUSE Linux Enterprise Server* 11, 12
> Ubuntu* 14.04, 16.04, 17.04
> macOS* 10.12, 10.13
>
> Sorry, I currently don't know which of the 2016/2017/2018 ifort/mkl
> versions are more stable with WIEN2k.  So you would have to do your own
> testing.
>
> On 11/22/2017 10:14 AM, Luis Ogando wrote:
>
>¡ Gracias Pablo !
>I hope do not find any problem with the last version.
>Thank you again,
> Luis
>
> 2017-11-22 15:07 GMT-02:00 delamora <delam...@unam.mx>:
>
>> Estimado Luis,
>> You need a recent compiler for the WIEN2k 17.1
>> As researcher you can get a free licence
>>
>> NaCl U2
>>
>> Pablo
>> --
>> *De:* Wien <wien-boun...@zeus.theochem.tuwien.ac.at> en nombre de Luis
>> Ogando <lcoda...@gmail.com>
>> *Enviado:* miércoles, 22 de noviembre de 2017 05:02:54 a. m.
>> *Para:* A Mailing list for WIEN2k users
>> *Asunto:* [Wien] Intel compilers and MPI versions
>>
>> Dear Wien2k community,
>>
>>Greetings !
>>Is there a recommended version of the Intel compilers and MPI to use
>> with Wien2k ?
>>Thank you !
>>Best wishes,
>>Luis
>>
>
> ___
> 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] Intel compilers and MPI versions

[Luis Ogando]

   ¡ Gracias Pablo !
   I hope do not find any problem with the last version.
   Thank you again,
Luis

2017-11-22 15:07 GMT-02:00 delamora <delam...@unam.mx>:

> Estimado Luis,
> You need a recent compiler for the WIEN2k 17.1
> As researcher you can get a free licence
>
> NaCl U2
>
> Pablo
> --
> *De:* Wien <wien-boun...@zeus.theochem.tuwien.ac.at> en nombre de Luis
> Ogando <lcoda...@gmail.com>
> *Enviado:* miércoles, 22 de noviembre de 2017 05:02:54 a. m.
> *Para:* A Mailing list for WIEN2k users
> *Asunto:* [Wien] Intel compilers and MPI versions
>
> Dear Wien2k community,
>
>Greetings !
>Is there a recommended version of the Intel compilers and MPI to use
> with Wien2k ?
>Thank you !
>Best wishes,
>Luis
>
>
>
> ___
> 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] Intel compilers and MPI versions

[Luis Ogando]

Dear Wien2k community,

   Greetings !
   Is there a recommended version of the Intel compilers and MPI to use
with Wien2k ?
   Thank you !
   Best wishes,
   Luis
___
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] LAPW2: semicore band-ranges too large

[Luis Ogando]

Dear Prof. Blaha,

   Thank you again !
   I have 3 k-points and each k-point gives rise to an MPI calculation with
9 processors. I believe that LAPW1 results are written in case.scf1_1,
case.scf1_2 and case.scf1_3 for each k-point and after each iteration,
these files are added to case.scf and "cleaned".
   For some reason, only the Gamma point results are present in case.scf.
Anyway, I could notice that  the lowest Gamma eigenvalues have an abrupt
change in the last iteration what probably caused the calculation
interruption (iqtlsave=1).
   I will increase the effective RKmax to 3.0, following your
recommendation and hoping that this can solve the problem.
   Thank you for your help.
   All the best,
   Luis


2017-09-28 9:42 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> For sure the effective RKmax=2.37 is too small.
>
> You will have to go mpi-parallel.
>
> Otherwise, check your eigenvalues at the different k-points.
>
> With only C,N,H you can identify each eigenvalue and of course the low
> lying eigenvalues should change very little for different k-points ...
>
> On 09/27/2017 08:18 PM, Luis Ogando wrote:
>
>> Dear Prof. Blaha,
>>
>>Thank you very much for your help !
>>Do not worry ! I removed only the l=0 lo orbitals for C. The   "
>> 0   -0.70  0.002 CONT 1   " lines were preserved.
>>Yes, I used RKmax=3.0 , but it was reduced to  RKM= 2.37  due to
>> NMATMAX. Do you believe that this can be related to the "effective"
>> RKmax value ? I can increase NMATMAX, recompile LAPW1 and try again, but
>> I would like your opinion before starting such a time consuming
>> calculation.
>>During optimization, when Gamma was the only k-point, I tested the
>> basis size through an SCF cycle (MSR1) with an intermediary structure
>> *and iqtlsave = 1.* In that case, the effective RKmax was 2.38 and the
>> calculation converged without a problem, but the RMT's were smaller than
>> now (0.98 (C), 1.18 (N) and 0.64 (H)).
>>Is there any other parameter that you would like to know ?
>>Thank you again.
>>All the best,
>>  Luis
>>
>> 2017-09-27 1:49 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at
>> <mailto:pbl...@theochem.tuwien.ac.at>>:
>>
>>
>> As I said, iqtlsave should ONLY be used in very special cases (high
>> pressure). It usually is a hint for ghostbands and one should not
>> switch it of.
>>
>> I don't think the problems come from a not optimized structure,
>> except when the positions would be extremely wrong.
>>
>> The RMTs are probably ok.
>>
>> When I say, you should remove the lo for C, l=0, I meant to remove
>> the line with l=0 and 0.30 as energy parameter, but keep the line
>> with -0.7xx.
>>
>> PS: I hope you reduced RKMax to 3 (or for the beginning to save time
>> during crude position optimization even 2.75)
>>
>> Am 26.09.2017 um 19:31 schrieb Luis Ogando:
>>
>> Dear Prof. Blaha,
>>
>> Thank you very much for your response !
>> The molecule has 100 atoms and the only symmetry operation
>> is identity. You can imagine the computation time required for
>> optimization. I turned "iqtlsave" off during optimization in
>> order to avoid interruption due to fortuitous atom displacement.
>> Anyway, after getting the relaxed structure, I turned it on
>> again (and got the problem).
>> The RMT's I am using are 1.25 (C), 1.24 (N) and 0.67 (H).
>> These values were suggested by init_lapw.
>> As you previewed, l=0 local orbitals for C are problematic
>> and I removed them during optimization. I also removed the l=0
>> local orbitals for N and kept the same basis set for the next
>> calculations, with the optimized structure.
>> I believe that it is important to say that I got the error
>> message on the SCF cycle number 25 after energy convergence on
>> cycle 23 (-ec 0.0001 -cc 0.0001). During optimization I used
>> "-ec 0.001 -cc 0.001 -fc 1.0"  . Do you believe that the problem
>> can be related to a "non" fully relaxed structure ?
>> Thank you again !
>> All the best,
>>  Luis
>>
>>
>> 2017-09-25 16:57 GMT-03:00 Peter Blaha
>> <pbl...@theochem.tuwien.ac.at
>> <mailto:pbl...@theochem.tuwien.ac.at>
>>  

Re: [Wien] LAPW2: semicore band-ranges too large

[Luis Ogando]

Dear Prof. Blaha,

   Thank you very much for your help !
   Do not worry ! I removed only the l=0 lo orbitals for C. The   "   0
-0.70  0.002 CONT 1   " lines were preserved.
   Yes, I used RKmax=3.0 , but it was reduced to  RKM= 2.37  due to
NMATMAX. Do you believe that this can be related to the "effective" RKmax
value ? I can increase NMATMAX, recompile LAPW1 and try again, but I would
like your opinion before starting such a time consuming calculation.
   During optimization, when Gamma was the only k-point, I tested the basis
size through an SCF cycle (MSR1) with an intermediary structure *and
iqtlsave = 1.* In that case, the effective RKmax was 2.38 and the
calculation converged without a problem, but the RMT's were smaller than
now (0.98 (C), 1.18 (N) and 0.64 (H)).
   Is there any other parameter that you would like to know ?
   Thank you again.
   All the best,
 Luis

2017-09-27 1:49 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> As I said, iqtlsave should ONLY be used in very special cases (high
> pressure). It usually is a hint for ghostbands and one should not switch it
> of.
>
> I don't think the problems come from a not optimized structure, except
> when the positions would be extremely wrong.
>
> The RMTs are probably ok.
>
> When I say, you should remove the lo for C, l=0, I meant to remove the
> line with l=0 and 0.30 as energy parameter, but keep the line with -0.7xx.
>
> PS: I hope you reduced RKMax to 3 (or for the beginning to save time
> during crude position optimization even 2.75)
>
> Am 26.09.2017 um 19:31 schrieb Luis Ogando:
>
>> Dear Prof. Blaha,
>>
>> Thank you very much for your response !
>> The molecule has 100 atoms and the only symmetry operation is
>> identity. You can imagine the computation time required for optimization. I
>> turned "iqtlsave" off during optimization in order to avoid interruption
>> due to fortuitous atom displacement. Anyway, after getting the relaxed
>> structure, I turned it on again (and got the problem).
>> The RMT's I am using are 1.25 (C), 1.24 (N) and 0.67 (H). These
>> values were suggested by init_lapw.
>> As you previewed, l=0 local orbitals for C are problematic and I
>> removed them during optimization. I also removed the l=0 local orbitals for
>> N and kept the same basis set for the next calculations, with the optimized
>> structure.
>> I believe that it is important to say that I got the error message on
>> the SCF cycle number 25 after energy convergence on cycle 23 (-ec 0.0001
>> -cc 0.0001). During optimization I used  "-ec 0.001 -cc 0.001 -fc 1.0"  .
>> Do you believe that the problem can be related to a "non" fully relaxed
>> structure ?
>> Thank you again !
>> All the best,
>>  Luis
>>
>>
>> 2017-09-25 16:57 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at
>> <mailto:pbl...@theochem.tuwien.ac.at>>:
>>
>> Yes, worry !!
>>
>> Why did you change iqtlsave in the first place ? It is not sace and
>> ment only for special cases like very large pressure.
>>
>> I guess you had spurious ghost bands and most likely the problems
>> come form the small C sphere and the l=0 LO on Carbon.
>> Remove the C l=0 local orbital.
>>
>>
>> Am 25.09.2017 um 20:56 schrieb Luis Ogando:
>>
>> Dear Wien2k community,
>>
>>  My system is a molecule (H, C and N) with vacuum along "y"
>> and "z".
>>  After optimizing the structure using only the Gamma point
>> (large cell) and iqtlsave = 0, I am trying to get the DOS using
>> more k-points.
>>  To do this, I turned iqtlsave on (iqtlsave=1) and I am
>> getting the message "LAPW2: semicore band-ranges too large".
>> Should I worry about this ?
>>  Thank you very much.
>>  All the best,
>>   Luis
>>
>>
>>
>>
>> ___
>> 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
>> <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
>>

[Wien] LAPW2: semicore band-ranges too large

[Luis Ogando]

Dear Wien2k community,

   My system is a molecule (H, C and N) with vacuum along "y" and "z".
   After optimizing the structure using only the Gamma point (large cell)
and iqtlsave = 0, I am trying to get the DOS using more k-points.
   To do this, I turned iqtlsave on (iqtlsave=1) and I am getting the
message "LAPW2: semicore band-ranges too large". Should I worry about this ?
   Thank you very much.
   All the best,
Luis
___
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] Quick question about convergence criteria

[Luis Ogando]

   Thank you Oleg !
   All the best,
Luis


2017-09-12 9:47 GMT-03:00 Rubel, Oleg <rub...@mcmaster.ca>:

> Usually forces are most difficult to converge. I bet that by the time
> forces are converged within 1 mRy/Bohr your energy and charge are converged
> much better than your initial request.
>
> Oleg
>
> > On Sep 12, 2017, at 08:03, Luis Ogando <lcoda...@gmail.com> wrote:
> >
> > Dear Wien2k community,
> >
> >My system is a molecule (periodic along x and vacuum along y an z).
> >The structural optimization took a long time due to the small atoms
> soft modes (N, C and H). In order to avoid that the optimization lasts for
> ever, I used the following convergence criteria:
> >
> > -ec 0.001 -cc 0.001 -fc 1.0
> >
> >I would like to know if you consider that this convergence is
> acceptable.
> >Thank you for your attention.
> >All the best,
> > Luis
> >
> > ___
> > 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] Charge convergence

[Luis Ogando]

Dear Prof. Marks, Blaha and Dobysheva,

   First of all, thank you very much for your comments.

*Dear Prof. Marks:*

1) The warning message is related to

WARNING: RKmax reduced due to NMATMAX

but I am aware of this. No reasons to worry about.

2) My system is a molecule (as pointed by Prof. Blaha) with 60 C atoms, 5 N
atoms and 35 H atoms. The cell has vacuum along two of the three directions.
   I believe that the large changes in atomic positions are related to
rotations of the H bonds (is there a way to check it ?). It may explain the
"significant" changes in :DIS without disturbing the energy. Do you believe
that this can also explain the small GREED value ?  MSR1a certainly found
soft modes.


*Dear Prof. Blaha:*
1) I thought that once the -cc and -ec criteria are fulfilled, the
optimization process stops changing the structure. Now I know that the stop
criterium is more complex than this (obviously, the forces have to be taken
into account in a minimization process)


*Dear Prof. Dobysheva:*
1) Thank you for your clarification. It will be useful.

   All the best,
 Luis



2017-07-12 7:35 GMT-03:00 Lyudmila Dobysheva <lyuk...@mail.ru>:

> 11.07.2017 23:31, Luis Ogando wrote:
>
>> :DIS  :  CHARGE DISTANCE   ( 0.0014560 for atom   33 spin 1)
>> :DIS  :  CHARGE DISTANCE   ( 0.0014130 for atom   33 spin 1)
>>  >> On Tue, Jul 11, 2017 at 9:40 AM, Luis Ogando wrote:
>>
>>> The energy is finally converged, but the charge is not despite the
>>>>> fact that its change is below the limit in the last 10 iterations.
>>>>>
>>>> ...
>
>> > CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004560
>>>> > CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004130
>>>>
>>>>> If I am not wrong, the convergence is achieved after 3 consecutive
>>>>> iterations with changes below the limit, but in my case this is
>>>>> happening for more than 10 iterations  without convergence.
>>>>>
>>>> A very small addition: dayfile prints here not :DIS, but :DIS minus
> 0.001
> So, these lines show that the criterium ":DIS smaller than 0.001" is not
> fulfilled yet, the convergence is achieved when negative values appear here
> three times.
>
> Best wishes
>   Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 432459(office), 722529(Fax)
> E-mail: l...@ftiudm.ru, lyuk...@mail.ru (office)
> lyuk...@gmail.com (home)
> Skype:  lyuka17 (home), lyuka18 (office)
> http://ftiudm.ru/content/view/25/103/lang,english/
> --
>
___
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 convergence

[Luis Ogando]

Dear Prof. Marks,

   Here is the output :

:DIRP :  |MSR1a|= 1.353E-02 |PRATT|= 1.465E-02 ANGLE=  79.7 DEGREES
:DIRQ :  |MSR1a|= 1.677E-03 |PRATT|= 1.281E-02 ANGLE=  93.1 DEGREES
:DIR  :  |MSR1a|= 1.364E-02 |PRATT|= 1.946E-02 ANGLE=  82.6 DEGREES
:FRMSA:  (mRyd/au)0.6390.737 RMS (au) 7.37E-04 MAX 1.49E-03
:F-condition (mRyd/au)2.000 T
:MIX  :   MSD1a  REGULARIZATION: 5.25E-06  GREED: 0.022  Newton 1.00
0.85
:ENE  : *WARNING** TOTAL ENERGY IN Ry =-5118.71234888
:DIS  :  CHARGE DISTANCE   ( 0.0015217 for atom   33 spin 1)
0.0002284
:PLANE:  INTERSTITIAL TOTAL  6.45327 DISTAN  5.045E-02 %
:CHARG:  CLM CHARGE   /ATOM  1.55937 DISTAN  9.661E-03 %
:DIRM :  MEMORY  8/8 RESCALES   4.81  1.88 RED 1.079 PRED 0.834 NEXT 0.819
:DIRA :  |MSR1a|= 2.749E-02 |PRATT|= 1.207E-02 ANGLE=  96.4 DEGREES
:DIRP :  |MSR1a|= 2.675E-02 |PRATT|= 1.567E-02 ANGLE=  77.8 DEGREES
:DIRQ :  |MSR1a|= 3.360E-03 |PRATT|= 1.506E-02 ANGLE=  92.1 DEGREES
:DIR  :  |MSR1a|= 2.696E-02 |PRATT|= 2.174E-02 ANGLE=  81.5 DEGREES
:FRMSA:  (mRyd/au)0.6430.748 RMS (au) 1.47E-03 MAX 2.96E-03
:F-condition (mRyd/au)2.000 F
:MIX  :   MSD1a  REGULARIZATION: 4.91E-06  GREED: 0.022  LMStep 0.28  1.55
Step
:ENE  : *WARNING** TOTAL ENERGY IN Ry =-5118.71254328
:DIS  :  CHARGE DISTANCE   ( 0.0012525 for atom   33 spin 1)
0.0001933
:PLANE:  INTERSTITIAL TOTAL  6.45329 DISTAN  4.818E-02 %
:CHARG:  CLM CHARGE   /ATOM  1.55937 DISTAN  8.128E-03 %
:DIRM :  MEMORY  8/8 RESCALES   4.58  1.76 RED 0.928 PRED 0.819 NEXT 0.834
:DIRA :  |MSR1a|= 2.089E-02 |PRATT|= 1.112E-02 ANGLE=  92.0 DEGREES
:DIRP :  |MSR1a|= 2.058E-02 |PRATT|= 1.423E-02 ANGLE=  79.0 DEGREES
:DIRQ :  |MSR1a|= 2.808E-03 |PRATT|= 1.267E-02 ANGLE= 102.2 DEGREES
:DIR  :  |MSR1a|= 2.077E-02 |PRATT|= 1.906E-02 ANGLE=  83.0 DEGREES
:FRMSA:  (mRyd/au)0.6310.728 RMS (au) 1.18E-03 MAX 2.35E-03
:F-condition (mRyd/au)2.000 F
:MIX  :   MSD1a  REGULARIZATION: 4.63E-06  GREED: 0.022  LMStep 0.56  1.34
Step
:ENE  : *WARNING** TOTAL ENERGY IN Ry =-5118.71277695
:DIS  :  CHARGE DISTANCE   ( 0.0014560 for atom   33 spin 1)
0.0002067
:PLANE:  INTERSTITIAL TOTAL  6.45332 DISTAN  4.941E-02 %
:CHARG:  CLM CHARGE   /ATOM  1.55937 DISTAN  8.675E-03 %
:DIRM :  MEMORY  8/8 RESCALES   4.36  1.65 RED 1.036 PRED 0.834 NEXT 0.799
:DIRA :  |MSR1a|= 2.054E-02 |PRATT|= 1.072E-02 ANGLE=  94.5 DEGREES
:DIRP :  |MSR1a|= 2.057E-02 |PRATT|= 1.391E-02 ANGLE=  77.1 DEGREES
:DIRQ :  |MSR1a|= 2.854E-03 |PRATT|= 1.353E-02 ANGLE=  96.6 DEGREES
:DIR  :  |MSR1a|= 2.077E-02 |PRATT|= 1.941E-02 ANGLE=  81.5 DEGREES
:FRMSA:  (mRyd/au)0.6480.755 RMS (au) 1.24E-03 MAX 2.48E-03
:F-condition (mRyd/au)2.000 F
:MIX  :   MSD1a  REGULARIZATION: 3.58E-06  GREED: 0.022  LMStep 0.62  1.32
Step
:ENE  : *WARNING** TOTAL ENERGY IN Ry =-5118.71298286
:DIS  :  CHARGE DISTANCE   ( 0.0014130 for atom   33 spin 1)
0.0002016
:PLANE:  INTERSTITIAL TOTAL  6.45336 DISTAN  4.946E-02 %
:CHARG:  CLM CHARGE   /ATOM  1.55937 DISTAN  8.530E-03 %
:DIRM :  MEMORY  8/8 RESCALES   4.48  1.73 RED 0.998 PRED 0.799 NEXT 0.819
:DIRA :  |MSR1a|= 2.041E-02 |PRATT|= 1.138E-02 ANGLE=  91.9 DEGREES
:DIRP :  |MSR1a|= 2.005E-02 |PRATT|= 1.431E-02 ANGLE=  75.4 DEGREES
:DIRQ :  |MSR1a|= 2.692E-03 |PRATT|= 1.330E-02 ANGLE=  91.6 DEGREES
:DIR  :  |MSR1a|= 2.023E-02 |PRATT|= 1.954E-02 ANGLE=  79.6 DEGREES
:FRMSA:  (mRyd/au)0.6580.762 RMS (au) 1.18E-03 MAX 2.38E-03
:F-condition (mRyd/au)2.000 F
:MIX  :   MSD1a  REGULARIZATION: 3.72E-06  GREED: 0.022  LMStep 0.72  1.27
Step
:ENE  : *WARNING** TOTAL ENERGY IN Ry =-5118.71317174

   Any suggestion or just wait a little ?
   Thank you !
   All the best,
   Luis

2017-07-11 16:20 GMT-03:00 Laurence Marks <l-ma...@northwestern.edu>:

> tail -n 20 *.scf $1 | grep -e :ADIST -e :DIR -e :MV -e GREED -e
> :FRMS -e :ENE -e :CHARG -e PRATT \
> -e :DIS -e "MIXING SC" -e ":RANK" -e PLANE | \
> grep -v -e "with 1.0" -e scheme -e CONTRIBUTION | \
> tail -n 50
>
> On Tue, Jul 11, 2017 at 1:20 PM, Luis Ogando <lcoda...@gmail.com> wrote:
> > Dear Prof. Marks,
> >
> >Thank you very much for your explanation.
> >Unfortunatelly, I am stil using Wien2k 14.2, without the "Check"
> command.
> >Anyway, I can wait for the charge convergence (for a while). If it
> takes
> > too long and nothing bad happens, I will "kill" the optimization.
> >Thank you again.
> > All the best,
> >  Luis
> >
> >
> > 2017-07-11 13:13 GMT-03:00 Laurence Marks <l-ma...@northwestern.edu>:
> >>
> >> It is possible for :ENE (Energy, -ec) to seem to converge, but has not
> >> -- so it is always wise IMO to also use the charge converge (:DIS,
> >> -cc). A value of .0004130 is probabl

[Wien] Charge convergence

[Luis Ogando]

Dear Prof. Marks and Wien2k community,

   Good afternoon !
   Just a curiosity about the charge convergence criteria. I am optimizing
a supercell and the charge convergence limit I am using is 0.001. The same
numerical value for the energy convergence.
   The energy is finally converged, but the charge is not despite the fact
that its change is below the limit in the last 10 iterations.

CarbazoleLDAopt.dayfile::CHARGE convergence:  1 0.001 -.0002028
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0006007
CarbazoleLDAopt.dayfile::CHARGE convergence:  1 0.001 -.0002590
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0007240
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0008640
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0005344
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0005217
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0002525
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004560
CarbazoleLDAopt.dayfile::CHARGE convergence:  0 0.001 .0004130

   If I am not wrong, the convergence is achieved after 3 consecutive
iterations with changes below the limit, but in my case this is happening
for more than 10 iterations  without convergence.
   Could you please kindly explain what may be happening ?
   Thank you !
Luis
___
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] Restarting HF with SO

[Luis Ogando]

Dear Prof. Marks and Prof. Tran,

   I would like to thank you very much for your help.
   I have implemented Prof. Tran's suggestion. Let's cross the fingers and
see what happens.
   Thank you again !
   All the best,
  Luis

2017-05-19 5:57 GMT-03:00 <t...@theochem.tuwien.ac.at>:

> Hi,
>
> Try eventually that:
> -save the calculation (save_lapw some_name) and rename
> GaPwurtHSE-DielSO-1.vectorhf_old as some_name.vectorhf
> -create a new fresh directory where you copy the files some_name.*
> -restore the calculation (restore -f some_name)
> -restart the calculation
>
> But I'm afraid that it won't work if case.energyhf is not complete.
>
> FT
>
> On Thursday 2017-05-18 13:29, Luis Ogando wrote:
>
> Date: Thu, 18 May 2017 13:29:42
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <w...@zeus.theochem.tuwien.ac.
>> at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] Restarting HF with SO
>>
>>
>> Dear Wien2k community,
>>
>>I am trying to calculate the dielectric function for wurtzite GaP
>> using -hf and -so as previously discussed (
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14603.html
>> ).
>>There was a shut down of the machine during the  hf  execution in the
>> first step of the calculation  (  run_lapw -hf ...  ). When the machine
>> came back, I removed the case.vectorhf (case.vectorhf_old is still there)
>> and case.energyhf.  Then, I executed
>>
>> run_lapw -hf -NI -s hf -ec 0.0001 -cc 0.0001 -i 200
>>
>> trying to restart the calculation (non-parallel execution due to the HF x
>> SO issue discussed in the previous messages above).
>>The calculation restarted without a problem, but when the the
>> case.vectorhf reached 187MB (less than a half of the expected size, see
>> below) I got an error.
>>
>> -rw-r--r-- 1 luisoda luisoda 187M Mai 18 03:51 GaPwurtHSE-DielSO-1.vector
>> -rw-r--r-- 1 luisoda luisoda 187M Mai 18 00:14
>> GaPwurtHSE-DielSO-1.vectorhf
>> -rw-r--r-- 1 luisoda luisoda 565M Abr 23 21:33
>> GaPwurtHSE-DielSO-1.vectorhf_old
>>
>>The only related error message I found it was:
>>
>> error in calc_h: info not equal to 0
>>
>>I am probably making a mistake when restarting the calculation and I
>> would really appreciate any help with this issue.
>>Many thanks in advance.
>>All the best,
>>  Luis
>>
>>
>>
> ___
> 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] Restarting HF with SO

[Luis Ogando]

Dear Prof. Marks,

   Thank you very much for your help !
   Unfortunately, I would like to understand why the  -s  option, designed
to restart a calculation at the same point where it crashed, does not work.
Without this, I am afraid that even your suggestion will not help.
   Thank you again,
   Luis


2017-05-18 14:39 GMT-03:00 Laurence Marks <l-ma...@northwestern.edu>:

> I don't have the answer, but you may want to contemplate in the future
> doing something like a set of shorter runs saving the interim results
>
> for i in 1 2 3 4 ... XX
> do
>   mkdir Safety
>   runsp_lapw -hf ... -i 3 -NI
>   rm Safety/*bro*
>   mv *bro* Safety
>   save -f -d Safety
>   cp Safety/*bro* ./ ; cp Safety/*.scf ./
> done
>
> (It would be easier if save_lapw had an option to not delete the *bro*
> files and retain case.scf -- a simple hack.)
>
> On Thu, May 18, 2017 at 12:27 PM, Luis Ogando <lcoda...@gmail.com> wrote:
> > Dear Gavin,
> >
> >Thank you very much for your answer.
> >I am using Wien2k 14.2 and, unfortunately, that was the only message I
> > got from the standard output file (queuing system). The error files and
> > case.dayfile have no useful information.
> >The interruption was during the  hf  execution, after lapw1, that
> > finished without a problem.
> >It was not the first time I had to restart the calculation due to a
> shut
> > down. In the other cases, I restarted the calculation from scratch, but,
> > with a non parallel calculation, I have to solve this reinitialization
> issue
> > or the calculation will never end. So, I would be glad if someone else
> could
> > give me another hint.
> >Thank you again.
> >All the best,
> >  Luis
> >
> >
> >
> >
> > 2017-05-18 11:35 GMT-03:00 Gavin Abo <gs...@crimson.ua.edu>:
> >>
> >> Sorry, those code line numbers are for WIEN2k 16.1.  For example, if you
> >> are using WIEN2k 14.2, the line numbers should be 998 instead of 1354
> and
> >> 1006 instead of 1365 in SRC_hf/calc_h.F.
> >>
> >>
> >> On 5/18/2017 8:19 AM, Gavin Abo wrote:
> >>
> >> Unfortunately, I think that error message can tell you "why" the
> >> calculation stopped, but it might not tell you the initial "cause" of
> it.
> >> That is likely because the issue that caused it happened earlier in the
> >> calculation (perhaps lapw1?).  The vector file size is smaller than the
> >> vectorhf_old.  I'm not sure if they should be the same size or not.  If
> so,
> >> perhaps you need to restart the calculation in the lapw1 step (-s
> lapw1) to
> >> regenerate the vector file instead of starting with the hf step (-s hf),
> >> which I believe comes later in the calculation from that of lapw1, or
> you
> >> might just have to start the calculation over from scratch.
> >>
> >> In SRC_hf/calc_h_2.F, you should see:
> >>
> >> line 1354:
> >> !_COMPLEX call
> >> zheev('V','U',nbf,ham,nbf,enknew,workdiag,2*nbf-1,rworkdiag,info)
> >>
> >> line 1365:
> >> if (info .ne. 0) then
> >>   print *, 'info=', info
> >>   stop 'error in calc_h_2: info not equal to 0'
> >> endif
> >>
> >> From the code above, you can see that there likely should be a little
> more
> >> error information available from the "print *, 'info=', info" statement
> that
> >> you did not report.  I believe this should have been printed to the
> standard
> >> output (terminal or std output file if you are using a queuing system).
> >>
> >> Depending on the value of the info variable, the calculation seems to
> have
> >> stopped because it encountered an illegal value or there was a
> convergence
> >> problem [1]:
> >>
> >> INFO is INTEGER
> >>   = 0:  successful exit
> >>   < 0:  if INFO = -i, the i-th argument had an illegal value
> >>   > 0:  if INFO = i, the algorithm failed to converge; i
> >>         off-diagonal elements of an intermediate tridiagonal
> >> form did not converge to zero.
> >>
> >> Perhaps, the software developers of the hf code have further insight
> than
> >> I currently do into what could resolve the problem.
> >>
> >> [1]
> >> http://www.netlib.org/lapack/explore-html/df/d9a/group__
> complex16_h_eeigen_ga70c041fd19635ff621cfd5d804bd7a30.html#
> ga70c

Re: [Wien] Restarting HF with SO

[Luis Ogando]

   I do not know if it is relevant, but my calculation is complex (-c).
   Thank you again,
Luis


2017-05-18 8:29 GMT-03:00 Luis Ogando <lcoda...@gmail.com>:

> Dear Wien2k community,
>
>I am trying to calculate the dielectric function for wurtzite GaP using
> -hf and -so as previously discussed (  http://www.mail-archive.com/
> wien@zeus.theochem.tuwien.ac.at/msg14603.html  ).
>There was a shut down of the machine during the  hf  execution in the
> first step of the calculation  (  run_lapw -hf ...  ). When the machine
> came back, I removed the case.vectorhf (case.vectorhf_old is still there)
> and case.energyhf.  Then, I executed
>
> run_lapw -hf -NI -s hf -ec 0.0001 -cc 0.0001 -i 200
>
> trying to restart the calculation (non-parallel execution due to the HF x
> SO issue discussed in the previous messages above).
>The calculation restarted without a problem, but when the the
> case.vectorhf reached 187MB (less than a half of the expected size, see
> below) I got an error.
>
> -rw-r--r-- 1 luisoda luisoda 187M Mai 18 03:51 GaPwurtHSE-DielSO-1.vector
> -rw-r--r-- 1 luisoda luisoda 187M Mai 18 00:14 GaPwurtHSE-DielSO-1.vectorhf
> -rw-r--r-- 1 luisoda luisoda 565M Abr 23 21:33
> GaPwurtHSE-DielSO-1.vectorhf_old
>
>The only related error message I found it was:
>
> error in calc_h: info not equal to 0
>
>I am probably making a mistake when restarting the calculation and I
> would really appreciate any help with this issue.
>Many thanks in advance.
>All the best,
>  Luis
>
>
___
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] Restarting HF with SO

[Luis Ogando]

Dear Wien2k community,

   I am trying to calculate the dielectric function for wurtzite GaP using
-hf and -so as previously discussed (
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14603.html
).
   There was a shut down of the machine during the  hf  execution in the
first step of the calculation  (  run_lapw -hf ...  ). When the machine
came back, I removed the case.vectorhf (case.vectorhf_old is still there)
and case.energyhf.  Then, I executed

run_lapw -hf -NI -s hf -ec 0.0001 -cc 0.0001 -i 200

trying to restart the calculation (non-parallel execution due to the HF x
SO issue discussed in the previous messages above).
   The calculation restarted without a problem, but when the the
case.vectorhf reached 187MB (less than a half of the expected size, see
below) I got an error.

-rw-r--r-- 1 luisoda luisoda 187M Mai 18 03:51 GaPwurtHSE-DielSO-1.vector
-rw-r--r-- 1 luisoda luisoda 187M Mai 18 00:14 GaPwurtHSE-DielSO-1.vectorhf
-rw-r--r-- 1 luisoda luisoda 565M Abr 23 21:33
GaPwurtHSE-DielSO-1.vectorhf_old

   The only related error message I found it was:

error in calc_h: info not equal to 0

   I am probably making a mistake when restarting the calculation and I
would really appreciate any help with this issue.
   Many thanks in advance.
   All the best,
 Luis
___
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] Effective mass

[Luis Ogando]

Hi Fatima,

   Trying different numbers of points around H means that you will be
changing the delta_K you take to fit the parabola.
   Besides this, you must also try a band structure with more K_points. Fix
the delta_K and see how the effective mass changes with the number of
points inside the range. As I said, choosing the suitable delta_K and its
number of points may be a hard task.
   Keep in mind that fitting three points will give you a perfect but
probably meaningless parabola.
   Good luck,
  Luis
___
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] Effective madd

[Luis Ogando]

Hi Fatima,

   The effective mass approximation works near the band extrema (maxima and
minima). You have to choose some points around them and fit the parabola.
Try different number of points (distances from the maximum or minimum) and
check the consistency of the calculated effective mass.
   Some times, it is hard to get this consistency. Experimental values may
help (if they exist).
   All the best,
Luis


2017-05-03 7:37 GMT-03:00 fatima DFT :

> Dear Wien2k Users,
> From the band structure attached in below link I can calculate the
> electron effective mass using parabola fitting but I do not know how to
> calculate the hole effective mass as the shape of the VBM is not parabolic.
> I wonder if someone from the mailing list could help me.
>
> https://sites.google.com/site/dftfatima5/letter/mailing-
> list-queries/pbe_R.bands.agr?attredirects=0=1
>
> Warm Regards
> Fatima
>
> ___
> 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] my membership to the mailing list gets disabled every 3 weeks

[Luis Ogando]

Dear Prof. Blaha,

   Unfortunately, I am facing the same problem described by Dr. Fabiana Da
Pieve.
   Please, let me know if I can do anything to help.
   All the best,
  Luis


2017-01-30 13:34 GMT-02:00 Peter Blaha :

> I've nothing changed recently in the mailing list configuration, so I
> don't know why this should now happen (except when your mail system has
> changed e.g spam-processing, ...)
>
> It probably comes from   bounce processing, i.e. mailman cannot send to
> your email addresses and gets a bounce back. After 5 (or 10 days if it is a
> soft bounce) it will disable your membership and just before, it will send
> you a warning.
>
> It may have to do with your specific email accounts ? maybe they think it
> is spam ... ?
>
> Of course, I can increase the bounce level from 5 (up to 10), but for sure
> I want to keep it, otherwise mailman will keep outdated addresses forever
> and continues to send mails to them.
>
> Regards
>
> Am 30.01.2017 um 09:26 schrieb Fabiana Da Pieve:
>
>> Dear Wien2k developers
>>
>> I am a pretty silent user of Wien2k since many years and I always read
>> with pleasure the emails of the different users, which sometimes are
>> also useful for me.
>>
>> However, in the last period I get very often (every 3 weeks) an email to
>> confirm my membership to the mailing list, and if I do not do it soon my
>> membership is cancelled the very same day.
>>
>> I do not think this is normal. Or is it ?
>> In any case, before it was not the case. Is there something I can do to
>> avoid this ?
>>
>> Thank you very much for your attention
>> Fabiana Da Pieve
>>
>>
>>
>>
>> ___
>> 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/wi
>> e...@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/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/wi
> e...@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] How to speed up a reliable optimization

[Luis Ogando]

Thank you once more !!
   Luis


2017-01-26 11:41 GMT-02:00 Laurence Marks <l-ma...@northwestern.edu>:

> N.B., the latest release has some additional controls that allow for a bit
> more control of the trust region, e.g. a maximum size. These are in the
> README, they are not in the user guide. They should only be used by experts
> for really nasty to converge problems.
>
> ---
> Professor Laurence Marks
> "Research is to see what everybody else has seen, and to think what nobody
> else has thought", Albert Szent-Gyorgi
> http://www.numis.northwestern.edu
> Corrosion in 4D http://MURI4D.numis.northwestern.edu
> Partner of the CFW 100% gender equity project, www.cfw.org/100-percent
> Co-Editor, Acta Cryst A
>
>
> On Jan 26, 2017 07:28, "Laurence Marks" <l-ma...@northwestern.edu> wrote:
>
>> The last two (three) have useful information. They are
>>
>> Mode Size Step
>>
>> Mode is whether the trust region is active; it is off when Newton is
>> shown.
>>
>> Size is the radius of the trust region compared to a full Newton step,
>> for instance 0.5 would mean only half the full radius.
>>
>> Step is the magnitude of the step taken compared to a full Pratt step.
>>
>> All mixer codes (other DFT as well) use a Taylor series expansion for the
>> density change with some approximation for the Jacobian (see the mixer
>> README & papers). MSEC3 & MSR1 use different Jacobian approximations, as
>> did the old BROYD. Neglecting the higher-order terms is only valid for some
>> total step magnitude, the trust-region radius which is the "Size" variable
>> above. When Size is small the algorithm thinks these higher-order terms
>> matter. (The mixer adjusts the trust-region radius depending upon how much
>> the self-consistency is improving, which is very tricky, fuzzy coding and
>> imperfect.)
>>
>> The numbers you sent indicate that the algorithm thinks everything is
>> "fine". If Size is small (e.g. 0.05) and remains small that suggests a
>> problem. The "Step" term can be small when :DIS is large, but should not be
>> small near the solution. If it is large (2-3 or more) the algorithm thinks
>> that there are soft modes present.
>>
>> ---
>> Professor Laurence Marks
>> "Research is to see what everybody else has seen, and to think what
>> nobody else has thought", Albert Szent-Gyorgi
>> http://www.numis.northwestern.edu
>> Corrosion in 4D http://MURI4D.numis.northwestern.edu
>> Partner of the CFW 100% gender equity project, www.cfw.org/100-percent
>> Co-Editor, Acta Cryst A
>>
>>
>>
>> On Jan 26, 2017 05:02, "Luis Ogando" <lcoda...@gmail.com> wrote:
>>
>> Dear Prof. Marks,
>>
>>Just for completeness, in the InP case I am using mBJ and I have
>> checked that during the last 20 regular SCF cycles the steps are changing
>> from
>>
>> :MIX  :   MSE1   REGULARIZATION: 6.30E-06  GREED: 0.317  Newton 1.00  0.22
>>
>> to
>>
>> :MIX  :   MSE1   REGULARIZATION: 4.93E-06  GREED: 0.437  Newton 1.00  1.14
>>
>>Thank you once more !
>>All the best,
>>Luis
>> * PS: Could you, please, clarify the meaning of the last two columns in
>> the :MIX line ?
>>
>> 2017-01-26 8:18 GMT-02:00 Luis Ogando <lcoda...@gmail.com>:
>>
>>> Dear Prof. Marks,
>>>
>>>Thank you very much for your answers ! I am pretty sure that your
>>> "intuition" will save a lot of computation time !
>>>Just one last question: I have another system , a supercell formed by
>>> 15 InP zinc blend cells along [111] (hexagonal representation of the cubic
>>> lattice) and 3 InP wurtzite cells. They are aligned along the hexagonal "c"
>>> axis.
>>>  Comparing the gaps of the
>>> respective bulks and this supercell (same calculation parameters) , I
>>> believe that the SCF cycle (here, it is not a lattice optimization) stopped
>>> at a local minimum.
>>>   My question is : in this case
>>> (regular SCF cycle and InP cells), would you change any of your previous
>>> answers ?
>>>Thank you again !!
>>>All the best,
>>>  Luis
>>>
>>>
>>> 2017-01-25 17:56 GMT-02:00 Laurence Marks <l-ma...@northwestern.edu>:
>>>
>>>> Inlined is my intuition, which does not have to be completely right.
>>>

Re: [Wien] How to speed up a reliable optimization

[Luis Ogando]

Dear Prof. Marks,

   Just for completeness, in the InP case I am using mBJ and I have checked
that during the last 20 regular SCF cycles the steps are changing from

:MIX  :   MSE1   REGULARIZATION: 6.30E-06  GREED: 0.317  Newton 1.00  0.22

to

:MIX  :   MSE1   REGULARIZATION: 4.93E-06  GREED: 0.437  Newton 1.00  1.14

   Thank you once more !
   All the best,
   Luis
* PS: Could you, please, clarify the meaning of the last two columns in the
:MIX line ?

2017-01-26 8:18 GMT-02:00 Luis Ogando <lcoda...@gmail.com>:

> Dear Prof. Marks,
>
>Thank you very much for your answers ! I am pretty sure that your
> "intuition" will save a lot of computation time !
>Just one last question: I have another system , a supercell formed by
> 15 InP zinc blend cells along [111] (hexagonal representation of the cubic
> lattice) and 3 InP wurtzite cells. They are aligned along the hexagonal "c"
> axis.
>  Comparing the gaps of the respective
> bulks and this supercell (same calculation parameters) , I believe that the
> SCF cycle (here, it is not a lattice optimization) stopped at a local
> minimum.
>   My question is : in this case
> (regular SCF cycle and InP cells), would you change any of your previous
> answers ?
>Thank you again !!
>All the best,
>  Luis
>
>
> 2017-01-25 17:56 GMT-02:00 Laurence Marks <l-ma...@northwestern.edu>:
>
>> Inlined is my intuition, which does not have to be completely right.
>>
>> On Wed, Jan 25, 2017 at 11:32 AM, Luis Ogando <lcoda...@gmail.com> wrote:
>>
>>> Dear Prof. Marks (and Wien2k community),
>>>
>>>After a recent discussion about "difficult" optimizations in this
>>> mailing list (subject: "Mixer surprise when using PBE0 hybrid on-site
>>> functional"), I would like ask you for an advice.
>>>I have a system with:
>>> * 5 rings with C, H and N atoms
>>> * 100 atoms with P1 symmetry
>>> * the rings are out of a plane
>>> * vacuum along y and z
>>>I know that this is a very hard optimization problem, so I would like
>>> to kindly ask:
>>>
>>> 1) Do you believe that MSEC3a will work better than MSR1a in such a case
>>> ?
>>>
>>
>> I would switch to MSEC3a, use SLOW or reduce the GREED to 0.1 only if you
>> see indications of problems. If the system is a decent insulator and the
>> experimental positions are quite good you may have no problems. At the end
>> I would switch back to MSR1a certainly for a system with OH as the
>> positions of the hydrogens can be quite soft. It can take quite some time
>> to get the rotations of the OH bond distance right as Wien2k uses cartesian
>> coordinates not polars. Which of the 3 is best -- I am not sure.
>>
>>>
>>> 2) Do you recommend using -it, -vec2pratt and -noHinv options with
>>> run_lapw ?
>>>
>>
>> I use -it -noHinv -vec2pratt. Sometimes you need to do an occasional full
>> diagonalization (touch .fulldiag) as the iterative method is less stable
>> (it adds a little noise). In my personal version I have added back the old
>> -itn option so this is done automatically every few steps.
>>
>>>
>>> 3) Should I reduce TRUST to 0.5 (I am using LDA and experimental values
>>> for the initial atomic positions) ?
>>>
>>
>> Probably not. TRUST 0.5 would be if it is taking much too large steps
>> which tends (in my experience) to occur more with soft electronic modes
>> such as one has with d and f electrons.
>>
>>>
>>> 4) Should I use SLOW in case.inm ?
>>>
>>
>> See my answer to 1)
>>
>>>
>>>Many thanks in advance.
>>>All the best,
>>>   Luis
>>>
>>>
>>
>>
>> --
>> 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-percen
>> t
>> 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/wi
>> e...@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] How to speed up a reliable optimization

[Luis Ogando]

Dear Prof. Marks,

   Thank you very much for your answers ! I am pretty sure that your
"intuition" will save a lot of computation time !
   Just one last question: I have another system , a supercell formed by 15
InP zinc blend cells along [111] (hexagonal representation of the cubic
lattice) and 3 InP wurtzite cells. They are aligned along the hexagonal "c"
axis.
 Comparing the gaps of the respective
bulks and this supercell (same calculation parameters) , I believe that the
SCF cycle (here, it is not a lattice optimization) stopped at a local
minimum.
  My question is : in this case
(regular SCF cycle and InP cells), would you change any of your previous
answers ?
   Thank you again !!
   All the best,
 Luis


2017-01-25 17:56 GMT-02:00 Laurence Marks <l-ma...@northwestern.edu>:

> Inlined is my intuition, which does not have to be completely right.
>
> On Wed, Jan 25, 2017 at 11:32 AM, Luis Ogando <lcoda...@gmail.com> wrote:
>
>> Dear Prof. Marks (and Wien2k community),
>>
>>After a recent discussion about "difficult" optimizations in this
>> mailing list (subject: "Mixer surprise when using PBE0 hybrid on-site
>> functional"), I would like ask you for an advice.
>>I have a system with:
>> * 5 rings with C, H and N atoms
>> * 100 atoms with P1 symmetry
>> * the rings are out of a plane
>> * vacuum along y and z
>>I know that this is a very hard optimization problem, so I would like
>> to kindly ask:
>>
>> 1) Do you believe that MSEC3a will work better than MSR1a in such a case ?
>>
>
> I would switch to MSEC3a, use SLOW or reduce the GREED to 0.1 only if you
> see indications of problems. If the system is a decent insulator and the
> experimental positions are quite good you may have no problems. At the end
> I would switch back to MSR1a certainly for a system with OH as the
> positions of the hydrogens can be quite soft. It can take quite some time
> to get the rotations of the OH bond distance right as Wien2k uses cartesian
> coordinates not polars. Which of the 3 is best -- I am not sure.
>
>>
>> 2) Do you recommend using -it, -vec2pratt and -noHinv options with
>> run_lapw ?
>>
>
> I use -it -noHinv -vec2pratt. Sometimes you need to do an occasional full
> diagonalization (touch .fulldiag) as the iterative method is less stable
> (it adds a little noise). In my personal version I have added back the old
> -itn option so this is done automatically every few steps.
>
>>
>> 3) Should I reduce TRUST to 0.5 (I am using LDA and experimental values
>> for the initial atomic positions) ?
>>
>
> Probably not. TRUST 0.5 would be if it is taking much too large steps
> which tends (in my experience) to occur more with soft electronic modes
> such as one has with d and f electrons.
>
>>
>> 4) Should I use SLOW in case.inm ?
>>
>
> See my answer to 1)
>
>>
>>Many thanks in advance.
>>All the best,
>>   Luis
>>
>>
>
>
> --
> 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] How to speed up a reliable optimization

[Luis Ogando]

Dear Prof. Marks (and Wien2k community),

   After a recent discussion about "difficult" optimizations in this
mailing list (subject: "Mixer surprise when using PBE0 hybrid on-site
functional"), I would like ask you for an advice.
   I have a system with:
* 5 rings with C, H and N atoms
* 100 atoms with P1 symmetry
* the rings are out of a plane
* vacuum along y and z
   I know that this is a very hard optimization problem, so I would like to
kindly ask:

1) Do you believe that MSEC3a will work better than MSR1a in such a case ?

2) Do you recommend using -it, -vec2pratt and -noHinv options with run_lapw
?

3) Should I reduce TRUST to 0.5 (I am using LDA and experimental values for
the initial atomic positions) ?

4) Should I use SLOW in case.inm ?

   Many thanks in advance.
   All the best,
  Luis
___
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] Hybrid functionals and SO

[Luis Ogando]

Dear Wien2k community,

   Greetings !
   Just to check: it is not yet possible to use hybrid functionals with
spin orbit coupling (Wien2k 16.1), is it ?
   All the best,
 Luis
___
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] Hartree-Fock and the Hubbard Model

[Luis Ogando]

   Thank you Pablo !
   I am looking for something introductory like wikipedia. Do you have some
reference "in this direction" ?
   All the best,
  Luis



2016-11-21 15:25 GMT-02:00 delamora <delam...@unam.mx>:

> Luis, look for Hubbard Model
>
> NaCl U2
>
>   Pablo
> --
> *De:* Wien <wien-boun...@zeus.theochem.tuwien.ac.at> en nombre de Luis
> Ogando <lcoda...@gmail.com>
> *Enviado:* lunes, 21 de noviembre de 2016 11:00:23 a. m.
> *Para:* A Mailing list for WIEN2k users
> *Asunto:* Re: [Wien] Hartree-Fock and the Hubbard Model
>
> Dear Prof. Tran,
>
>I would like to read more about this subject, but, unfortunately, your
> link gave me a message like : " Wikipedia does not have an article with
> this exact name. "
>Please*,* could you suggest another non-specialist reference like
> wikipedia ?
>Thank you,
>Luis
>
> 2016-11-20 13:28 GMT-02:00 <t...@theochem.tuwien.ac.at>:
>
>> Hi,
>>
>> DFT+U is a cheap but rather rough approximation of HF.
>> Beside this, there is also the difference that in DFT+U, the Coulomb
>> operator is attenuated in order to account for the screening due to
>> correlation. In HF, no correlation is included.
>> In hybrids, the screening is included by using only ~25% of HF exchange
>> (and there is also correlation coming from a LDA/GGA correlation term).
>>
>> Hybrid, onsite-hybrid and DFT+U are more or less the same,
>> since all of them are one-electron methods and mix HF with LDA/GGA.
>> As Karel said, they are better than LDA/GGA, but can not reproduce
>> the experimental observations that are beyond the one-electron methods.
>> DMFT is better since it is a beyond one-electrons method.
>>
>> Read that:
>> https://en.wikipedia.org/wiki/LDA+U
>>
>> FT
>>
>>
>> On Wed, 16 Nov 2016, delamora wrote:
>>>
>>>
>>> Dear Fabien Tran and Karel Vyborny,
>>>
>>> Thanks for your comments.
>>>
>>>
>>> What I want to know is if the Hartree Fock exchange is what the Hubbard
>>> U is
>>> trying to model
>>>
>>> What I know is that for strong intraatomic repulsion, 3d and 4f, the
>>> Hubbard
>>> U gives good results, although the U is a parameter.
>>>
>>> But for intermediate intraatomic repulsion, 4d, 5d, 5f then more
>>> expensive
>>> methods are needed, such as DMFT
>>>
>>> So, if this is the case that the Hartree Fock exchange is what the
>>> Hubbard U
>>> is trying to model then the hybrid functionals would do a better job.
>>>
>>> So, my question is; What are the Hubbard U and DMFT trying to model?
>>>
>>>
>>> Cheers
>>>
>>>   Pablo de la Mora
>>
>>
>> ___
>> 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/wi
>> e...@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] Hartree-Fock and the Hubbard Model

[Luis Ogando]

Dear Prof. Tran,

   I would like to read more about this subject, but, unfortunately, your
link gave me a message like : " Wikipedia does not have an article with
this exact name. "
   Please*,* could you suggest another non-specialist reference like
wikipedia ?
   Thank you,
   Luis

2016-11-20 13:28 GMT-02:00 :

> Hi,
>
> DFT+U is a cheap but rather rough approximation of HF.
> Beside this, there is also the difference that in DFT+U, the Coulomb
> operator is attenuated in order to account for the screening due to
> correlation. In HF, no correlation is included.
> In hybrids, the screening is included by using only ~25% of HF exchange
> (and there is also correlation coming from a LDA/GGA correlation term).
>
> Hybrid, onsite-hybrid and DFT+U are more or less the same,
> since all of them are one-electron methods and mix HF with LDA/GGA.
> As Karel said, they are better than LDA/GGA, but can not reproduce
> the experimental observations that are beyond the one-electron methods.
> DMFT is better since it is a beyond one-electrons method.
>
> Read that:
> https://en.wikipedia.org/wiki/LDA+U
>
> FT
>
>
> On Wed, 16 Nov 2016, delamora wrote:
>>
>>
>> Dear Fabien Tran and Karel Vyborny,
>>
>> Thanks for your comments.
>>
>>
>> What I want to know is if the Hartree Fock exchange is what the Hubbard U
>> is
>> trying to model
>>
>> What I know is that for strong intraatomic repulsion, 3d and 4f, the
>> Hubbard
>> U gives good results, although the U is a parameter.
>>
>> But for intermediate intraatomic repulsion, 4d, 5d, 5f then more expensive
>> methods are needed, such as DMFT
>>
>> So, if this is the case that the Hartree Fock exchange is what the
>> Hubbard U
>> is trying to model then the hybrid functionals would do a better job.
>>
>> So, my question is; What are the Hubbard U and DMFT trying to model?
>>
>>
>> Cheers
>>
>>   Pablo de la Mora
>
>
> ___
> 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] run_lapw -hf (complex case)

[Luis Ogando]

Dear Prof. Tran,

   Thank you for your attention !
   So, the sequence is the same for the complex and real cases with
non-spin-polarized systems. Am I right ?
   All the best,
Luis


2016-11-07 14:50 GMT-02:00 <t...@theochem.tuwien.ac.at>:

> It is not necessary to include -c since the x script detects
> automatically if the calculation is complex.
>
>
> On Monday 2016-11-07 17:28, Luis Ogando wrote:
>
> Date: Mon, 7 Nov 2016 17:28:50
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <w...@zeus.theochem.tuwien.ac.
>> at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] run_lapw -hf (complex case)
>>
>>
>> Dear Wien2k community,
>>
>>On page 51 of the User Guide (Wien2k 14.2) one can read the following
>> sequence of commands corresponding to " run_lapw -hf " for the
>> non-spin-polarized and real case:
>>
>>  x lapw0 -grr (semilocal exchange)
>>  x lapw0 (semilocal exchange-correlation)
>>  x lapw1 (semilocal orbitals)
>>  x lapw2 (semilocal bands)
>>  mv case.vectorhf case.vectorhf_old
>>  x hf (hybrid orbitals)
>>  cp case.klist_fbz case.klist, cp case.kgen_fbz case.kgen
>>  x lapw2 -hf (hybrid electron density and bands)
>>  cp case.klist_ibz case.klist, cp case.kgen_ibz case.kgen
>>  x lcore
>>  x mixer
>>
>>I would like to know the correspondent sequence for the
>> non-spin-polarized but complex case. It would be the same sequence but
>> including " -c
>> " when appropriate ?
>>Thank you,
>> Luis
>>
>>
>>
>>
> ___
> 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] run_lapw -hf (complex case)

[Luis Ogando]

Dear Wien2k community,

   On page 51 of the User Guide (Wien2k 14.2) one can read the following
sequence of commands corresponding to " run_lapw -hf " for the
non-spin-polarized and real case:

 x lapw0 -grr (semilocal exchange)
 x lapw0 (semilocal exchange-correlation)
 x lapw1 (semilocal orbitals)
 x lapw2 (semilocal bands)
 mv case.vectorhf case.vectorhf_old
 x hf (hybrid orbitals)
 cp case.klist_fbz case.klist, cp case.kgen_fbz case.kgen
 x lapw2 -hf (hybrid electron density and bands)
 cp case.klist_ibz case.klist, cp case.kgen_ibz case.kgen
 x lcore
 x mixer

   I would like to know the correspondent sequence for the
non-spin-polarized but complex case. It would be the same sequence but
including " -c " when appropriate ?
   Thank you,
Luis
___
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] Intel compilers and MPI

[Luis Ogando]

Dear Prof Marks,

   Thank you very much for your help.
   All the best,
  Luis


2016-10-31 16:27 GMT-02:00 Laurence Marks <l-ma...@northwestern.edu>:

> The intel ifort + mkl for k-point parallel.
> Scalapack for mpi (check if it is in the package you are looking at)
> Intel mpi is good, but openmpi and mvapich as also good. I currently
> prefer the intelmpi.
> The intel C compiler is not critical (gcc should be fine). If it comes
> with, use it. I would not purchase it just for Wien2k.
>
> On Mon, Oct 31, 2016 at 6:18 AM, Luis Ogando <lcoda...@gmail.com> wrote:
> > Dear Wien2k community,
> >
> >A quick question: to compile and run Wien2k, do I need only the Intel
> > Fortran and C compilers with MKL (Composer Edition) plus Intel MPI or do
> I
> > have to buy the licence for the complete "cluster edition" (
> > https://software.intel.com/en-us/intel-parallel-studio-xe  ) ?
> >All the best,
> >   Luis
> >
> >
>
>
>
> --
> 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] Intel compilers and MPI

[Luis Ogando]

Dear Wien2k community,

   A quick question: to compile and run Wien2k, do I need only the Intel
Fortran and C compilers with MKL (Composer Edition) plus Intel MPI or do I
have to buy the licence for the complete "cluster edition" (
https://software.intel.com/en-us/intel-parallel-studio-xe  ) ?
   All the best,
  Luis
___
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] Dielectric function , HSE (YS-PBE0) and spin-orbit coupling

[Luis Ogando]

Dear Prof. Tran,

   Thank you very much for your help !
   I will try it and wait for the next Wien2k release.
   All the best,
  Luis



2016-08-23 12:02 GMT-03:00 <t...@theochem.tuwien.ac.at>:

> Hi,
>
> Unfortunately, it is not yet possible to combine the -hf and -so options
> simultaneously, but probably this will be possible in the next WIEN2k
> release. At the moment, the best is maybe to do what you suggest, but
> you need to follow the steps below
>
> 1) run_lapw -hf ...
> 2) cp case.klist_fbz case.klist
> 3) cp case.kgen_fbz case.kgen
> 4) cp case.vectorhf case.vector
> 5) cp case.energyhf case.energy
> 6) initso_lapw (do NOT add any relativistic LO)
> 7) x lapwso (WITHOUT -p)
> 8) x lapw2 -fermi -so (WITHOUT -p)
> 9) cp $WIENROOT/SRC_templates/case.inop case.inop (same for injoint and
> inkram)
> 10) modify case.in/op/joint/kram according to your needs.
> 11) x optic -so (WITHOUT -p)
> 12) x joint
> 13) x kram
>
> Before "run_lapw -hf ..." choose emax in case.in1(c) and
> nband in case.inhf, which are large enough also for SO and optic,
> but don't specify an excessively large nband in order to avoid
> hybrid calculations that are too expensive. This is nband which will
> determine the range of energy for plotting the optic spectra.
>
> F. tran
>
> On Monday 2016-08-22 20:00, Luis Ogando wrote:
>
> Date: Mon, 22 Aug 2016 20:00:50
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <w...@zeus.theochem.tuwien.ac.
>> at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] Dielectric function , HSE (YS-PBE0) and spin-orbit
>> coupling
>>
>>
>> Dear Wien2k community,
>>
>>I would like to calculate the dielectric function of GaP in the
>> wurtzite
>> symmetry but I only get a reasonable band structure using HSE (YS-PBE0).
>>My problem is that spin-orbit coupling (SOC) has a significant
>> contribution to the electronic properties of this system and I was
>> thinking
>> about some way to, at least, estimate the SOC effect on "epsilon".
>>Considering that SOC is relevant but less important than HSE, my first
>> trial would be:
>> 1) run a regular SCF cycle with -hf option ( run_lapw -hf ... )
>> 2) after that, I would run " x lapwso " to get a rough idea of the SOC
>> effects
>> 3) calculate the dielectric function as explained in the Wien user guide
>> for
>> the SOC case, but including -hf with the appropriate executables.
>>As I do not in deep know the programs, I am not sure if this would work
>> or give rise to a crash.
>>Do you believe that this procedure would give me the approximate SOC
>> effects on the dielectric function ?
>>Any other suggestion would be highly appreciated.
>>Thanks in advance.
>>All the best,
>>Luis
>>
>>
>>
>>
> ___
> 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] Dielectric function , HSE (YS-PBE0) and spin-orbit coupling

[Luis Ogando]

Dear Wien2k community,

   I would like to calculate the dielectric function of GaP in the wurtzite
symmetry but I only get a reasonable band structure using HSE (YS-PBE0).
   My problem is that spin-orbit coupling (SOC) has a significant
contribution to the electronic properties of this system and I was thinking
about some way to, at least, estimate the SOC effect on "epsilon".
   Considering that SOC is relevant but less important than HSE, my first
trial would be:
1) run a regular SCF cycle with -hf option ( run_lapw -hf ... )
2) after that, I would run " x lapwso " to get a rough idea of the SOC
effects
3) calculate the dielectric function as explained in the Wien user guide
for the SOC case, but including -hf with the appropriate executables.
   As I do not in deep know the programs, I am not sure if this would work
or give rise to a crash.
   Do you believe that this procedure would give me the approximate SOC
effects on the dielectric function ?
   Any other suggestion would be highly appreciated.
   Thanks in advance.
   All the best,
   Luis
___
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] GGA-PBE and YS-PBE0

[Luis Ogando]

Dear Prof. Tran,

   Thank you very much for your help !
   All the best,
   Luis


2016-07-14 8:46 GMT-03:00 <t...@theochem.tuwien.ac.at>:

> Hi,
>
> In general, mixing Hartree-Fock with a semilocal functional has
> an effect on the volume. See Table III in
> http://journals.aps.org/prb/abstract/10.1103/PhysRevB.83.235118
>
> Should you neglect this effect or not, depends on its importance
> for the conclusions of your paper.
>
> F. Tran
>
> On Thursday 2016-07-14 13:27, Luis Ogando wrote:
>
> Date: Thu, 14 Jul 2016 13:27:38
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <
>> wien@zeus.theochem.tuwien.ac.at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] GGA-PBE and YS-PBE0
>>
>>
>> Dear Wien2k community,
>>
>>I would like to know if it is reasonable to use YS-PBE0 (HSE) hybrid
>> functional in a structure optimized with GGA-PBE. In other words, I
>> would like to know if the expected effect of the hybrid functional on the
>> Energy x Volume curve given by the correspondent semilocal functional
>> is a rigid shift in energy (roughly speaking).
>>Thank you for your attention.
>>All the best,
>> Luis
>>
>>
>>
>>
> ___
> 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] GGA-PBE and YS-PBE0

[Luis Ogando]

Dear Wien2k community,

   I would like to know if it is reasonable to use YS-PBE0 (HSE) hybrid
functional in a structure optimized with GGA-PBE. In other words, I would
like to know if the expected effect of the hybrid functional on the Energy
x Volume curve given by the correspondent semilocal functional is a rigid
shift in energy (roughly speaking).
   Thank you for your attention.
   All the best,
Luis
___
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] NMATMAX

[Luis Ogando]

   0K ! Now it is clear !
   Thank you very much !
   All the best,
Luis



2016-07-12 15:35 GMT-03:00 Maciej Polak <maciej.po...@pwr.edu.pl>:

> Everything is OK, that only means that you have a complex calculation, in
> which case the NMATMAX is in addition reduced by sqrt(2), so you have
> 13000*sqrt(36/2)=55154. You should read the users guide, its all there
> (page 213).
> Try 64 cores.
>
> Best regards
>
> Maciej Polak
>
>
>
> On 07/12/2016 08:26 PM, Luis Ogando wrote:
>
> Dear Polak,
>
>Thank you for your response.
>In fact, I am using only one k-point with in a 36 processors MPI
> calculation. In this case, I should have the matrix size limited to 13000
> (NMATMAX) x sqrt(36) = 78000, but I am getting "MATRIX SIZE" = 55150. What
> am I still missing ? Is NMATMAX defined in another place ?
>Thank you again.
>All the best,
>  Luis
>
>
>
> 2016-07-12 15:11 GMT-03:00 Maciej Polak <maciej.po...@pwr.edu.pl>:
>
>> The NMATMAX you have defined in your param.inc is the maximum size for a
>> non mpi parallel calculation. If you use MPI, then the NMATMAX will be
>> automatically increased by sqrt(nmpi). So if you want to increase your
>> matrix size, the best way is to use mpi parallel execution. Simply
>> increasing NMATMAX and recompiling lapw1 and then running it without mpi
>> may lead to unrealistically high computational time.
>> And yes, the NMATMAX is really limiting the effective the RKmax, as you
>> need more matrix elements to represent a bigger basis set.
>>
>> Best regards
>>
>> Maciej Polak
>>
>>
>> On 07/12/2016 07:53 PM, Luis Ogando wrote:
>>
>> Dear Wien2k community,
>>
>>I am calculating a compound with H atoms. Due to this, I used RKmax =
>> 3.0 as recommended in the Wien2k homepage.
>>The calculating run without a problem, but I got :
>>
>> :WARN :  WARNING: RKmax reduced due to NMATMAX
>>
>>In $WIENROOT/SRC_lpaw1/param.inc I have NMATMAX=13000 and, to my
>> surprise, I also have :
>>
>> :RKM  : MATRIX SIZE 55150LOs: 295  RKM= 2.38  WEIGHT= 1.00  PGR:
>>
>> when I was expecting MATRIX SIZE <= NMATMAX
>>I would like to get an effective RKmax=3.0 for testing convergence and
>> to get it I was thinking in changing NMATMAX in
>> $WIENROOT/SRC_lpaw1/param.inc and recompiling the SRC_lapw1 directory.
>>Well, as I am not sure if NMATMAX is really limiting the effective
>> RKmax, I would like to know what I misunderstood and what is the correct
>> procedure to increase the effective RKmax.
>>Thank you for your attention !
>>All the best,
>>   Luis
>>
>>
>>
>>
>>
>>
>> ___
>> Wien mailing 
>> listw...@zeus.theochem.tuwien.ac.athttp://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 
> listw...@zeus.theochem.tuwien.ac.athttp://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] NMATMAX

[Luis Ogando]

Dear Polak,

   Thank you for your response.
   In fact, I am using only one k-point with in a 36 processors MPI
calculation. In this case, I should have the matrix size limited to 13000
(NMATMAX) x sqrt(36) = 78000, but I am getting "MATRIX SIZE" = 55150. What
am I still missing ? Is NMATMAX defined in another place ?
   Thank you again.
   All the best,
 Luis



2016-07-12 15:11 GMT-03:00 Maciej Polak <maciej.po...@pwr.edu.pl>:

> The NMATMAX you have defined in your param.inc is the maximum size for a
> non mpi parallel calculation. If you use MPI, then the NMATMAX will be
> automatically increased by sqrt(nmpi). So if you want to increase your
> matrix size, the best way is to use mpi parallel execution. Simply
> increasing NMATMAX and recompiling lapw1 and then running it without mpi
> may lead to unrealistically high computational time.
> And yes, the NMATMAX is really limiting the effective the RKmax, as you
> need more matrix elements to represent a bigger basis set.
>
> Best regards
>
> Maciej Polak
>
>
> On 07/12/2016 07:53 PM, Luis Ogando wrote:
>
> Dear Wien2k community,
>
>I am calculating a compound with H atoms. Due to this, I used RKmax =
> 3.0 as recommended in the Wien2k homepage.
>The calculating run without a problem, but I got :
>
> :WARN :  WARNING: RKmax reduced due to NMATMAX
>
>In $WIENROOT/SRC_lpaw1/param.inc I have NMATMAX=13000 and, to my
> surprise, I also have :
>
> :RKM  : MATRIX SIZE 55150LOs: 295  RKM= 2.38  WEIGHT= 1.00  PGR:
>
> when I was expecting MATRIX SIZE <= NMATMAX
>I would like to get an effective RKmax=3.0 for testing convergence and
> to get it I was thinking in changing NMATMAX in
> $WIENROOT/SRC_lpaw1/param.inc and recompiling the SRC_lapw1 directory.
>Well, as I am not sure if NMATMAX is really limiting the effective
> RKmax, I would like to know what I misunderstood and what is the correct
> procedure to increase the effective RKmax.
>Thank you for your attention !
>All the best,
>   Luis
>
>
>
>
>
>
> ___
> Wien mailing 
> listw...@zeus.theochem.tuwien.ac.athttp://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

[Wien] NMATMAX

[Luis Ogando]

Dear Wien2k community,

   I am calculating a compound with H atoms. Due to this, I used RKmax =
3.0 as recommended in the Wien2k homepage.
   The calculating run without a problem, but I got :

:WARN :  WARNING: RKmax reduced due to NMATMAX

   In $WIENROOT/SRC_lpaw1/param.inc I have NMATMAX=13000 and, to my
surprise, I also have :

:RKM  : MATRIX SIZE 55150LOs: 295  RKM= 2.38  WEIGHT= 1.00  PGR:

when I was expecting MATRIX SIZE <= NMATMAX
   I would like to get an effective RKmax=3.0 for testing convergence and
to get it I was thinking in changing NMATMAX in
$WIENROOT/SRC_lpaw1/param.inc and recompiling the SRC_lapw1 directory.
   Well, as I am not sure if NMATMAX is really limiting the effective
RKmax, I would like to know what I misunderstood and what is the correct
procedure to increase the effective RKmax.
   Thank you for your attention !
   All the best,
  Luis
___
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] Fwd: Phonopy

[Luis Ogando]

Dear Dr. Gupta,

   As said by Prof. Blaha, you need "total forces" after each :FGLXXX value
and not "partial forces".
   As far as I remember, the "total forces" are written when we use the
"-fc" option in the run_lapw command, but I may be wrong (I used phonopy a
long time ago).
   Are you using the last version of Wien2k ?
   All the best,
  Luis



2016-06-14 9:59 GMT-03:00 GOUTAM KUMAR GUPTA :

> Dear Blaha
>
> yes ,We got total forces at the end of scf files. in all four
> (1,2,3,4.scf) cases similar as is given below
>
>
>  TOTAL FORCE WITH RESPECT TO THE GLOBAL COORDINATE SYSTEM:
> :FGL001:   1.ATOM 1.990164939-2.355025345
> -65.852619662 partial forces
> :FGL002:   2.ATOM 1.657758789-1.528141986
> -64.563203275 partial forces
> :FGL003:   3.ATOM 2.013110308-1.951678770
> -64.915794333 partial forces
> :FGL004:   4.ATOM 2.451424441-3.530262985
> -64.201093381 partial forces
> :FGL005:   5.ATOM 2.294023235-2.328282552
> -66.121235468 partial forces
> :FGL006:   6.ATOM 2.281756255-2.503371769
> -65.852014480 partial forces
> :FGL007:   7.ATOM 2.483043895-2.268896721
> -65.759165770 partial forces
> :FGL008:   8.ATOM 2.251816983-2.203155260
> -65.936127413 partial forces
> :FGL009:   9.ATOM-3.052289087 2.939861042
> -66.094300563 partial forces
> :FGL010:  10.ATOM-0.599014079 3.263575430
> -65.959690814 partial forces
> :FGL011:  11.ATOM-3.223069731 0.791636940
> -66.022929979 partial forces
> :FGL012:  12.ATOM-2.242891255 2.324666166
> -65.733212483 partial forces
> :FGL013:  13.ATOM-2.199401257 2.094741650
> -65.160993875 partial forces
> :FGL014:  14.ATOM-2.473559698 2.305400782
> -66.496348972 partial forces
> :FGL015:  15.ATOM-2.302700322 2.579912628
> -65.824566358 partial forces
> :FGL016:  16.ATOM-2.250917678 2.324730213
> -65.670671242 partial forces
> :FGL017:  17.ATOM 0.214944844-0.284376783
> -15.836377639 partial forces
> :FGL018:  18.ATOM 0.297510232-0.303509473
> -14.441741135 partial forces
> :FGL019:  19.ATOM 0.293112648-0.291986071
> -14.422855669 partial forces
> :FGL020:  20.ATOM 0.281616807-0.261084822
> -14.465997554 partial forces
> :FGL021:  21.ATOM 0.271838320-0.285211390
> -14.327164373 partial forces
> :FGL022:  22.ATOM 0.305299216-0.276612467
> -14.366359346 partial forces
> :FGL023:  23.ATOM 0.265761316-0.302861429
> -14.401710048 partial forces
> :FGL024:  24.ATOM 0.291894876-0.275752692
> -14.331712080 partial forces
> :FGL025:  25.ATOM-0.265260467 0.279435202
> -14.331092051 partial forces
> :FGL026:  26.ATOM-0.330767287 0.255016650
> -14.313112143 partial forces
> :FGL027:  27.ATOM-0.253125457 0.320850994
> -14.322299591 partial forces
> :FGL028:  28.ATOM-0.296503620 0.285197097
> -14.390960216 partial forces
> :FGL029:  29.ATOM-0.398359429 0.434231849
> -14.354896890 partial forces
> :FGL030:  30.ATOM-2.507166788-0.842105453
> -15.130272087 partial forces
> :FGL031:  31.ATOM 0.223976324 1.244921444
> -14.738357888 partial forces
> :FGL032:  32.ATOM-0.277295252 0.286440989
> -14.423164962 partial forces
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> (END)
>
>
>
> Thanks
>
>
> On Tue, Jun 14, 2016 at 5:43 PM, Peter Blaha  > wrote:
>
>> phonopy (and I) has asked you if at the end of the file  2.scf there are
>> lines (for all atoms) with
>>
>> :FGL0xx   ..   total
>>
>> where xx referes to atom-numbers.
>>
>> Yes or no ?
>>
>>
>> On 06/14/2016 02:05 PM, GOUTAM KUMAR GUPTA wrote:
>>
>>> Dear Sir,
>>>
>>> We are using the wurzite (structure) of ZnS.
>>> I know that phonopy want primitive cell so i choose the P cell only.
>>> Yes, we have mailed the infromation which the phonopy print after the
>>> last command line
>>> that is
>>> mbeshst@IITJ_HPC ZnS]$ phonopy --wien2k -f 1.scf 2.scf 3.scf 4.scf
>>>  _
>>>
>>>_ __ | |__   ___  _ __   ___   _ __  _   _
>>>   | '_ \| '_ \ / _ \| '_ \ / _ \ | '_ \| | | |
>>>   | |_) | | | | (_) | | | | (_) || |_) | |_| |
>>>   | .__/|_| |_|\___/|_| |_|\___(_) .__/ \__, |
>>>   |_||_||___/
>>>1.10.0
>>>
>>> **
>>> Wien2k FORCE_SETS support is experimental.
>>> Your feedback would be appreciated.   
>>> 

Re: [Wien] Fwd: Phonopy

[Luis Ogando]

Dear Dr. Gupta,

   When you calculated the energy for each one of the supercells generated
by phonopy, did you use the "-fc" option for force convergence in the
"run_lapw" command ?
   All the best,
Luis



2016-06-14 5:38 GMT-03:00 GOUTAM KUMAR GUPTA :

> Dear sir
> I  want to calculate the phonon spectrum of ZnS using the phonopy 1.10.0.
> so in this order, i  followed these steps:
> mkstruct
> init_lapw
> phonopy --wien2k -c ZnS.struct -d --dim="2 2 2"
> so it generate the four files
> ZnS.structS-001
> ZnS.structS-002
> ZnS.structS-003
> ZnS.structS-004
> after this process, i calculated the scf file of each struct file by
> making directory of each struct file separetly then copy into the ZnS
> directory then i would like to compute the total force so i gave the
> command " phonopy --wien2k -f 1.scf 2.scf 3.scf 4.scf "
>  which showing the following error
>
> [ambeshst@IITJ_HPC ZnS]$ phonopy --wien2k -f 1.scf 2.scf 3.scf 4.scf
> _
>   _ __ | |__   ___  _ __   ___   _ __  _   _
>  | '_ \| '_ \ / _ \| '_ \ / _ \ | '_ \| | | |
>  | |_) | | | | (_) | | | | (_) || |_) | |_| |
>  | .__/|_| |_|\___/|_| |_|\___(_) .__/ \__, |
>  |_||_||___/
>   1.10.0
>
> **
> Wien2k FORCE_SETS support is experimental.
> Your feedback would be appreciated.   
> **
> It is assumed that there is no symmetrically-equivalent atoms in
> '1.scf' at wien2k calculation.
>
> Drift force of 1.scf
>   0.00053796  -0.00033949  -0.08833666
> This drift force was subtracted from forces.
> 2.scf does not contain necessary information.
> Plese check if there are "FGL" lines with
> "total forces" are required.
> FORCE_SETS could not be created.
>  _
>___ _ __   __| |
>   / _ \ '_ \ / _` |
>  |  __/ | | | (_| |
>   \___|_| |_|\__,_|
>
> --
> *Goutam Kumar Gupta*
> *Mob:8561995547*
>
>
>
> ___
> 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] :WAR : LOPW-exhausted for atom ...

[Luis Ogando]

   Dear Prof. Blaha,

   Thank you very much !
   All the best,
  Luis



2016-06-09 10:07 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> This is no problem.
>
>
> Am 06.06.2016 um 16:16 schrieb Luis Ogando:
>
>> Dear Wien2k community,
>>
>>I am trying to optimize a cubic structure with MSR1a and I am getting
>> the following message in practically all the SCF cycles.
>>
>> :WAR   : LOPW-exhausted for atom   11 PASS 1  had to reduce check 0.01
>>
>>After checking it in the mailing list and noticing that the PASS is
>> always 1 and that "check" is always reduced to 0.01, I believe that it
>> is not a serious problem. Anyway, I would like to be sure. Can anyone
>> confirm this to me ?
>>Please, do not hesitate in asking me more information.
>>Thanks in advance,
>>   Luis
>>
>>
>>
>> ___
>> 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/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
>
___
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] :WAR : LOPW-exhausted for atom ...

[Luis Ogando]

Dear Wien2k community,

   I am trying to optimize a cubic structure with MSR1a and I am getting
the following message in practically all the SCF cycles.

:WAR   : LOPW-exhausted for atom   11 PASS 1  had to reduce check 0.01

   After checking it in the mailing list and noticing that the PASS is
always 1 and that "check" is always reduced to 0.01, I believe that it is
not a serious problem. Anyway, I would like to be sure. Can anyone confirm
this to me ?
   Please, do not hesitate in asking me more information.
   Thanks in advance,
  Luis
___
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] GaP wurtzite

[Luis Ogando]

Dear Prof. Tran,

   First of all, thank you very much for your help.
   Unfortunately, mBJ at the PBEsol geometry did not solve my problem.
Despite of giving me structural parameters between the LDA and PBE results,
mBJ with PBEsol at the PBEsol geometry gave me a gap of 1.82 eV at M (CBM)
for GaP in the wurtzite structure.
   Do you have any other suggestion or do you believe that this is the best
we can do ?
   Thank you again.
   All the best,
 Luis




2016-05-25 10:52 GMT-03:00 <t...@theochem.tuwien.ac.at>:

> Hi,
>
> If mBJ+LDA/PBE means mBJ calculation at the LDA/PBE geometry, then you
> could try mBJ at the PBEsol geometry.
>
> But anyway, what do you mean by "good" or "not good"? What is the
> disagreement between mBJ and experiment?
>
> F. Tran
>
> On Wednesday 2016-05-25 15:13, Luis Ogando wrote:
>
> Date: Wed, 25 May 2016 15:13:40
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <
>> wien@zeus.theochem.tuwien.ac.at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] GaP wurtzite
>>
>>
>> Dear Wien2k community,
>>
>>I have calculated the band structure of GaP in the wurtzite phase with
>> PBE and LDA. After the cell optimization with the correspondent XC
>> potential, I got a direct gap structure with underestimated gap value.
>>The direct gap result is the expected one (
>> dx.doi.org/10.1021/nl304723c | Nano Lett. 2013, 13, 1559−1563 ) and, in
>> order to improve the gap value, I calculated the band structure with mBJ
>> (P-semiconductor).
>> When I use mBJ + LDA I got a very good value for the gap, but it
>> becomes indirect (CBM at M). When I use mBJ + PBE, the gap keeps direct,
>> but its value is not that good.
>>Well, I would appreciate if someone could give me any suggestion about
>> how to get a good gap without changing its "character".
>>All the best,
>> Luis
>>
>>
>>
> ___
> 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] GaP wurtzite

[Luis Ogando]

Dear Prof. Tran,

   Thank you for your comments !!
   Yes, mBJ+LDA/PBE means mBJ calculation at the LDA/PBE geometry.

   The experimental gap is around 2.1 eV and I got this value with mBJ +
LDA but with the CBM at M.
   When using mBJ + PBE, I get a direct gap of ~ 1.8 eV. Well, I agree that
it is not so bad, but after the change to an indirect gap with mBJ+LDA, I
am a little worried about what happens to the other symmetry points.
   Thank you again.
   All the best,
  Luis



2016-05-25 10:52 GMT-03:00 <t...@theochem.tuwien.ac.at>:

> Hi,
>
> If mBJ+LDA/PBE means mBJ calculation at the LDA/PBE geometry, then you
> could try mBJ at the PBEsol geometry.
>
> But anyway, what do you mean by "good" or "not good"? What is the
> disagreement between mBJ and experiment?
>
> F. Tran
>
> On Wednesday 2016-05-25 15:13, Luis Ogando wrote:
>
> Date: Wed, 25 May 2016 15:13:40
>> From: Luis Ogando <lcoda...@gmail.com>
>> Reply-To: A Mailing list for WIEN2k users <
>> wien@zeus.theochem.tuwien.ac.at>
>> To: A Mailing list for WIEN2k users <wien@zeus.theochem.tuwien.ac.at>
>> Subject: [Wien] GaP wurtzite
>>
>>
>> Dear Wien2k community,
>>
>>I have calculated the band structure of GaP in the wurtzite phase with
>> PBE and LDA. After the cell optimization with the correspondent XC
>> potential, I got a direct gap structure with underestimated gap value.
>>The direct gap result is the expected one (
>> dx.doi.org/10.1021/nl304723c | Nano Lett. 2013, 13, 1559−1563 ) and, in
>> order to improve the gap value, I calculated the band structure with mBJ
>> (P-semiconductor).
>> When I use mBJ + LDA I got a very good value for the gap, but it
>> becomes indirect (CBM at M). When I use mBJ + PBE, the gap keeps direct,
>> but its value is not that good.
>>Well, I would appreciate if someone could give me any suggestion about
>> how to get a good gap without changing its "character".
>>All the best,
>> Luis
>>
>>
>>
> ___
> 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] GaP wurtzite

[Luis Ogando]

Dear Wien2k community,

   I have calculated the band structure of GaP in the wurtzite phase with
PBE and LDA. After the cell optimization with the correspondent XC
potential, I got a direct gap structure with underestimated gap value.
   The direct gap result is the expected one ( dx.doi.org/10.1021/nl304723c
| Nano Lett. 2013, 13, 1559−1563 ) and, in order to improve the gap value,
I calculated the band structure with mBJ (P-semiconductor).
When I use mBJ + LDA I got a very good value for the gap, but it
becomes indirect (CBM at M). When I use mBJ + PBE, the gap keeps direct,
but its value is not that good.
   Well, I would appreciate if someone could give me any suggestion about
how to get a good gap without changing its "character".
   All the best,
Luis
___
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] MSR1a X mini

[Luis Ogando]

   Dear Prof. Marks and Prof. Blaha,

   Thank you very much for your comments.
   All the best,
  Luis

2016-01-28 12:54 GMT-02:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> For sure there can be examples where the old min_lapw is faster, but
> experience is that usually run -min is faster than min_lapw.
>
> I have a different opinion about constraining positions. I'm using this
> very frequently and have no problems with it.
> But: don't be surprised if on these constrained atoms at the end some
> forces appear !
>
>
> On 01/28/2016 02:32 PM, Luis Ogando wrote:
>
>> Dear Wien2k community (and specially Prof. Marks),
>>
>> Is there any situation where the "old" "mini" may present a better
>> performance than "MSR1a" or this is an almost impossible situation ?
>> I am working with III-V semiconductors and their heterostructures.
>> Sometimes I am trying to optimize the heterostructure fixing the atomic
>> positions in the "thick" layer using the correspondent optimized bulk
>> values. If I remember correctly, Prof. Marks has criticized this
>> procedure. Would this significantly affect the heterostructure
>> optimization ?
>> All the best,
>>  Luis
>>
>>
>>
>> ___
>> 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
>
___
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] MSR1a X mini

[Luis Ogando]

Dear Wien2k community (and specially Prof. Marks),

   Is there any situation where the "old" "mini" may present a better
performance than "MSR1a" or this is an almost impossible situation ?
   I am working with III-V semiconductors and their heterostructures.
Sometimes I am trying to optimize the heterostructure fixing the atomic
positions in the "thick" layer using the correspondent optimized bulk
values. If I remember correctly, Prof. Marks has criticized this procedure.
Would this significantly affect the heterostructure optimization ?
   All the best,
Luis
___
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] LDA x PBE for optimization

[Luis Ogando]

Dear Wien2k community,

   I am working with III-V semiconductors (bulks and some
combinations/heterostructures of their different compounds).
   I have noticed that sometimes LDA is better than PBE for convergence in
the structural optimizations (in other words, convergence is easier with
LDA).
   I would like to know if there is a kind of "general tendency" for III-V
semiconductors or it will depend on the atomic species (or anything else) ?
   All the best,
   Luis
___
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] LDA x PBE for optimization

[Luis Ogando]

Dear Prof. Tran,

   Thank you very much !
   All the best,
 Luis


2016-01-25 15:31 GMT-02:00 <t...@theochem.tuwien.ac.at>:

> Since LDA does not require the derivatives of the electron density,
> maybe this leads to more stable and smoother SCF/optimization.
>
>
> On Mon, 25 Jan 2016, Luis Ogando wrote:
>
> Dear Wien2k community,
>>
>>I am working with III-V semiconductors (bulks and some
>> combinations/heterostructures of their different compounds).
>>I have noticed that sometimes LDA is better than PBE for convergence
>> in the structural optimizations (in other words, convergence is easier with
>> LDA).
>>I would like to know if there is a kind of "general tendency" for
>> III-V semiconductors or it will depend on the atomic species (or anything
>> else) ?
>>All the best,
>>Luis
>>
>>
> ___
> 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] restoring MSR1a

[Luis Ogando]

Dear Professor Marks,

   Thank you very much !
   All the best,
 Luis


2016-01-20 11:37 GMT-02:00 Laurence Marks <laurence.ma...@gmail.com>:

> I don't think you need anything more.
>
> As one caveat, the default save_lapw deletes the case.broyd* files so you
> will need to wait for the multisecant matrix to be reestablished before the
> calculation makes much progress, i.e. 4-8 iterations.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> On Jan 20, 2016 06:39, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>> Dear Wien2k community,
>>
>>Just a quick question : considering that I am using MSR1a for an
>> optimization and I want to add more scf cycles using restore_lapw for a
>> previous optimization that did not converge but it was saved using
>> save_lapw, the default parameters for these commands are good enough or
>> should I include (and restore) any extra file in the "saved" directory ?
>>All the best,
>>Luis
>>
>>
> ___
> 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] restoring MSR1a

[Luis Ogando]

Dear Wien2k community,

   Just a quick question : considering that I am using MSR1a for an
optimization and I want to add more scf cycles using restore_lapw for a
previous optimization that did not converge but it was saved using
save_lapw, the default parameters for these commands are good enough or
should I include (and restore) any extra file in the "saved" directory ?
   All the best,
   Luis
___
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] passing env variables to lapw1 and 2

[Luis Ogando]

  What about to include them in the job submission script ?
   All the best,
 Luis

2015-11-10 12:32 GMT-02:00 Laurence Marks :

> A partial solution is to include them in $WIENROOT/parallel_options, as
> all the parallel routines source this file. You may be able to tweak this
> for what you want, but since I don't know exactly what you want to set I am
> not sure.
>
> N.B., if you are using openmpi then you have to enable transfer for
> variables in the mpi call command, and perhaps for other flavors as well.
>
> On Tue, Nov 10, 2015 at 8:25 AM, Pavel Ondracka 
> wrote:
>
>> Dear Wien2k mailing list,
>>
>> I'm having some troubles passing environmental variables (eg.
>> OMP_NUM_THREADS or similar) to lapw1 and lapw2. This works in serial
>> mode where the lapw* programs are called directly, however in parallel
>> mode they are run through remote shell and all environmental info is
>> lost.
>> I can declare them in my .bashrc and then it works (since the .bashrc
>> is reloaded when remote shell is spawned) however i would  like to
>> specify them per task.
>> One solution I had in mind was to go through AcceptEnv in sshd however
>> this is considered insecure according to cluster admins an is disabled.
>> Another option is to modify the wien scripts to include the required
>> variables when calling the remote shell, however at the moment I'm
>> wondering if there is more universal and elegant solution?
>> Any ideas?
>>
>> Best regards
>> Pavel Ondračka
>> ___
>> 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
>
>
___
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] Linear constraint and MSR1a

[Luis Ogando]

Dear Prof. Marks and Wien2k community,

   Is it possible to use linear constraints for the atomic positions with
MSR1a ?
   All the best,
  Luis
___
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] Linear constraint and MSR1a

[Luis Ogando]

   Thank you !
  Luis


2015-10-14 16:20 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> If you mean fix atom(s), yes. General linear constraints, no. There is
> some code to do this with PORT, never used it (& I am on travel).
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> On Oct 14, 2015 19:21, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>> Dear Prof. Marks and Wien2k community,
>>
>>Is it possible to use linear constraints for the atomic positions with
>> MSR1a ?
>>All the best,
>>   Luis
>>
>>
> ___
> 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] time difference among nodes

[Luis Ogando]

Hi Lyudmila,

   Thanks again !
   I will ask them.
   All the best,
  Luis


2015-09-29 10:37 GMT-03:00 Lyudmila Dobysheva :

> 29.09.2015 14:57, Laurence Marks wrote:
>
>> If it happens again, one thing to ask them to check is swap usage and
>> how much memory is cached.
>>
> ...
>
>> Alternatively it was something else, a zombie, big log files or other
>> things. Rebooting gets rid of a lot of system caches and helps
>>
>
> I stand for losing parallelization on that node due to unclear reason
> (maybe this bad swapping/caching threw away parallel options from the
> memory and all jobs had been sent to only one processor of the node).
>
> I would like to know what had administrator seen in the "1" mode of top
> command.
>
> Best wishes
>   Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 432045(office), 722529(Fax)
> E-mail: l...@ftiudm.ru, lyuk...@mail.ru (office)
> lyuk...@gmail.com (home)
> Skype:  lyuka17 (home), lyuka18 (office)
> http://ftiudm.ru/content/view/25/103/lang,english/
> --
> ___
> 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] time difference among nodes

[Luis Ogando]

Hi Lyudmila,

   Unfortunately, they do not have "top mode 1" output corresponding to the
problem period.
   Thanks again.
   All the best,
 Luis


2015-09-29 10:37 GMT-03:00 Lyudmila Dobysheva :

> 29.09.2015 14:57, Laurence Marks wrote:
>
>> If it happens again, one thing to ask them to check is swap usage and
>> how much memory is cached.
>>
> ...
>
>> Alternatively it was something else, a zombie, big log files or other
>> things. Rebooting gets rid of a lot of system caches and helps
>>
>
> I stand for losing parallelization on that node due to unclear reason
> (maybe this bad swapping/caching threw away parallel options from the
> memory and all jobs had been sent to only one processor of the node).
>
> I would like to know what had administrator seen in the "1" mode of top
> command.
>
> Best wishes
>   Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 432045(office), 722529(Fax)
> E-mail: l...@ftiudm.ru, lyuk...@mail.ru (office)
> lyuk...@gmail.com (home)
> Skype:  lyuka17 (home), lyuka18 (office)
> http://ftiudm.ru/content/view/25/103/lang,english/
> --
> ___
> 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] time difference among nodes

[Luis Ogando]

Dear Prof. Marks,

   Thanks !
   I will send your message to the administrators !
   All the best,
   Luis


2015-09-29 8:57 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> If it happens again, one thing to ask them to check is swap usage and how
> much memory is cached. On some of my nodes I have noticed that they do not
> always release cached memory, and can start swapping. If this happens the
> job will get very slow. The commands to use to clear the cache can be found
> at
>
> http://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/
> or similar. (Needs root access.) Top can also show memory use.
>
> While there should be no need to do this, I have noticed that I need to do
> it every 3hrs on 4 nodes - the other 20 don't need it. It is an issue
> mainly for big calculations.
>
> Alternatively it was something else, a zombie, big log files or other
> things. Rebooting gets rid of a lot of system caches and helps -- even on
> my Android tablet every week or two. It's murky waters.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> Hi Elias,
>
>There were no other jobs in the specific queue I was using and the
> nodes are dedicated to that queue, so, it was the opportunity to reboot
> them without furious reactions from other users.
>After trying everything suggested by the Wien2k community, the
> administrators resignedly remembered the words of wisdom given by the
> cluster guru, Shakespeare, and followed the suggestion given by Lyudmila
> Dobysheva. In other words, they killed my job, restarted all the nodes and
> I resubmitted the calculation
>All the best,
>  Luis
>
>
> 2015-09-29 3:50 GMT-03:00 Elias Assmann <elias.assm...@gmail.com>:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 09/28/2015 01:58 PM, Luis Ogando wrote:
>> > The problem is solved ! The solution was one suggested by Lyudmila
>> > Dobysheva : reboot the nodes. We will never know the origin of the
>> > problem, but, honestly, I do not care !
>>
>> Good to hear that!  So, how did you get the admins to reboot them?
>>
>> > "There are more things in heaven and earth, Horatio, Than are
>> > dreamt of in your philosophy."
>>
>> That is an apt quote for people working on clusters ;-).
>>
>>
>> Elias
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJWCjTGAAoJEE/4gtQZfOqPhFAQAKZmda0t9FGgfAsk9UjymogK
>> oN1WxHdenQVOSaOblpAFEn4c0ihTog7zePEXdTqNl03OcBUcdKtOPVqSVLBKlmlF
>> f0VOBUeXjmOZKd6SAIuwNojflW0k9ysrJ2sLCo/dOGepT4L2Q8Um5DHpgh+mjehM
>> XtGbn6uDUQlcjoLKgHG9GxBzr9qRDqc4chYnMAvwNGkm7qntt7Q1jol9yGZikB8e
>> CONyaqYghNBr4x7BtGOaITJQ7yWw++l7t56oMSCNOXzee8Noy53cKPCVOvzh8lUF
>> PlMRNFB9pTgdxs59dy5yF31R4LTJjMG7zm+gHjmWDMi7BnQZQGEWDc6MIzLIwTPj
>> kN5dZm4R/cbVjYEzIlmsr9h67H/+9Otr36AvwfvvwycL/wy0RkC7jxqY0eC8i3fK
>> v/FdmFbt6b2wxzalmjvg+sEILe18Uz0fCmhcCDRdZ2fgmOWC68WeH4I7d2/kCJTr
>> Az2K8ZvZ5LxBCSH9MLoh/heZVSI3rowHu3aUNqfcbZ1pJLmT68RU9ZmPgfQnA4bK
>> 4uny7MaDcyYN/IvMRWf8lUiuY3OsRHGZAmcIfagkqvV2ukWPRFQ2AmsaZpMxbYyg
>> FsdKDJfYocUdp14KMT3wEhiGmUTE5BwtxAXq4NTq1sdJGESZIzhbEXYHbgnD7mbF
>> QDT7WZ/DqG+KpcVTRmnz
>> =JtdF
>> -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
>>
>
>
> ___
> 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] time difference among nodes

[Luis Ogando]

Hi Elias,

   There were no other jobs in the specific queue I was using and the nodes
are dedicated to that queue, so, it was the opportunity to reboot them
without furious reactions from other users.
   After trying everything suggested by the Wien2k community, the
administrators resignedly remembered the words of wisdom given by the
cluster guru, Shakespeare, and followed the suggestion given by Lyudmila
Dobysheva. In other words, they killed my job, restarted all the nodes and
I resubmitted the calculation
   All the best,
 Luis


2015-09-29 3:50 GMT-03:00 Elias Assmann <elias.assm...@gmail.com>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/28/2015 01:58 PM, Luis Ogando wrote:
> > The problem is solved ! The solution was one suggested by Lyudmila
> > Dobysheva : reboot the nodes. We will never know the origin of the
> > problem, but, honestly, I do not care !
>
> Good to hear that!  So, how did you get the admins to reboot them?
>
> > "There are more things in heaven and earth, Horatio, Than are
> > dreamt of in your philosophy."
>
> That is an apt quote for people working on clusters ;-).
>
>
> Elias
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJWCjTGAAoJEE/4gtQZfOqPhFAQAKZmda0t9FGgfAsk9UjymogK
> oN1WxHdenQVOSaOblpAFEn4c0ihTog7zePEXdTqNl03OcBUcdKtOPVqSVLBKlmlF
> f0VOBUeXjmOZKd6SAIuwNojflW0k9ysrJ2sLCo/dOGepT4L2Q8Um5DHpgh+mjehM
> XtGbn6uDUQlcjoLKgHG9GxBzr9qRDqc4chYnMAvwNGkm7qntt7Q1jol9yGZikB8e
> CONyaqYghNBr4x7BtGOaITJQ7yWw++l7t56oMSCNOXzee8Noy53cKPCVOvzh8lUF
> PlMRNFB9pTgdxs59dy5yF31R4LTJjMG7zm+gHjmWDMi7BnQZQGEWDc6MIzLIwTPj
> kN5dZm4R/cbVjYEzIlmsr9h67H/+9Otr36AvwfvvwycL/wy0RkC7jxqY0eC8i3fK
> v/FdmFbt6b2wxzalmjvg+sEILe18Uz0fCmhcCDRdZ2fgmOWC68WeH4I7d2/kCJTr
> Az2K8ZvZ5LxBCSH9MLoh/heZVSI3rowHu3aUNqfcbZ1pJLmT68RU9ZmPgfQnA4bK
> 4uny7MaDcyYN/IvMRWf8lUiuY3OsRHGZAmcIfagkqvV2ukWPRFQ2AmsaZpMxbYyg
> FsdKDJfYocUdp14KMT3wEhiGmUTE5BwtxAXq4NTq1sdJGESZIzhbEXYHbgnD7mbF
> QDT7WZ/DqG+KpcVTRmnz
> =JtdF
> -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
>
___
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] time difference among nodes

[Luis Ogando]

Dear Wien2k community,

   I would like to thank so many hints !
   The problem is solved ! The solution was one suggested by Lyudmila
Dobysheva : reboot the nodes. We will never know the origin of the problem,
but, honestly, I do not care !

"There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy."
- *Hamlet* (1.5.167-8), Hamlet to Horatio
 Shakespeare

   I would like to thank you all again.
   All the best,
 Luis

2015-09-25 5:56 GMT-03:00 Pawel Lesniak <lesn...@ifmpan.poznan.pl>:

> Hello,
>
> I'd suggest trying three things.
>
> First of all - does your cluster allow running interactive jobs? If yes,
> than you should create an interactive job to run /bin/bash. I'm not
> familiar with PBS, but in SGE/OGE if you print cluster queues with "qstat
> -f" you'll see "I" in column qtype which means that given queue allows
> running interactive jobs. Using bash you should be able to run top on given
> node without SSH access.
>
> Regardless of success or failure you should be able to look at nodes
> statistics using "qhost" command. You should see at lease what is the
> current load, memory usage and swap usage. In SGE/OGE there's a switch "-j"
> to qhost which will also show you what jobs are currently running on each
> node. It's necessary to be able to see load of machine interactively
> instead of view at some point of time.
>
> The last concept is to prepare a job to run at the same time on the same
> node as Wien2K, consisting of several
> "ps auxww | grep ogando >> ${HOME}/ps.output; sleep 2"
> commands. It will give you some information on what's going on. Think of
> it as non-interactive top stored in text file.
>
>
> Best regards,
>
> Pawel Lesniak
>
>
> W dniu 23.09.2015 o 14:25, Luis Ogando pisze:
>
> 0K ! In this case, I will try it !
>Many thanks,
>   Luis
>
>
> 2015-09-23 9:23 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:
>
>> Ganglia is web based, you don't need ssh. Please read the link I sent.
>>
>> ---
>> Professor Laurence Marks
>> Department of Materials Science and Engineering
>> Northwestern University
>> http://www.numis.northwestern.edu
>> Corrosion in 4D http://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
>> On Sep 23, 2015 07:21, "Luis Ogando" <lcoda...@gmail.com> wrote:
>>
>>>Hi,
>>>
>>>I can not access the nodes. SSH among them is forbidden ! We have to
>>> ask the administrators for anything !! It is the hell !!
>>>Of course, only the PBS jobs can "travel" among the nodes.
>>>All the best,
>>>Luis
>>>
>>>
>>> 2015-09-23 9:14 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:
>>>
>>>> Nooo!
>>>>
>>>> You should use ganglia yourself.
>>>>
>>>> ---
>>>> Professor Laurence Marks
>>>> Department of Materials Science and Engineering
>>>> Northwestern University
>>>> http://www.numis.northwestern.edu
>>>> Corrosion in 4D <http://MURI4D.numis.northwestern.edu>
>>>> http://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
>>>> On Sep 23, 2015 07:13, "Luis Ogando" < <lcoda...@gmail.com>
>>>> lcoda...@gmail.com> wrote:
>>>>
>>>>> Dear Prof. Marks,
>>>>>
>>>>>Thank you for your comment.
>>>>>I sent your suggestions to the administrators.
>>>>>All the best,
>>>>> Luis
>>>>>
>>>>>
>>>>> 2015-09-23 8:56 GMT-03:00 Laurence Marks < <laurence.ma...@gmail.com>
>>>>> laurence.ma...@gmail.com>:
>>>>>
>>>>>> It is hard to work this out remotely, particularly with unfriendly
>>>>>> sys_admin.
>>>>>>
>>>>>> I would find out if you have ganglia available, see
>>>>>> <http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/ICEX_Admin_Guide/sgi_html/ch05.html#Z1190844523tls>
>>>>>> http://techpubs.sgi.com/libr

Re: [Wien] time difference among nodes

[Luis Ogando]

Dear Prof. Marks,

   As I suspected, users can not use ganglia. Our administrators are very
jealous !!

Dear Elias Assmann,

   Many thanks for your comments. I will try to comment on some of them.


First of all, I wonder: To what extent is this problem reproducible?
> E.g., does your job always run on the same 4 nodes?


Yes.


> Is it always the
> same node(s) that are slow?


Yes


> Does the problem also show up in other
> calculations (maybe just changing the number of k-points, or
> restarting the same case from scratch).


The strangest part: at the beginning of this month, the same calculation
was running properly. I had a crash for convergence problems and when I
reduced the "mixing factor" in case.inm (it is now 0.04 in pre-convergence
scf cycle) the problems started. Obviously, I do not believe that the
mixing factor is the problem.


> Is it only lapw1 that is slow?
>

No. All the executables are running slowly in the problematic node.


>
> Second, how did you make those ‘top’s?  As for ‘lapw0’ and ‘lapw1’, I
> am guessing that this is just because the snapshots were taken at
> different times (notice that the CPU times of lapw0 on the two nodes
> are quite different, too).
>

Users can do nothing. The administrator sent me the "top's" and I have
asked him for simultaneous ones.


>
> About the CPU usage on ‘n2’, I find this very suspicious.  If it is as
> Peter said that the jobs are in the initialization and therefore not
> computing much, that may be fine; but I have to disagree with his
> assessment, because the memory usage of lapw1 on the two nodes is
> basically the same (if anything, the image sizes on ‘n2’ are slightly
> larger).  Note also that it is *not* the case that other processes are
> using the CPU; the total usage is at 7.5 %.
>
> It would be good to clarify that by getting a ‘top’ such that we know
> that lapw1 had been running for a while.  To this end, top has an ‘-n’
> option which says how many frames to output, e.g. ‘top -bn 10’.
>
> I am also curious about the load averages.  ‘n2’ has larger “mid-term”
> and “long-term” load averages than the others, and its “short-term”
> average is just as large.  I am not sure what that means.
>
> On 09/23/2015 02:21 PM, Luis Ogando wrote:
> > I can not access the nodes. SSH among them is forbidden ! We have
> > to ask the administrators for anything !! It is the hell !! Of
> > course, only the PBS jobs can "travel" among the nodes.
>
> I do not know about PBS Pro, but Torque and SGE have an option (I
> think ‘-I’ in either case) to submit an interactive job where you get
> a login on a node.  Of course that is only a realistic option when the
> queuing time is not too long.  Otherwise, any information that a more
> sophisticated tool can give you will also be available from the
> command line (just more painful to extract!) via ‘top’, ‘ps’, ‘/proc’,
> etc.  You can also put these things in a jobs script (which you
> apparently already did with ‘top’).
>
>
> Good luck,
>
> Elias
>

Finally, I would like to thank all the comments and say that if I did
not comment on them is because the administrators said they can not be the
origin of the problem, "everything is 0K" (?).
   All the best,
  Luis
___
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] time difference among nodes

[Luis Ogando]

0K ! In this case, I will try it !
   Many thanks,
  Luis


2015-09-23 9:23 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> Ganglia is web based, you don't need ssh. Please read the link I sent.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> On Sep 23, 2015 07:21, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>>Hi,
>>
>>I can not access the nodes. SSH among them is forbidden ! We have to
>> ask the administrators for anything !! It is the hell !!
>>Of course, only the PBS jobs can "travel" among the nodes.
>>All the best,
>>Luis
>>
>>
>> 2015-09-23 9:14 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:
>>
>>> Nooo!
>>>
>>> You should use ganglia yourself.
>>>
>>> ---
>>> Professor Laurence Marks
>>> Department of Materials Science and Engineering
>>> Northwestern University
>>> http://www.numis.northwestern.edu
>>> Corrosion in 4D http://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
>>> On Sep 23, 2015 07:13, "Luis Ogando" <lcoda...@gmail.com> wrote:
>>>
>>>> Dear Prof. Marks,
>>>>
>>>>Thank you for your comment.
>>>>I sent your suggestions to the administrators.
>>>>All the best,
>>>> Luis
>>>>
>>>>
>>>> 2015-09-23 8:56 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:
>>>>
>>>>> It is hard to work this out remotely, particularly with unfriendly
>>>>> sys_admin.
>>>>>
>>>>> I would find out if you have ganglia available, see
>>>>> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/ICEX_Admin_Guide/sgi_html/ch05.html#Z1190844523tls
>>>>> . This is much more useful than top. Try doing http://... to relevant
>>>>> head or admin nodes.
>>>>>
>>>>> ---
>>>>> Professor Laurence Marks
>>>>> Department of Materials Science and Engineering
>>>>> Northwestern University
>>>>> http://www.numis.northwestern.edu
>>>>> Corrosion in 4D http://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
>>>>> On Sep 23, 2015 06:31, "Luis Ogando" <lcoda...@gmail.com> wrote:
>>>>>
>>>>>> Dear Prof. Blaha and Lyudmila Dobysheva,
>>>>>>
>>>>>>Many thanks for your comments !
>>>>>>Unfortunately, users have no privileges in the cluster. I will
>>>>>> send your comments to the administrators and let's see what happens.
>>>>>>Many thanks again,
>>>>>> Luis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ___
>>>>> 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
>
>
___
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] time difference among nodes

[Luis Ogando]

   Hi,

   I can not access the nodes. SSH among them is forbidden ! We have to ask
the administrators for anything !! It is the hell !!
   Of course, only the PBS jobs can "travel" among the nodes.
   All the best,
   Luis


2015-09-23 9:14 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> Nooo!
>
> You should use ganglia yourself.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> On Sep 23, 2015 07:13, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>> Dear Prof. Marks,
>>
>>Thank you for your comment.
>>I sent your suggestions to the administrators.
>>All the best,
>> Luis
>>
>>
>> 2015-09-23 8:56 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:
>>
>>> It is hard to work this out remotely, particularly with unfriendly
>>> sys_admin.
>>>
>>> I would find out if you have ganglia available, see
>>> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/ICEX_Admin_Guide/sgi_html/ch05.html#Z1190844523tls
>>> . This is much more useful than top. Try doing http://... to relevant
>>> head or admin nodes.
>>>
>>> ---
>>> Professor Laurence Marks
>>> Department of Materials Science and Engineering
>>> Northwestern University
>>> http://www.numis.northwestern.edu
>>> Corrosion in 4D http://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
>>> On Sep 23, 2015 06:31, "Luis Ogando" <lcoda...@gmail.com> wrote:
>>>
>>>> Dear Prof. Blaha and Lyudmila Dobysheva,
>>>>
>>>>Many thanks for your comments !
>>>>Unfortunately, users have no privileges in the cluster. I will send
>>>> your comments to the administrators and let's see what happens.
>>>>Many thanks again,
>>>> Luis
>>>>
>>>>
>>>>
>>>>
>>> ___
>>> 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] time difference among nodes

[Luis Ogando]

Dear Prof. Marks,

   Thank you for your comment.
   I sent your suggestions to the administrators.
   All the best,
Luis


2015-09-23 8:56 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> It is hard to work this out remotely, particularly with unfriendly
> sys_admin.
>
> I would find out if you have ganglia available, see
> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/ICEX_Admin_Guide/sgi_html/ch05.html#Z1190844523tls
> . This is much more useful than top. Try doing http://... to relevant
> head or admin nodes.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> http://www.numis.northwestern.edu
> Corrosion in 4D http://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
> On Sep 23, 2015 06:31, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>> Dear Prof. Blaha and Lyudmila Dobysheva,
>>
>>Many thanks for your comments !
>>Unfortunately, users have no privileges in the cluster. I will send
>> your comments to the administrators and let's see what happens.
>>Many thanks again,
>> Luis
>>
>>
>>
>>
> ___
> 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] time difference among nodes

[Luis Ogando]

Dear Prof. Blaha and Lyudmila Dobysheva,

   Many thanks for your comments !
   Unfortunately, users have no privileges in the cluster. I will send your
comments to the administrators and let's see what happens.
   Many thanks again,
Luis
___
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] time difference among nodes

[Luis Ogando]

   0:06.76 lapw1c_mpi

 2123 ogando20   0  924m 632m  18m R8  1.7   0:09.65 lapw1c_mpi

 2098 ogando20   0  922m 634m  16m R8  1.8   0:06.71 lapw1c_mpi

 2097 ogando20   0  927m 641m  19m R7  1.8   0:06.75 lapw1c_mpi

 2094 ogando20   0 67048 2928 2052 S0  0.0   0:00.02 orted

 2099 ogando20   0 67048 2932 2052 S0  0.0   0:00.01 orted

 2120 ogando20   0 67048 2924 2052 S0  0.0   0:00.01 orted

r1i1n3

top - 17:42:50 up 56 days,  3:25,  1 user,  load average: 10.57, 6.02, 2.59
Tasks: 241 total,  13 running, 228 sleeping,   0 stopped,   0 zombie
Cpu(s): 99.5%us,  0.4%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,
 0.0%st
Mem: 36176M total,31395M used, 4781M free,0M buffers
Swap:0M total,0M used,0M free,23089M cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND

26197 ogando20   0  913m 634m  17m R  100  1.8   0:59.33 lapw1c_mpi

26199 ogando20   0  909m 630m  16m R  100  1.7   0:59.39 lapw1c_mpi

26200 ogando20   0  906m 624m  13m R  100  1.7   0:59.35 lapw1c_mpi

26260 ogando20   0  910m 631m  16m R  100  1.7   0:57.17 lapw1c_mpi

26271 ogando20   0  904m 625m  17m R  100  1.7   0:54.98 lapw1c_mpi

26273 ogando20   0  903m 624m  16m R  100  1.7   0:55.03 lapw1c_mpi

26274 ogando20   0  903m 620m  13m R  100  1.7   0:55.04 lapw1c_mpi

26258 ogando20   0  913m 634m  17m R  100  1.8   0:57.17 lapw1c_mpi

26259 ogando20   0  910m 631m  16m R  100  1.7   0:57.16 lapw1c_mpi

26261 ogando20   0  908m 625m  13m R  100  1.7   0:57.22 lapw1c_mpi

26272 ogando20   0  903m 624m  17m R  100  1.7   0:54.97 lapw1c_mpi

26198 ogando20   0  909m 631m  17m R   99  1.7   0:59.34 lapw1c_mpi

26196 ogando20   0 67048 2924 2052 S0  0.0   0:00.02 orted

26257 ogando20   0 67048 2928 2052 S0  0.0   0:00.01 orted

26270 ogando20   0 67048 2924 2052 S0  0.0   0:00.01 orted

2015-09-21 10:22 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> a) Check your .machines file.  DFoes it meet your expectations, or has
> this node too large load.
>
> b) Can you interactively login into these nodes while your job is running ?
> If yes, login on 2 nodes (in two windows) and runtop
>
> c) If nothing obvious is wrong so far, test the network by doing some
> bigger copying from/to these nodes from your $home (or $scratch) to see if
> file-io is killing you.
>
>
> On 09/21/2015 02:51 PM, Luis Ogando wrote:
>
>> Dear Prof. Marks,
>>
>> Many thanks for your help.
>> The administrators said that everything is 0K, the software is the
>> problem (the easy answer) : no zombies, no other jobs in the node, ... !!
>> Let me give you more information to see if you can imagine other
>> possibilities:
>>
>> 1) Intel Xeon Six Core 5680, 3.33GHz
>>
>> 2) Intel(R) Fortran/CC/OpenMPI Intel(R) 64 Compiler XE for applications
>> running on Intel(R) 64, Version 12.1.1.256 Build 20111011
>>
>> 3) OpenMPI 1.6.5
>>
>> 4) PBS Pro 11.0.2
>>
>> 5) OpenMPI built using  --with-tm  due to prohibited ssh among nodes  (
>> http://www.open-mpi.org/faq/?category=building#build-rte-tm )
>>
>> 6) Wien2k 14.2
>>
>> 7) The mystery : two weeks ago, everything was working properly !!
>>
>> Many thanks again !
>> All the best,
>> Luis
>>
>> 2015-09-18 23:24 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com
>> <mailto:laurence.ma...@gmail.com>>:
>>
>> Almost certainly one or more of:
>> * Other jobs on the node
>> * Zombie process(es)
>> * Too many mpi
>> * Bad memory
>> * Full disc
>> * Too hot
>>
>> If you have it use ganglia, if not ssh in and use top/ps or whatever
>> SGI has. If you cannot sudo get help from someone who can.
>>
>> On Sep 18, 2015 8:58 PM, "Luis Ogando" <lcoda...@gmail.com
>> <mailto:lcoda...@gmail.com>> wrote:
>>
>> Dear Wien2k community,
>>
>> I am using Wien2k in a SGI cluster with 32 nodes. My
>> calculation is running in 4 nodes that have the same
>> characteristics and only my job is running in these 4 nodes.
>> I noticed that one of these 4 nodes is spending more than 20
>> times the time spent by the other 3 nodes in the run_lapw
>> execution.
>> Could someone imagine a reason for this ? Any advice ?
>> All the best,
>>  Luis
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theo

Re: [Wien] time difference among nodes

[Luis Ogando]

Dear Prof. Marks,

   Many thanks for your help.
   The administrators said that everything is 0K, the software is the
problem (the easy answer) : no zombies, no other jobs in the node, ... !!
   Let me give you more information to see if you can imagine other
possibilities:

1) Intel Xeon Six Core 5680, 3.33GHz

2) Intel(R) Fortran/CC/OpenMPI Intel(R) 64 Compiler XE for applications
running on Intel(R) 64, Version 12.1.1.256 Build 20111011

3) OpenMPI 1.6.5

4) PBS Pro 11.0.2

5) OpenMPI built using  --with-tm  due to prohibited ssh among nodes  (
http://www.open-mpi.org/faq/?category=building#build-rte-tm )

6) Wien2k 14.2

7) The mystery : two weeks ago, everything was working properly !!

   Many thanks again !
   All the best,
   Luis

2015-09-18 23:24 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com>:

> Almost certainly one or more of:
> * Other jobs on the node
> * Zombie process(es)
> * Too many mpi
> * Bad memory
> * Full disc
> * Too hot
>
> If you have it use ganglia, if not ssh in and use top/ps or whatever SGI
> has. If you cannot sudo get help from someone who can.
> On Sep 18, 2015 8:58 PM, "Luis Ogando" <lcoda...@gmail.com> wrote:
>
>> Dear Wien2k community,
>>
>>I am using Wien2k in a SGI cluster with 32 nodes. My calculation is
>> running in 4 nodes that have the same characteristics and only my job is
>> running in these 4 nodes.
>>I noticed that one of these 4 nodes is spending more than 20 times the
>> time spent by the other 3 nodes in the run_lapw execution.
>>Could someone imagine a reason for this ? Any advice ?
>>All the best,
>> Luis
>>
>>
>
> ___
> 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] time difference among nodes

[Luis Ogando]

Dear Professor Blaha,

   Thank you !
   My .machines file is 0K.
   I will ask the administrator to follow your other suggestions (users do
not have privileges).
   All the best,
   Luis


2015-09-21 10:22 GMT-03:00 Peter Blaha <pbl...@theochem.tuwien.ac.at>:

> a) Check your .machines file.  DFoes it meet your expectations, or has
> this node too large load.
>
> b) Can you interactively login into these nodes while your job is running ?
> If yes, login on 2 nodes (in two windows) and runtop
>
> c) If nothing obvious is wrong so far, test the network by doing some
> bigger copying from/to these nodes from your $home (or $scratch) to see if
> file-io is killing you.
>
>
> On 09/21/2015 02:51 PM, Luis Ogando wrote:
>
>> Dear Prof. Marks,
>>
>> Many thanks for your help.
>> The administrators said that everything is 0K, the software is the
>> problem (the easy answer) : no zombies, no other jobs in the node, ... !!
>> Let me give you more information to see if you can imagine other
>> possibilities:
>>
>> 1) Intel Xeon Six Core 5680, 3.33GHz
>>
>> 2) Intel(R) Fortran/CC/OpenMPI Intel(R) 64 Compiler XE for applications
>> running on Intel(R) 64, Version 12.1.1.256 Build 20111011
>>
>> 3) OpenMPI 1.6.5
>>
>> 4) PBS Pro 11.0.2
>>
>> 5) OpenMPI built using  --with-tm  due to prohibited ssh among nodes  (
>> http://www.open-mpi.org/faq/?category=building#build-rte-tm )
>>
>> 6) Wien2k 14.2
>>
>> 7) The mystery : two weeks ago, everything was working properly !!
>>
>> Many thanks again !
>> All the best,
>> Luis
>>
>> 2015-09-18 23:24 GMT-03:00 Laurence Marks <laurence.ma...@gmail.com
>> <mailto:laurence.ma...@gmail.com>>:
>>
>> Almost certainly one or more of:
>> * Other jobs on the node
>> * Zombie process(es)
>> * Too many mpi
>> * Bad memory
>> * Full disc
>> * Too hot
>>
>> If you have it use ganglia, if not ssh in and use top/ps or whatever
>> SGI has. If you cannot sudo get help from someone who can.
>>
>> On Sep 18, 2015 8:58 PM, "Luis Ogando" <lcoda...@gmail.com
>> <mailto:lcoda...@gmail.com>> wrote:
>>
>> Dear Wien2k community,
>>
>> I am using Wien2k in a SGI cluster with 32 nodes. My
>> calculation is running in 4 nodes that have the same
>> characteristics and only my job is running in these 4 nodes.
>> I noticed that one of these 4 nodes is spending more than 20
>> times the time spent by the other 3 nodes in the run_lapw
>> execution.
>> Could someone imagine a reason for this ? Any advice ?
>> All the best,
>>  Luis
>>
>>
>> ___
>> Wien mailing list
>> Wien@zeus.theochem.tuwien.ac.at > 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
>>
>>
> --
>
>   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
>
___
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] time difference among nodes

[Luis Ogando]

Dear Wien2k community,

   I am using Wien2k in a SGI cluster with 32 nodes. My calculation is
running in 4 nodes that have the same characteristics and only my job is
running in these 4 nodes.
   I noticed that one of these 4 nodes is spending more than 20 times the
time spent by the other 3 nodes in the run_lapw execution.
   Could someone imagine a reason for this ? Any advice ?
   All the best,
Luis
___
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 convergence necessity

[Luis Ogando]

Dear Prof. Marks,

   Thank you very much for your answer !!
   All the best,
Luis

2015-07-15 21:26 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 I don't think I can give a complete answer, but I will make one point. It
 can easily happen that the energy convergence appears to be OK, but the
 charge convergence is not. The reason is that the energy convergence is
 measured as a change in energy over the last few iterations, whereas the
 charge convergence is based upon the difference of the initial and final
 densities in the current cycle. If, for whatever reason, the mixer is only
 taking very small steps the energy can appear to have converged, but in
 reality the true self-consistent solution (fixed point) has not been
 reached.

 Hence I almost always add something like -cc 0.001 as a minimum level. If
 I really want to be certain about the fixed point I might decrease this by
 a factor of 4-10, never more than this.

 N.B., for a preconvergence before switching to MSR1a -cc 0.05 is often
 good enough.


 On Wed, Jul 15, 2015 at 7:08 PM, Luis Ogando lcoda...@gmail.com wrote:

   Dear Wien2k community,

 I would like to know in which situations the charge convergence is
 really necessary.
 All the best,
   Luis




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


___
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] Charge convergence necessity

[Luis Ogando]

Dear Wien2k community,

   I would like to know in which situations the charge convergence is
really necessary.
   All the best,
 Luis
___
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] mBJ + SOC :: spin-orbit splitting reduction

[Luis Ogando]

Dear Martin Gmitra,

   Some time ago, we had some comments about this issue in the mailing
list. Please, take a look at
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10697.html
  . Nevertheless, your specific questions should be answered by more
experienced users/developers.
   All the best,
   Luis


2015-02-05 18:46 GMT-02:00 Martin Gmitra martin.gmi...@gmail.com:

 Dear Wien2k developers,

 We are observing underestimating trend of spin-orbit coupling
 splittings of Gamma_{15} bands in zinc-blende semiconductors.

 For instance in GaAs, the Gamma_{15v} splits to Gamma_{8v} and
 Gamma_{7v} by the values of about 0.29 eV, while experiment gives 0.34
 eV. PBE calculations gives 0.32 eV. Similar one sees for Gamma_{15c}
 which splits due to spin-orbit to Gamma_{8c} and Gamma_{7c} where mBJ
 gives 0.156 eV and PBE 0.181 eV. This one can compare to 0.174 eV from
 GW+SOC calculations [PRL 96, 086405].

 In PRB 82, 205212 you present two implementations of mBJ, within
 Wien2k and VASP. Could you please provide information whether both the
 implementations provide the same spin-orbit splittings of Gamma_{15}
 states?

 In case they are the same, which part of the Becke-Johnson approach
 can be responsible for such a reduction?

 Best regards,
 Martin Gmitra
 Uni Regensburg
 ___
 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] Error in OPTIC

[Luis Ogando]

Another relevant information: when performing a sequential calculation
for a previously problematic K-grid (parallel execution), OPTIC works
without any error.
   All the best,
 Luis
___
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] mBJ and gap along z axis

[Luis Ogando]

Dear Wien2k community,

   I am using mBJ in a homostructutre, for example, a wurtzite InP
supercell with stacking faults along the z axis that correspond to a zinc
blend region.
   I would like to see the gap evolution along the z axis. By now, I am
using a very naive approach comparing the projected DOS for each atom with
that from the wurtzite and zinc blend bulks to determine the gap value in
each atomic position.
   Obviously, this is not an accurate or rigorous approach and I would like
to know if someone could suggest me a proper way to do this.
   All the best,
Luis
___
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] MSR1a information request

[Luis Ogando]

Dear Prof. Marks,

   I did new tests with the problematic system and I got some
interesting results.
   Roughly speaking, I have a set of case.struct files to optimise internal
parameters. I got them through x optimize using option 8 ( VARY C/A RATIO
and VOLUME (2D-case) (tetr and hex lattices) ) and I used the
optimize.job script to do the job.
   My results can be summarised as follows :

1) when I used mini and clmextrapol to generate the initial density for
a new case.struct from the x optimize set, everything went fine and I got
all structures optimised (internal parameters) without any error.

2) when I repeated the above calculation just changing mini by MSR1a,
the calculation was stuck in the second case.struct. More specifically,
mixer kept running forever during the third SCF cycle.

3) when I restarted the last calculation just changing clmextrapol by
dstart, everything went fine, without any error.

   It looks like there is an issue related to the starting density
(clmextrapol x dstart ).
   I am using Wien2k-13.
   Please, fell free to ask for any additional information.
   All the best,
  Luis


2014-09-17 11:10 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 A small discriepancy (grep -e :NEC03 case.scf) would be
 :NEC03: NUCLEAR AND ELECTRONIC CHARGE   1960.0  1959.98254 Valence
 i.e. around 0.0175


 A large one would be
 :NEC03: NUCLEAR AND ELECTRONIC CHARGE   1960.0  1959.68254 Valence
 i.e. around 0.3175

 A difference of 2.15 says that there is something going very badly wrong.
 Check first that :NEC01 shows only a small difference. If that is fine and
 other things are fine reduce the trust step in case.inM from 0.35 to 0.1.

 I perhaps have a cure, but it needs testing and may turn out not to be a
 cure.





 On Wed, Sep 17, 2014 at 8:48 AM, Luis Ogando lcoda...@gmail.com wrote:

Dear Prof. Marks,

 What do you mean with a large discrepancy in the new charge density
 ?
 I am facing some problems with a change in :NEC03 around 2.15. Would
 this be the case ?
 All the best,
   Luis
  PS: I am using Wien2k-13

 2014-09-16 9:42 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 I have a suspicion that for some systems MSR1a does not do so well and
 it is associated with a large discrepancy in the new charge density
 (:NEC03). This may be a source of problems, or just a symptom. If you have
 cases where MSR1a was not bahaving so well can you please check this and
 let me know. Thanks.

 N.B., not sure what I can do about this, but identifying an issue is
 always the first step.

 ___
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu
 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





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


___
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] MSR1a information request

[Luis Ogando]

Dear Prof. Marks,

   What do you mean with a large discrepancy in the new charge density ?
   I am facing some problems with a change in :NEC03 around 2.15. Would
this be the case ?
   All the best,
 Luis
PS: I am using Wien2k-13

2014-09-16 9:42 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 I have a suspicion that for some systems MSR1a does not do so well and it
 is associated with a large discrepancy in the new charge density (:NEC03).
 This may be a source of problems, or just a symptom. If you have cases
 where MSR1a was not bahaving so well can you please check this and let me
 know. Thanks.

 N.B., not sure what I can do about this, but identifying an issue is
 always the first step.

 ___
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu
 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


___
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] MSR1a information request

[Luis Ogando]

Dear Prof. Marks,

   I found my mistake !
   Thank you for your attention !
   All the best,
 Luis

2014-09-17 11:10 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 A small discriepancy (grep -e :NEC03 case.scf) would be
 :NEC03: NUCLEAR AND ELECTRONIC CHARGE   1960.0  1959.98254 Valence
 i.e. around 0.0175


 A large one would be
 :NEC03: NUCLEAR AND ELECTRONIC CHARGE   1960.0  1959.68254 Valence
 i.e. around 0.3175

 A difference of 2.15 says that there is something going very badly wrong.
 Check first that :NEC01 shows only a small difference. If that is fine and
 other things are fine reduce the trust step in case.inM from 0.35 to 0.1.

 I perhaps have a cure, but it needs testing and may turn out not to be a
 cure.





 On Wed, Sep 17, 2014 at 8:48 AM, Luis Ogando lcoda...@gmail.com wrote:

Dear Prof. Marks,

 What do you mean with a large discrepancy in the new charge density
 ?
 I am facing some problems with a change in :NEC03 around 2.15. Would
 this be the case ?
 All the best,
   Luis
  PS: I am using Wien2k-13

 2014-09-16 9:42 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 I have a suspicion that for some systems MSR1a does not do so well and
 it is associated with a large discrepancy in the new charge density
 (:NEC03). This may be a source of problems, or just a symptom. If you have
 cases where MSR1a was not bahaving so well can you please check this and
 let me know. Thanks.

 N.B., not sure what I can do about this, but identifying an issue is
 always the first step.

 ___
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu
 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





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


___
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] Hard charge convergence

[Luis Ogando]

Dear Prof. Tran,

   Thank you again !
   All the best,
  Luis


2014-09-02 17:32 GMT-03:00 t...@theochem.tuwien.ac.at:

 What is important for geometry optimization is to require also force
 convergence (-fc) with a value like 0.5 or 1 (see user's guide).



 On Tue, 2 Sep 2014, Luis Ogando wrote:

  Dear Professor Tran,

Thank you for your response.
Actually, I am doing structure optimization, so energy is the most
 important parameter (and forces due to free parameters). Perhaps, I am
 being
 too strict when asking for charge convergence during structure
 optimization.
 What is your opinion ?
Thank you again.
All the best,
  Luis


 2014-09-02 16:59 GMT-03:00 t...@theochem.tuwien.ac.at:
   Hi,

   It depends on your needs. Just use the command grep to see
   if the quantity you are interested in particular (e.g., magnetic
   moment
   or band gap) seems to have reached a degree of convergence
   which satisfies you.

   F. Tran

   On Tue, 2 Sep 2014, Luis Ogando wrote:

 Dear Wien2k community,

I would like some general hints for a system with
 a difficult charge convergence.
In my case, I got the energy convergence (-ec
 0.0001), but not the charge one (-cc 0.0001).
Would it be acceptable to increase the charge
 convergence criterion to -cc 0.0005 ? I am getting
 charge changes bellow this value.
All the best,
 Luis


 ___
 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

[Wien] Hard charge convergence

[Luis Ogando]

Dear Wien2k community,

   I would like some general hints for a system with a difficult charge
convergence.
   In my case, I got the energy convergence (-ec 0.0001), but not the
charge one (-cc 0.0001).
   Would it be acceptable to increase the charge convergence criterion to
-cc 0.0005 ? I am getting charge changes bellow this value.
   All the best,
Luis
___
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] Hard charge convergence

[Luis Ogando]

Dear Professor Tran,

   Thank you for your response.
   Actually, I am doing structure optimization, so energy is the most
important parameter (and forces due to free parameters). Perhaps, I am
being too strict when asking for charge convergence during structure
optimization. What is your opinion ?
   Thank you again.
   All the best,
 Luis


2014-09-02 16:59 GMT-03:00 t...@theochem.tuwien.ac.at:

 Hi,

 It depends on your needs. Just use the command grep to see
 if the quantity you are interested in particular (e.g., magnetic moment
 or band gap) seems to have reached a degree of convergence
 which satisfies you.

 F. Tran


 On Tue, 2 Sep 2014, Luis Ogando wrote:

  Dear Wien2k community,

I would like some general hints for a system with a difficult charge
 convergence.
In my case, I got the energy convergence (-ec 0.0001), but not the
 charge one (-cc 0.0001).
Would it be acceptable to increase the charge convergence criterion to
 -cc 0.0005 ? I am getting charge changes bellow this value.
All the best,
 Luis


 ___
 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] pbs_tmrsh x ssh

[Luis Ogando]

Hi,

   Another link that can be useful is:

http://www.open-mpi.org/faq/?category=building#build-rte-tm

   Anyway, I will try it and let you know the results.
   All the best,
 Luis



2014-07-23 18:30 GMT-03:00 Gavin Abo gs...@crimson.ua.edu:

  It seems to me that pbs_tmrsh is only available on systems that have PBS
 Professional.

 There is information about it in the PBS Professional support
 documentation (Reference Guide and User Guide) on Altair's PBS Works
 website:

 http://www.pbsworks.com/(S(k4q1hy4krq5yn3rw0qjyvcmg))/SupportDocuments.aspx

 I would say replace ssh by pbs_tmrsh in siteconfig and see what happens;
 either it works as an ssh replacement or it doesn't.


 On 7/23/2014 2:43 PM, Laurence Marks wrote:

 Hint: man pbs_tmrsh. I don't have it, and in fact I cannot find a web
 page with it anywhere. If you can find a link post it?


 On Wed, Jul 23, 2014 at 3:07 PM, Luis Ogando lcoda...@gmail.com wrote:

  Dear Wien2k community,


 SSH is forbidden in my computation center due to misuse.
I tried the hopen suggestion given by Prof. Marks to circumvent the
 ssh use without success.
By now, I am only able to use one cluster node each time (as in a SMP
 machine), but the guys from computation center said that pbs_tmrsh could be
 a possible alternative to ssh among the nodes.
Well, I would like to know if someone has any experience in using
 pbs_tmrsh with Wien2k. Any hint or advice ?
All the best,
  Luis




  --
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu 1-847-491-3996
 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


___
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] pbs_tmrsh x ssh

[Luis Ogando]

Hi Prof. Marks, Gavin and others,

   Wien2k is finally running in more than one node without ssh.
   My steps:

1) I rebuilt the OpenMPI wrappers with  --with-tm  option in configure.
This should work for PBS Pro , Open PBS and Torque (
see   http://www.open-mpi.org/faq/?category=building#build-rte-tm   ).

2) I believe that this will influence only mpirun, but, in any case, I
recompiled FFTW and Wien2k with the new wrappers.

3) As it is advised not to use pbs_tmrsh when OpenMPI is built
with --with-tm option, I set USE_REMOTE to 0 in the parallel_options file.
This avoids ssh or equivalent commands during Wien2k execution.

   The only issue is that if I want to use -it and a combination of K-point
and MPI parallelizations, I have to set the scratch to the local directory.
   I hope that this information may be useful for others.
   All the best,
Luis


2014-07-24 8:45 GMT-03:00 Luis Ogando lcoda...@gmail.com:

 Hi,

Another link that can be useful is:

 http://www.open-mpi.org/faq/?category=building#build-rte-tm

Anyway, I will try it and let you know the results.
All the best,
  Luis



 2014-07-23 18:30 GMT-03:00 Gavin Abo gs...@crimson.ua.edu:

  It seems to me that pbs_tmrsh is only available on systems that have
 PBS Professional.

 There is information about it in the PBS Professional support
 documentation (Reference Guide and User Guide) on Altair's PBS Works
 website:


 http://www.pbsworks.com/(S(k4q1hy4krq5yn3rw0qjyvcmg))/SupportDocuments.aspx

 I would say replace ssh by pbs_tmrsh in siteconfig and see what happens;
 either it works as an ssh replacement or it doesn't.


 On 7/23/2014 2:43 PM, Laurence Marks wrote:

 Hint: man pbs_tmrsh. I don't have it, and in fact I cannot find a web
 page with it anywhere. If you can find a link post it?


 On Wed, Jul 23, 2014 at 3:07 PM, Luis Ogando lcoda...@gmail.com wrote:

  Dear Wien2k community,


 SSH is forbidden in my computation center due to misuse.
I tried the hopen suggestion given by Prof. Marks to circumvent the
 ssh use without success.
By now, I am only able to use one cluster node each time (as in a SMP
 machine), but the guys from computation center said that pbs_tmrsh could be
 a possible alternative to ssh among the nodes.
Well, I would like to know if someone has any experience in using
 pbs_tmrsh with Wien2k. Any hint or advice ?
All the best,
  Luis




  --
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu 1-847-491-3996
 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



___
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] pbs_tmrsh x ssh

[Luis Ogando]

Dear Wien2k community,


   SSH is forbidden in my computation center due to misuse.
   I tried the hopen suggestion given by Prof. Marks to circumvent the
ssh use without success.
   By now, I am only able to use one cluster node each time (as in a SMP
machine), but the guys from computation center said that pbs_tmrsh could be
a possible alternative to ssh among the nodes.
   Well, I would like to know if someone has any experience in using
pbs_tmrsh with Wien2k. Any hint or advice ?
   All the best,
 Luis
___
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] (no subject)

[Luis Ogando]

Hi Sikander,

   Try to accept the case.struct suggested by sgroup and see what happens.
   Other option is to use x patchsymm and use the case.struct generated.
   You have a problem with the symmetry operations. Have you edited the
case.struct keeping the previous symmetry operations ?
   All the best,
   Luis


2014-05-30 10:08 GMT-03:00 sikandar azam sikandar...@yahoo.com:

 Dear All
 I am doing the initialization but getting this problem,
  check in  .outputsgroup  for proper symmetry, compare
with your struct file and later with  .outputs
sgroup has also produced a new struct file based on your old one.
If you see warnings above, consider to use the newly generated
struct file, which you can view (edit) now.
 - continue with symmetry (old case.struct) or use/edit
 .struct_sgroup ? (c/e)
 c
symmetry(15:05:32) 0.000u 0.008s 0:00.02 0.0%   0+0k 256+64io
 1pf+0w
  -- ERROR --
  ERROR: (multiplicity of atom   1 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   2 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   3 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   4 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   5 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   6 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom   7 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   4  ISYM:   2  NSYM   4
  ERROR: Check your struct file withx sgroup
  -- ERROR --

 Please help me.
 with regards
 sikander



 ___
 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] SO coupling and mBJ

[Luis Ogando]

Dear Tran,

   Thank you for your comment.
   I am interested in extracting kp parameters (effective masses, ...) from
the calculated band structure. Do you believe that the bands can be
significantly deformed in theses results or the main effect should be a
rigid displacement of the bands ?
   All the best,
Luis


2014-05-30 13:45 GMT-03:00 t...@theochem.tuwien.ac.at:

 Maybe hybrid functionals, but the problem is that at the moment
 SOC can not be used with hybrid functionals.


 On Fri, 30 May 2014, Luis Ogando wrote:

  Dear Wien2k community,
I have successfully optimized GaN in the zinc blend phase using LSDA.
 After that, I got the band structure using LSDA and mBJ (P-semiconductor
 parameters : A=0.267, B=0.656 and e=1).
I noticed that mBJ significantly improves the band gap, but the SO
 splitting goes down from 12meV (LSDA) to 3 meV (mBJ). The experimental
 value
 is about 16 meV.
Well, I would like to know if there is some way to keep both quantities
 well described.
All the best,
 Luis



 ___
 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] SO coupling and mBJ

[Luis Ogando]

   What about the LSDA results ?
   Thanks,
Luis


2014-05-30 14:09 GMT-03:00 t...@theochem.tuwien.ac.at:

 Usually the effect does not consist of a rigid shift and in fact, mBJ
 does not seem that good for effective masses as shwon in these articles:

 http://journals.aps.org/prb/abstract/10.1103/PhysRevB.82.205212
 http://iopscience.iop.org/0953-8984/24/20/205503/
 http://scitation.aip.org/content/aip/journal/jap/114/18/10.1063/1.4829674



 On Fri, 30 May 2014, Luis Ogando wrote:

  Dear Tran,
Thank you for your comment.
I am interested in extracting kp parameters (effective masses, ...)
 from
 the calculated band structure. Do you believe that the bands can be
 significantly deformed in theses results or the main effect should be a
 rigid displacement of the bands ?
All the best,
 Luis


 2014-05-30 13:45 GMT-03:00 t...@theochem.tuwien.ac.at:
   Maybe hybrid functionals, but the problem is that at the moment
   SOC can not be used with hybrid functionals.

   On Fri, 30 May 2014, Luis Ogando wrote:

 Dear Wien2k community,
I have successfully optimized GaN in the zinc
 blend phase using LSDA.
 After that, I got the band structure using LSDA and
 mBJ (P-semiconductor
 parameters : A=0.267, B=0.656 and e=1).
I noticed that mBJ significantly improves the
 band gap, but the SO
 splitting goes down from 12meV (LSDA) to 3 meV
 (mBJ). The experimental value
 is about 16 meV.
Well, I would like to know if there is some way
 to keep both quantities
 well described.
All the best,
 Luis



 ___
 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] Wien2k stopped working

[Luis Ogando]

Dear Prof. Marks,

   Thank you very much for your comments.
   I suspect that sys_adm changed something they assumed harmless for
users.
   I will follow your suggestions.
   All the best,
 Luis


2014-05-29 10:19 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 Problems such as this are hard to help with remotely. It looks like
 something has gone wrong at the system level, and my guess is that it
 has one of two sources:

 a. Something has gone wrong with your account/directories. It could be
 as simple as your time allocation has expired, your password has been
 hacked or your .bashrc file has got corrupted. Check the basics, e.g.
 you can create a file, compile a simple program etc. While this is
 unlikely, you never know.

 b. There have been OS changes of some sort. Many sys_admins assume
 that users just employ the software that is provided, often using
 modules, and this is not compatible with how Wien2k runs. It may be
 that they have removed some of the libraries that you linked Wien2k
 against, changed how the nodes list is provided to you (which may
 break Machines2W). For instance, the overwriting of OMP_NUM_THREADS
 implies to me that someone has decided that of course you want to
 run using openmpi, which at least at the moment is not useful to you.
 (I know PB wants to change this, so sometime this statement may
 change.)

 Try some diagnostics to try and work out what has happened, for instance:
 * Compile something like hello world both mpi and non-mpi versions,
 then run it in a simple job.
 * Write a small script to interrogate the environment when you start a
 job, e.g. using commands such as ldd $WIENROOT/lapw1_mpi, env |
 grep -e MPI -e MKL as well as obvious ones such as ulimit, echo
 $PATH etc.
 * Check the cluster web-page, maybe they announced some changes.
 * Use ifort --version and similar, as well as which mpirun and
 similar -- maybe new.
 * If you know a friendly sys_admin ask them for general info. It is
 good to nurture someone.

 Of course, all of this may be totally wrong and you may have already
 sorted things out.


 On Wed, May 28, 2014 at 8:23 AM, Luis Ogando lcoda...@gmail.com wrote:
  Dear Wien2k community,
 
 I have Wien2k 13.1 installed in a SGI cluster using ifort, icc and
 Open
  MPI. The installation was a hard work (I would like to thank again the
 help
  from Prof. Lawrence Marks), but after all I have used Wien2k without
  problems for several months.
 I performed the first step of a long calculation and saved it in a
  different directory. When I tried the next step in the original
 directory,
  Wien2k crashed. After some tests, I decided to reinitialize the
 calculation
  from the beginning (in other words, to repeat the first step). To my
  surprise, I did not succeed even in this case and I would like to know if
  someone has faced such an unexpected problem.
 Please, find below some of the output files that I consider the most
  relevant ones.
 Finally, I would like to stress some points:
 
  1) lapw0 stops after more or less 7 minutes, but it took about 2 hours in
  the successful calculation.
 
  2) lapw1 stops after 5 seconds without generating the case.energy_* files
  and case.dayfile does not contain the time statistic for each processor.
 
  3) OMP_NUM_THREADS=12 is overwritten by the system (in my .bashrc I have
  OMP_NUM_THREADS=1), but even when I export this variable equal to 1 in
 the
  submission script, I get the same crash.
 
 Thank you very much for your attention,
Luis
  ===
  :log file
 
(init_lapw) options:
  Wed Apr  2 14:07:30 BRT 2014 (x_lapw) nn -f InPzb15InPwurt3-V2
  Wed Apr  2 14:07:46 BRT 2014 (x) nn
  Wed Apr  2 14:08:03 BRT 2014 (x) sgroup
  Wed Apr  2 14:08:23 BRT 2014 (x) symmetry
  Wed Apr  2 14:08:48 BRT 2014 (x) lstart
  Wed Apr  2 14:09:38 BRT 2014 (x) kgen
  Wed Apr  2 14:09:58 BRT 2014 (x) dstart -c -p
(initso_lapw) options:
  Tue May 27 16:07:00 BRT 2014 (x) Machines2W
(run_lapw) options: -p -NI -ec 0.0001 -cc 0.0001 -i 150 -it
  Tue May 27 16:07:00 BRT 2014 (x) lapw0 -p
  Tue May 27 16:14:10 BRT 2014 (x) lapw1 -it -p -c
  Tue May 27 16:14:15 BRT 2014 (x) lapw2 -p -c
 
  ===
  case.dayfile
 
  Calculating InPzb15InPwurt3-V2 in
 
 /home/ice/proj/proj546/ogando/Wien/Calculos/InP/InPzbInPwurt/15camadasZB+3WZ/InPzb15InPwurt3-V2
  on r1i0n15 with PID 6538
  using WIEN2k_13.1 (Release 17/6/2013) in
  /home/ice/proj/proj546/ogando/Wien/Executaveis-13-OpenMPI
 
 
  start (Tue May 27 16:07:00 BRT 2014) with lapw0 (150/99 to go)
 
  cycle 1 (Tue May 27 16:07:00 BRT 2014) (150/99 to go)
 
lapw0 -p (16:07:00) starting parallel lapw0 at Tue May 27 16:07:00 BRT
  2014
   .machine0 : 12 processors
  2540.314u 12.204s 7:09.36 594.4% 0+0k 180672+52736io 5pf+0w
lapw1 -it -p   -c (16:14:10) starting parallel lapw1 at Tue May 27

[Wien] Open MPI

[Luis Ogando]

Dear Wien2k Community,

   Just a quick question, what is the recommended version of Open MPI ?
   All the best,
Luis
___
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] Open MPI

[Luis Ogando]

Dear Laurence,

   Thank you very much again.
   All the best,
   Luis


2014-05-27 9:20 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 Not an easy question to answer. The trivial answer is one which works, but
 that won't help you!

 I have seen problems with anything before 1.4.3, so don't use an early
 one. I would recommend looking at the latest release of the one back
 stable version which I think is 1.6.5 as this is probably a patched 
 somewhat stable version, and the latest ( http://www.open-mpi.org 1.8 ?).

 One thing that may be important is to use a version compiled with the same
 compiler as you use for Wien2k. The command ompi_info -c is useful, also
 look at ompi_info -h.

 N.B., so long as you are familiar with using conventional ./configure
 scripts compiling is simple. Really tweaking it for best performance is a
 sys_admin job and well beyond me.

 __
 Laurence Marks
 Dept Mat Sci  Eng
 Northwestern University
 www.numis.northwestern.edu
 847 491 3996
 On May 27, 2014 6:51 AM, Luis Ogando lcoda...@gmail.com wrote:

  Dear Wien2k Community,

 Just a quick question, what is the recommended version of Open MPI ?
All the best,
 Luis


 ___
 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] convergence problem :: runsp_c_lapw

[Luis Ogando]

Dear Prof. Marks,

   Just a quick question: if someone reduce the greed to a very low value
but go back to the default values in case.inm for the last iterations, is
it safe ?
   All the best,
   Luis


2014-04-24 9:15 GMT-03:00 Laurence Marks l-ma...@northwestern.edu:

 Why did you change case.inm away from the defaults?

 a) Set the greed to 0.2 not 0.005. As I have said before, this does
 not do what you think it does and concepts such as reduce the mixing
 factor if it does not converge are wrong. Yes, wrong. Very wrong.
 Completely wrong. Always wrong. To understand more please read Journal
 of Chemical Theory and Computation 9 (2013) 2786.

 b) Use MSR1, and in extreme cases perhaps MSEC3. Do not use BROYD.
 Perhaps reduce the greed to 0.1, almost never less than this.

 A little explanation. The factor of 0.005 is called the mixing
 greed.in the spirit of algorithm greed (e.g.
 http://en.wikipedia.org/wiki/Greedy_algorithm). If it is too large the
 self-consistent iterations can become unstable. However, you rarely
 need to deal with this and the mixer does. If you set it too a small
 value (which you did) you are making the algorithm take such tiny
 steps that it can starve to death. The code honors the user setting
 of a very small value (at least in 12.1) under the assumption that the
 user knows what he/she is doing.

 On Thu, Apr 24, 2014 at 5:25 AM, Martin Gmitra martin.gmi...@gmail.com
 wrote:
  Dear Wien2k users,
 
  I am doing calculations of a hexaboride films invoking: runsp_c_lapw -so
  -eece
  My problem is two fold:
 
  (i) SCF calculations successfully converged for thin films (9 atomic
 units)
  and bulk systems. I do have a problem to converge a thicker film (11
 atomic
  units) even TEMP broadening of 0.02 is used. The observations after 800
  iterations are following:
 
  (1) fermi energy is jumping (roughly) between two values
  :FER  : F E R M I - ENERGY(FERMI-SM.)=   0.3682855520
  :FER  : F E R M I - ENERGY(FERMI-SM.)=   0.3682855520
  :FER  : F E R M I - ENERGY(FERMI-SM.)=  -0.7779431003
  :FER  : F E R M I - ENERGY(FERMI-SM.)=  -0.7779431003
  :FER  : F E R M I - ENERGY(FERMI-SM.)=   0.3683943150
  :FER  : F E R M I - ENERGY(FERMI-SM.)=   0.3683943150
  :FER  : F E R M I - ENERGY(FERMI-SM.)=  -0.7767634505
  :FER  : F E R M I - ENERGY(FERMI-SM.)=  -0.7767634505
 
  (2) charge distance non uniformly oscillates between 0.1 and 0.001
  :DIS  :  CHARGE DISTANCE   ( 1.1067771 for atom4 spin 1)
  0.1064425
  :DIS  :  CHARGE DISTANCE   ( 0.0059078 for atom6 spin 1)
  0.0013328
  :DIS  :  CHARGE DISTANCE   ( 0.0092322 for atom6 spin 1)
  0.0015769
  :DIS  :  CHARGE DISTANCE   ( 0.0092664 for atom6 spin 1)
  0.0015106
  :DIS  :  CHARGE DISTANCE   ( 0.5478509 for atom4 spin 1)
  0.0466613
  :DIS  :  CHARGE DISTANCE   ( 0.0078766 for atom6 spin 1)
  0.0014700
  :DIS  :  CHARGE DISTANCE   ( 0.9814094 for atom4 spin 1)
  0.0939173
  :DIS  :  CHARGE DISTANCE   ( 0.0070829 for atom6 spin 1)
  0.0015672
  :DIS  :  CHARGE DISTANCE   ( 0.0411319 for atom4 spin 2)
  0.0053433
  :DIS  :  CHARGE DISTANCE   ( 0.0072009 for atom6 spin 1)
  0.0014308
  :DIS  :  CHARGE DISTANCE   ( 0.1357701 for atom4 spin 2)
  0.0150618
 
  (3) magnetic moments are zero within spheres whereas there is
  :MMTOT: SPIN MAGNETIC MOMENT IN CELL   =-0.00010
  :MMINT: MAGNETIC MOMENT IN INTERSTITIAL =   -0.3
 
  (4) my case.inm
  BROYD  0.0   YES  (BROYD/PRATT, extra charge (+1 for additional e), norm)
  0.005   mixing FACTOR for BROYD/PRATT scheme
  1.00  1.00  PW and CLM-scaling factors
    8 idum, HISTORY
 
  :MIX  :   MSEC3  REGULARIZATION: 2.50E-04  GREED: 0.005  Newton 1.000
  with PRATT after 100 iterations
  MIX  :   PRATT  REGULARIZATION: 2.50E-04  GREED: 0.005
 
  Do you have any hints how to converge the calculations?
 
  (ii) I am running the calculations with version 12.1. The runsp_c_lapw
  script has been updated (debugged) in version 13.1 but SCF diverges in my
  cases (thin and thicker films).
 
  Does anybody experience similar problem?
 
  Best regards,
  Martin Gmitra
  Uni Regensburg
 
 
 



 --
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu 1-847-491-3996
 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

___
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] Need help

[Luis Ogando]

Hi Khan,

   Did you apply  x patchsymm?
   All the best,
  Luis


2014-04-15 6:21 GMT-03:00 kalsoom Khan kkkhan.qu...@yahoo.com:

 Dear all
 I am making the supercell but when i doped an atom.. i get this problem

  ERROR: (multiplicity of atom  20 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   2  ISYM:   2  NSYM   2
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom  21 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   2  ISYM:   2  NSYM   2
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom  22 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   2  ISYM:   2  NSYM   2
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom  23 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   2  ISYM:   2  NSYM   2
  ERROR: Check your struct file withx sgroup
  -- ERROR --
  -- ERROR --
  ERROR: (multiplicity of atom  24 )*(number of
 pointgroup-operations)
  ERROR: is NOT = (number of spacegroup-operations)
  ERROR: MULT:   2  ISYM:   2  NSYM   2
  ERROR: Check your struct file withx sgroup
  -- ERROR --
 - check in  Case.outputs  the symmetry operations,
the point symmetries and compare with results from sgroup
if you find errors (often from rounding errors of positions), apply
 x patchsymm
 - continue with lstart or edit the Case.struct_st file (c/e/x)
 c
 STOP: YOU MUST FIX your struct file
 YOU SHOULD PROBABLY ACCEPT THE STRUCT-FILE FROM SGROUP (
 Case.struct_sgroup )
 AND/OR APPLY  x patchsymm; cp Case.struct_patchsymm Case.struct


 Please help me.
 With regards
 KKHAN



 ___
 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] PHONOPY and symmetry

[Luis Ogando]

Dear WIEN2k community,

   I am trying to use PHONOPY to calculate phonon dispersion curves for InP
in the zincblend phase as a test. I used an optimized structural parameter
to build a 3x3x3 supercell using the supercell utility program. After
that, PHONOPY built two other supercells displacing atoms 1 and 109 by 0.02
Bohr along x direction.
   Now, it is important to say that PHONOPY works with P1 symmetry, what
means I can use the new cell suggested by nn, but not the one suggested
by sgroup during initialization.
   Everything went smoothly when I initialized the calculation for the
first supercell (that one with displacement for atom 1) accepting twice the
cell generated by nn, but I got the following error message for the
second cell (that one with displacement for atom 109).
   Finally, I would like to mention that if I accept the cell suggested by
sgroup, everything goes fine for the second cell, but this is not
suitable for PHONOPY as mentioned above.
   I would appreciate any help with this issue.
   The case.struct is too big for the mailing list (64 KB), but I can send
it to the personal e-mail of anyone interested in.
   The error message is at the end of this message.
   All the best,
 Luis



-- ERROR --
 ERROR: (multiplicity of atom  31 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  32 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  33 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  37 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   1  ISYM:   2  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  38 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   1  ISYM:   2  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  39 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   1  ISYM:   2  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  52 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  53 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  54 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   2  ISYM:   1  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  63 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   1  ISYM:   2  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  64 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT:   1  ISYM:   2  NSYM   4
 ERROR: Check your struct file withx sgroup
 -- ERROR --
 -- ERROR --
 ERROR: (multiplicity of atom  65 )*(number of
pointgroup-operations)
 ERROR: is NOT = (number of spacegroup-operations)
 ERROR: MULT: