[Wien] Warning in lapw1

[Laurence Marks]

There is no evidence that this matters. In principle one can increase
CLUSTERSIZE and I once added something to dynamically do this but it
did not seem to matter. Ignore it.

2011/6/3 David Tompsett :
> Dear All,
>
> I have recently compiled the latest Wien2k 11 release, but have come across
> an unusual warning in case.output1 when running some larger cases (30 atoms
> or more):
>
> :WARN :? WARNING: Not all eigenvectors are orthogonal
> ?Eigenvalue clusters in eigensolver = 703??? 2153
> 0?? 0?? 0 \
> ? 0?? 0?? 0?? 0?? 0
> 0?? 0?? 0?? \
> ??? 0?? 0?? 0?? 0?? 0
> 0?? 0?? 0 \
> ? 0?? 0?? 0?? 0?? 0
> 0?? 0?? 0?? \
> ??? 0?? 0?? 0?? 0?? 0?? 0
> 0?? 0 \
> ? 0?? 0?? 0?? 0?? 0?? 0
> 0?? 0?? \
> 0?? 0?? 0
> ?Gap in eigensolver =? 1.05489827340396041E-004? -1.
> -1.??? \
> ?? -1.?? -1.
> -1.?? -1.00\
> 00?? -1.?? -1.
> -1.?? -1.\
> ?? -1.?? -1.
> -1.?? -1.00\
> 00?? -1.?? -1.
> -1.? \
> ?-1.?? -1.
> -1.?? -1.\
> ?? -1.?? -1.
> ?? Increase CLUSTERSIZE in SECLR4
> ?Seclr4(Cholesky complete (CPU)) :? 17.200??? 112001.02 Mflops
> ?Seclr4(Cholesky complete (WALL)) : 17.251??? 111672.48 Mflops
> ?Seclr4(Transform to eig.problem (CPU)) :?? 84.490 68401.62 Mflops
> ?Seclr4(Transform to eig.problem (WALL)) :? 85.192 67837.83 Mflops
> ?Seclr4(Compute eigenvalues (CPU)) :?? 213.210 36141.22 Mflops
> ?Seclr4(Compute eigenvalues (WALL)) :? 213.585 36077.74 Mflops
> ?Seclr4(Backtransform (CPU)) :?? 9.500 28964.20 Mflops
>
> This warning appeared in the first iteration of the SCF cycle. I note that
> the CLUSTERSIZE? is set to 600 in SECLR4, but don't understand why I see the
> warning here. Does anyone know what the cause is? I am running using MPI
> parallel over 24 cores. Will the parallelisation setup affect this cluster
> size problem?
>
> Thank you,
> David Tompsett.
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>



-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi

[Wien] Magnetic material relaxation, RMT, MAE calculations

[Jihoon Park]

Dear users,


I am really wondering if we have to "relax" structure everytime when
calculating magnetic materials.
When relaxed, the magnetic properties, especially K value, become too far
from experimental data; K value calculated from not relaxed structure is
also far from the experimental one.

I tried force theorem as well, but that is still far from the experimental
data too.

Everytime my calculated K value is reversed.
For example, energies for <001> and <100> are compared and used to calculate
K.
But I do not understand why the energy for <100> is lower than that of
<001>.
Experimentally, <001> is stable for MnAl.


And another qeustion is about RMT.
Is it okay to change RMT to fit experimental data?
I tried several times to fit experimental one, but still question myself if
that is okay.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/57277182/attachment.htm>

[Wien] lapw2

[van...@urisan.tche.br]

Dear users


 I'm worried because I can not run the program more wien 2k. The error is
always repeating itself. Problem may be the program
 Help

Calculating 3irfe in /home/vandao/meus/3irfe
on Fisica-Host-Wien2k with PID 3617

start   (Fri Jun  3 17:58:53 BRT 2011) with lapw0 (40/99 to go)

cycle 1 (Fri Jun  3 17:58:53 BRT 2011)  (40/99 to go)

>   lapw0   (17:58:53) 2.904u 0.040s 0:02.94 100.0% 0+0k 0+0io 0pf+0w
>   lapw1  -up  (17:58:56) 2.204u 0.324s 0:02.75 91.6%  0+0k 0+0io 
> 0pf+0w
>   lapw1  -dn  (17:58:58) 2.196u 0.320s 0:02.74 91.6%  0+0k 0+0io 
> 0pf+0w
>   lapw2 -up   (17:59:01) Segmentation fault
0.084u 0.004s 0:00.08 100.0%0+0k 0+0io 0pf+0w
error: command   /WIENROOT/lapw2 uplapw2.def   failed

>   stop error

[Wien] Where is Orbital moment?

[Jihoon Park]

Dear users,


I have calculated LS coupling with dm, but have not found where calculated
orbital moments are.
Would you please tell me where they are.


All my best,
Jihoon Park
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/7910692b/attachment.htm>

[Wien] MAE calculation

[Jihoon Park]

I have been calculating MAE using WIEN2k.

I have done the followings,
---
WFFIL
4  1  0  llmax,ipr,kpot
-10.   1.5   emin,emax (output energy window)
   0.  0.  1. direction of magnetization (lattice vectors)
0   number of atoms for which RLO is added
0 0 0 0 0number of atoms for which SO is switch
off;atoms
---

and dm as well.


I did not get any error, but everytime I calculate MAE, I get easy plane
results for MnAl.
I do not know what is wrong.

Please give me some advice.


Thank you.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/19f5e415/attachment.htm>

[Wien] Volume optimization and Struct File

[Judy Cherian]

Hello All,

I am working with the TiC example in the user guide. I run the StructGen
command, the SCF calculations and then do the volume optimization. I notice
that the case.struct file changes after volume optimization, however the
lattice parameter in case.struct file doesn't match up with the optimized
lattice parameter that is given by the .outputeos file.  If we want to
perform further calculations using a volume optimized structure, are we
supposed to use the updated case.struct file that the program creates, or do
we need to manually edit the case.struct file to provide the optimized
lattice parameter given in the .outputeos file?


Judy Cherian

Graduate Student
Florida State University/NHMFL
Tallahassee, FL
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/768d81f0/attachment.htm>

[Wien] Magnetic properties or 5d metals

[Peter Blaha]

If it gives a small U for a 5d system, it gives the expected result.

The method is reliable if   a)  most of the considered electrons (5d) are 
localized
within the atomic sphere and b) is only reliable when "LDA+U is appicable, that 
means
if "atomic physics" dominates and states are localized similar as in an atom.

Spin-orbit ??


Am 02.06.2011 14:13, schrieb Pablo de la Mora:
> Dear WIEN users,
> Compounds with 5d metals have magnetic properties, but due to the extended 
> nature of the 5d orbitals the calculations give non-magnetic results, 
> includding the Hubbard U (Uh).
> I have calculated the Uh using the method proposed by G. Madsen and P. Novak:
> Notes about constraint LDA calculations to determine U 
> 
> which gives me a small Uh.
> To stabilize the magnetic state I need to use an unphysically large Uh. Any 
> suggestions?
>
> Is this method suggested by Madsen and Novak accurate?
> I have used in other compounds and it seems to give reasonable results, but 
> these notes are not very clear (I could expand some issues in the notes to 
> make them clearer).
>
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/
--

[Wien] new optimization scheme

[Lyudmila V. Dobysheva]

Thank you, dear Laurence and Peter.

> In the case you gave there is nothing fixing the origin naturally
> along the z axis (I suspect). 

Yes, and the cell really seems to move freely during the process. I see which 
atom to pin.

Do I understand correctly:
If there exists a force in :FSUM (:FCHECK), it means that we should pin the 
cell in this direction.
The line "Note: symmetry trapping" means only absence of inversion.

Best regards
  Lyudmila Dobysheva 
--
Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
426001 Izhevsk, ul.Kirova 132
RUSSIA
--
Tel.:7(3412) 442118 (home), 218988(office), 250614(Fax)
E-mail: lyu at otf.pti.udm.ru
lyuka17 at mail.ru
lyu at otf.fti.udmurtia.su
http://fti.udm.ru/content/view/25/103/lang,english/
--

[Wien] new optimization scheme

[Peter Blaha]

If you have inversion symmetry, then   :FSUM should always be exactly zero,
even when you have only partial (or wrong) forces.

If you do not inversion, :FSUM should still be zero, but due to non-scf 
conditions
or other problems with basis sets,... it might not be the case.
The  whole set of atoms could then "accelerate" and move freely through your 
unit
cell (at least in one direction; since symmetry does not change in such cases).
Fixing ONE atom would then avoid such movements.

Am 03.06.2011 13:06, schrieb Lyudmila V. Dobysheva:
> Thank you, dear Laurence and Peter.
>
>> In the case you gave there is nothing fixing the origin naturally
>> along the z axis (I suspect).
>
> Yes, and the cell really seems to move freely during the process. I see which
> atom to pin.
>
> Do I understand correctly:
> If there exists a force in :FSUM (:FCHECK), it means that we should pin the
> cell in this direction.
> The line "Note: symmetry trapping" means only absence of inversion.
>
> Best regards
>Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 442118 (home), 218988(office), 250614(Fax)
> E-mail: lyu at otf.pti.udm.ru
>  lyuka17 at mail.ru
>   lyu at otf.fti.udmurtia.su
> http://fti.udm.ru/content/view/25/103/lang,english/
> --
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/
--

[Wien] Warning in lapw1

[David Tompsett]

Dear All,

I have recently compiled the latest Wien2k 11 release, but have come across
an unusual warning in case.output1 when running some larger cases (30 atoms
or more):

:WARN :  WARNING: Not all eigenvectors are orthogonal
 Eigenvalue clusters in eigensolver = 7032153
0   0   0 \
  0   0   0   0   0
0   0   0   \
0   0   0   0   0
0   0   0 \
  0   0   0   0   0
0   0   0   \
0   0   0   0   0   0
0   0 \
  0   0   0   0   0   0
0   0   \
0   0   0
 Gap in eigensolver =  1.05489827340396041E-004  -1.
-1.\
   -1.   -1.
-1.   -1.00\
00   -1.   -1.
-1.   -1.\
   -1.   -1.
-1.   -1.00\
00   -1.   -1.
-1.  \
 -1.   -1.
-1.   -1.\
   -1.   -1.
   Increase CLUSTERSIZE in SECLR4
 Seclr4(Cholesky complete (CPU)) :  17.200112001.02 Mflops
 Seclr4(Cholesky complete (WALL)) : 17.251111672.48 Mflops
 Seclr4(Transform to eig.problem (CPU)) :   84.490 68401.62 Mflops
 Seclr4(Transform to eig.problem (WALL)) :  85.192 67837.83 Mflops
 Seclr4(Compute eigenvalues (CPU)) :   213.210 36141.22 Mflops
 Seclr4(Compute eigenvalues (WALL)) :  213.585 36077.74 Mflops
 Seclr4(Backtransform (CPU)) :   9.500 28964.20 Mflops

This warning appeared in the first iteration of the SCF cycle. I note that
the CLUSTERSIZE  is set to 600 in SECLR4, but don't understand why I see the
warning here. Does anyone know what the cause is? I am running using MPI
parallel over 24 cores. Will the parallelisation setup affect this cluster
size problem?

Thank you,
David Tompsett.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/48350205/attachment.htm>

[Wien] DOS

[van...@urisan.tche.br]

Dear Users

 I'm calculating the El Dens. but the error message appears.

Commandline: x lapw2 -emin -1.0 -up
Program input is: " "

Segmentation fault
0.076u 0.004s 0:00.08 87.5% 0+0k 0+0io 0pf+0w
error: command   /WIENROOT/lapw2 uplapw2.def   failed







 help

[Wien] problem with lapw2

[水牧 仁一朗]

Dear WIEN2k users,

I have this problem when I run w2web.
I calculate the band of ferromagnetic material CaCu3Fe4O12 with the space group 
#204(Im-3).

I show the error message as follows.
error: command /home/mizumaki/wien2k/lapw2 uplapw2.def failed
> stop error

Please can someone help me to overcome this problem ?

Best regards,

On 2011/01/18, at 18:57, Peter Blaha wrote:

> The error message is misleading. It stems from the time where we detected 
> from the
> case.inst file the value for "case" in parallel-calculations .
> 
> Nowadays this is done by:
> 
> setenv PWD $cwd
> set case= $PWD
> set case= $case:t
> if ($case == "") then
> echo "ERROR: no case.inst-file -> exit"
> 
> This means from the name of the "current working directory".
> 
> The error could be caused by a missing "directory" (filesystem) on the remote 
> computer.
> Either the filesystem where your calculation resides is not mounted on one of 
> the
> remote computers, or the NFS system is overloaded and temporarely cannot give 
> byk the information,
> 
> Try to use a SCRATCH variable pointing to a local directory to reduce NFS 
> traffic.
> 
> 
> Am 18.01.2011 08:53, schrieb Aboudi Hamouda:
>> Dear Wien2k users,
>> I have this problem when I run parallel calculations. This arrive only with 
>> some systems and not all the systems. ..
>> -> starting parallel LAPW1 jobs at Mon Jan 17 23:27:58 AST 2011
>> running LAPW1 in parallel mode (using .machines.help)
>> 4 number_of_parallel_jobs
>> cn030(2) 283.001u 0.695s 4:44.13 99.85% 0+0k 0+0io 0pf+0w
>> cn030(2) 286.373u 1.008s 4:47.76 99.87% 0+0k 0+0io 0pf+0w
>> cn030(2) 296.787u 0.532s 4:57.78 99.85% 0+0k 0+0io 0pf+0w
>> cn030(2) 281.630u 1.117s 4:43.13 99.86% 0+0k 0+0io 0pf+0w
>> cn030(1) 128.725u 0.353s 2:09.25 99.86% 0+0k 0+0io 0pf+0w
>> cn030(1) 125.805u 0.524s 2:06.68 99.72% 0+0k 0+0io 0pf+0w
>> Summary of lapw1para:
>> cn030 k=10 user=1402.32 wallclock=1408.73
>> 0.259u 0.479s 6:57.75 0.1% 0+0k 0+0io 0pf+0w
>>> lapw2 -up -p (23:34:55) running LAPW2 in parallel mode
>> ERROR: no case.inst-file -> exit
>> 0.009u 0.023s 0:00.06 33.3% 0+0k 0+0io 0pf+0w
>> error: command /home/aboudi/wien2k/lapw2para -up uplapw2.def failed
>> 
>>> stop error
>> 
>> It seems that wien2k can't find inst file. when I check my directory, I see 
>> the inst file. Please can someone help me to overcome this problem ?
>> Best regards,
>> 
>> 
>> 
>> 
>> ___
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> 
> -- 
> 
> P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
> Email: blaha at theochem.tuwien.ac.atWWW: 
> http://info.tuwien.ac.at/theochem/
> --
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

----
?679-51981-1-1

??
?
Tel:  0791-58-0802-3870
Fax: 0791-58-0830
E-mail: mizumaki at spring8.or.jp
--

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/164eea64/attachment.htm>

[Wien] new optimization scheme

[Lyudmila V. Dobysheva]

Dear WIEN developers,

I started using the new optimization scheme that is in mixer (MSR1a). In one 
calculation I had lines
:FSUM  : Sum of forces Fx,Fy,Fz   0.0   0.0   0.0
(and it worked well)

Another calculation has lines like (1):
:FSUM  : Sum of forces Fx,Fy,Fz   0.0   0.0  -1466.20200 
and in addtion some remark just after :RTO lines  (2):
Note: symmetry trapping
I do not know yet whether it works good as the process is going on. Energy is 
decreasing, but forces still not.

What these 1 and 2 mean and aren't they bad?

Best regards
  Lyudmila Dobysheva 
--
Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
426001 Izhevsk, ul.Kirova 132
RUSSIA
--
Tel.:7(3412) 442118 (home), 218988(office), 250614(Fax)
E-mail: lyu at otf.pti.udm.ru
lyuka17 at mail.ru
lyu at otf.fti.udmurtia.su
http://fti.udm.ru/content/view/25/103/lang,english/
--

[Wien] LAPW2 problem

[AJAY SINGH VERMA]

Respected all users,
I am trying to reproduce the results of a paper, related to compound ZnCdTe2 
chalcopyrite compound. We are using WIEN_11_executables to run the choosing 
system.
But when i use run_lapw on the command prompt i got the following error
Sir their occurs some error in LAPW2

asverma at ubuntu:~/work/ZnCdTe2$ run_lapw
hup: Command not found.
 LAPW0 END
 LAPW1 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred

Stack trace terminated abnormally.

>   stop error
asverma at ubuntu:~/work/ZnCdTe2$ 
Sir please help and suggest why it is so and how to remove this. 
Thanking you
A. S. Verma
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/4e2fd3cc/attachment.htm>

[Wien] Compilation problems on Red Hat 4 with G95/gfortran and gotolib

[Peter Blaha]

The password is stored in   $HOME/.w2wb/your_hostname/conf/w2web.users

Most likely you can use

htpasswd2 -b  HOME/.w2wb/your_hostname/conf/w2web.usersusername password
to add/change it.


Am 02.06.2011 16:41, schrieb Osbaldeston, Ryan:

> Do you also know how to change the admin/password for w2web? I need to change 
> it from my credentials to that of the client.

-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/
--

[Wien] LAPW2 problem

[AJAY SINGH VERMA]

Respected all users,
I am trying to reproduce the results of a paper, related to compound ZnCdTe2 
chalcopyrite compound. We are using WIEN_11_executables to run the choosing 
system.
But when i use run_lapw on the command prompt i got the following error
Sir their occurs some error in LAPW2

asverma at ubuntu:~/work/ZnCdTe2$ run_lapw
hup: Command not found.
 LAPW0 END
 LAPW1 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred

Stack trace terminated abnormally.

>   stop error
asverma at ubuntu:~/work/ZnCdTe2$ 
Sir please help and suggest why it is so and how to remove this. 
Thanking you
A. S. Verma
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/6070b2a0/attachment.htm>

[Wien] Compilation problems on Red Hat 4 with gfortran and gotolib

[Peter Blaha]

a) Please note: when you do not use ifort you probably loose half of the speed 
of the
calculations.
b) when using "-lblas_lapw -llapack_lapw"  you are using probably another 
factor of ~5,
so in total your calculations on a fancy new machine will run at the speed of a 
10 year
old processor.

In any case, start out the installation   WITHOUT mpi first (do you have a 
cluster with infiniband
or only a single machine where mpi is not useful anyway??).

Does the sequential compilation work ? It can always happen that there are some 
small
incompatibilities between WIEN2k   and   gfortran; in particular gfortran 
supports by
default only rather "short" lines  (check previous postings on the mailing list 
about
gfortran).

If there are errors, do not
attach a list of all (identical) error (this will exhaust us) nor include
all compile.msg  files, but you have to READ them yourself and if the
messages do not help, provide the essential details. Just a list of "ERROR" 
lines
is NOT enough like:
 > SRC_lapw0/compile.msg:make[1]: *** [lapw0_mpi] Error 1
 > SRC_trig/compile.msg:Error: Attribute at (1) is not allowed in a TYPE 
 > definition

but in the compile.msg files there is more info (which line,)

--
Some specific comments follow below, where you have given enough info:

If you want to link a library, which is NOT in any of the default pathes, you 
have to
provide the directories where these libraries are located. This can be done 
using eg.
-L/opt/GotoBLAS2/  and of course it should not be -lgoto but either -lgoto2 or 
-lgoto2_nehalemp-r1.13
and similar you need to specify the directories for your mpi (-lpblas) 
compilation.

> Fortran Compiler: gfortran
> C Compiler: CC
> goto Libraries: /opt/GotoBLAS2/libgoto2.so
>   /opt/GotoBLAS2/libgoto2.a
>   /opt/GotoBLAS2/libgoto2_nehalemp-r1.13.so
> NOTE: recommended for R_LIB is -llapack_lapw -lgoto -llapack_lapw but lgoto 
> doesn't exist in SRC_lib like lapack does and I assumed that blas, which is 
> located in SRC_lib, is what you are looking for since blas is called gotoblas.


> Then when examining the individual compile.msg files I found the pertinent 
> information to be:
> In SRC_lapw0:
> mpif90 -o lapw0_mpi cputim.o modules.o reallocate.o ainv.o am05_xscss.o b88.o 
> blyp.o brj.o charg2.o  charg3.o charge.o chfac.o chslv.o corgga.o 
> corpbe_revtpss.o corpbe_tpss.o cub_xc_back.o corlsd.o dfxhpbe.o dfxrevtpss.o 
> dfxtpss.o drho.o dylm.o efg.o energy.o epot1.o eramps.o errclr.o errflg.o 
> ev92.o ev92ex.o exch.o exch17.o fftw_para.o fithi.o fxhpbe.o fx_revtpss.o 
> fx_tpss.o gbass.o gcor.o gea.o geaex.o  getff1.o getfft.o gpoint.o gpointm.o 
> grans.o gtfnam.o hcth.o htbs.o ifflim.o kcis.o lapw0.o latgen.o multfc.o 
> multsu.o outerr.o pbea.o pbem.o pbe1.o pbe2.o pbesol.o poissn.o potfac.o 
> pwxad4.o pwxad5.o qranf.o readstruct.o rean0.o rean1.o rean3.o rean4.o 
> rhopw.o rotate.o rotdef.o rpbe.o setff0.o setff1.o setfft.o setff2.o seval.o 
> sevald.o sevaldd.o sevali.o sevalin.o sicpbe.o sicpbe_revtpss.o sicpbe_tpss.o 
> sogga.o sphbes.o spline.o srolyl.o stern.o sumfac.o suml.o SymmRot.o th1.o 
> th2.o vpw91.o vresp.o vs98.o vxc15.o vxc16.o vxc17.o vxc24.o vxc26.o vxclm2.o 
> vxcpw2.o vxi35.o 
vx
>   i35a.o wc05.o workf1.o xcener.o xcpot.o xcpot1.o xcpot3.o ykav.o  ylm.o 
> zfft3d.o  W2kutils.o W2kinit.o fftw_seq.o -ffree-form -O2 -L../SRC_lib 
> -lpthread -static  -L/usr/lib -L/usr/lib64 -lpblas -lredist -ltools 
> -lscalapack -lfblacs -lblacs -lmpi -L/opt/local/fftw/lib/ -lfftw_mpi -lfftw
> /usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for 
> -lpthread NOTE: This did not appear before I changed RP_LIB
> /usr/bin/ld: cannot find -lpblas  
>   NOTE: This DID appear before I 
> changed it and it made no difference

Rather clear after the explanations at the beginning. Errors of that sort are 
related
to your system.



> In SRC_lapw2: Errors like the following, may on them.
> In file qdmft_tmp_.F:433
>
>  chd=chd+REAL(dmftdm(ikk)%mat(i,i), KIND=8)*vnorm
> 1
> Error: 'mat' at (1) is not a member of the 'den_mat' structure

Rather unclear to me (though I'm not the author of this subroutine).
Maybe there is some previous error which explains this one ??
mat is a member of the den_mat structure (see line 20), but
maybe gfortran does not like the allocatable in the definition of a structure ?


> In SRC_mixer: Not even a clue what the error is here:
> Fprojmsec.o: In function `fprojmsec_':
> Fprojmsec.f:(.text+0x231): undefined reference to `dposvx_'

dposvx is part o lapack. So you did not link with a lapack library ...


> In SRC_telnes3: (NOTE: entire file text provided)
> gfortran  -ffree-form -O2  -c describetask.f
>   In file describetask.f:67
>
> 000),' mrad.
>  1
> Error: Unterminated character constant beginning at (1)

[Wien] new optimization scheme

[Peter Blaha]

The implementation of   :FSUM in WIEN2k_11 might not work properly in all cases.
Most likely, you can forget this statement (or estimate the sum of forces 
manually
taking into account eventually MULT > 1 !!!).
The next release should have this ok (and it will be called :FCHECK)

Am 03.06.2011 10:06, schrieb Laurence Marks:
> It is hard to say as you don't provide enough information.
> In the second case you apparently have a structure without a center 
> ofsymmetry and something very, very bad is going on along the z axis asthe 
> sum of forces should be zero with OK RKMAX/RMT etc.
> On Fri, Jun 3, 2011 at 2:27 AM, Lyudmila V. Dobysheva  
> wrote:>  Dear WIEN developers,>>  I started using the new optimization scheme 
> that is in mixer (MSR1a). In one>  calculation I had lines>  :FSUM  : Sum of 
> forces Fx,Fy,Fz   0.0   0.0   0.0>  (and it worked well)>>  
> Another calculation has lines like (1):>  :FSUM  : Sum of forces Fx,Fy,Fz   
> 0.0   0.0  -1466.20200>  and in addtion some remark just after :RTO 
> lines  (2):>  Note: symmetry trapping>  I do not know yet whether it works 
> good as the process is going on. Energy is>  decreasing, but forces still 
> not.>>  What these 1 and 2 mean and aren't they bad?>>  Best regards>
> Lyudmila Dobysheva>  
> -->  
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.>  426001 Izhevsk, 
> ul.Kirova 132>  RUSSIA>  
> -->  
> Tel.:7(3412) 442118 (home), 218988(office), 250614(F
ax)>  E-mail: lyu at otf.pti.udm.ru>  lyuka17 at mail.ru>  lyu 
at otf.fti.udmurtia.su>  http://fti.udm.ru/content/view/25/103/lang,english/>  
-->  
___>  Wien mailing list>  Wien at 
zeus.theochem.tuwien.ac.at>  
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>
>
> -- Laurence MarksDepartment of Materials Science and EngineeringMSE Rm 2036 
> Cook Hall2220 N Campus DriveNorthwestern UniversityEvanston, IL 60208, 
> USATel: (847) 491-3996 Fax: (847) 491-7820email: L-marks at northwestern dot 
> eduWeb: www.numis.northwestern.eduChair, Commission on Electron 
> Crystallography of IUCRwww.numis.northwestern.edu/Research is to see what 
> everybody else has seen, and to think whatnobody else has thoughtAlbert 
> Szent-Gyorgi___Wien mailing 
> listWien at 
> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/
--

[Wien] bug for spaghetti for monoclinic CXZ lattices AND spin-orbit

[Peter Blaha]

Igor Mazin posted a bug report that the coordinates of k-points in a 
bandstructure
calculation for a   monoclinic CXZ lattice   with and without spin-orbitare 
different.

I could verify this problem and in the present version the k-points  with SO 
are wrong.
(this concerns only the length of the different directions or the coordinates 
in case.spaghetti_ene).

Calculations for other symmetries, ... are not concerned.

I fixed the problem by modification of   SRC_lapw1/prtkpt.F  and 
SRC_spaghetti/cartco.f
which means that I adjusted spaghetti to be compatible with case.outputso, 
(which prints the
k-points in "conventional coordinates" instead of "primitive" ones, as given in 
case.klist),
but no longer with the "old" case.output1.

Thus, when you apply the change in spaghetti, you must also apply it in lapw1 
and
rerun the bandstructure (x lapw1 -band), since the output1 file needs to be 
different!!

Regards
-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671 FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.atWWW: http://info.tuwien.ac.at/theochem/
--
-- next part --
A non-text attachment was scrubbed...
Name: prtkpt.F
Type: text/x-fortran
Size: 8259 bytes
Desc: not available
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/a3458229/attachment.f>
-- next part --
A non-text attachment was scrubbed...
Name: cartco.f
Type: text/x-fortran
Size: 3598 bytes
Desc: not available
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20110603/a3458229/attachment-0001.f>

[Wien] LAPW2 problem

[Gerhard Fecher]

It is faster to search this forum for
SIGSEGV, segmentation fault
then to ask the question two times.

without knowledge what you did, no one will be able to help.


Ciao
Gerhard


Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz

Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
zeus.theochem.tuwien.ac.at]" im Auftrag von "AJAY SINGH VERMA 
[ajay_phy at hotmail.com]
Gesendet: Freitag, 3. Juni 2011 07:52
Bis: wien zeus
Betreff: [Wien] LAPW2 problem

Respected all users,
I am trying to reproduce the results of a paper, related to compound ZnCdTe2 
chalcopyrite compound. We are using WIEN_11_executables to run the choosing 
system.
But when i use run_lapw on the command prompt i got the following error
Sir their occurs some error in LAPW2

asverma at ubuntu:~/work/ZnCdTe2$ run_lapw
hup: Command not found.
 LAPW0 END
 LAPW1 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred

Stack trace terminated abnormally.

>   stop error
asverma at ubuntu:~/work/ZnCdTe2$
Sir please help and suggest why it is so and how to remove this.
Thanking you
A. S. Verma

[Wien] new optimization scheme

[Laurence Marks]

Ah, I had not seen this.

In the case you gave there is nothing fixing the origin naturally
along the z axis (I suspect). You need to edit case.inM to fix one of
the atom positions along the z direction to prevent the structure
freely translating along this direction (this is better for PORT as
well as MSR1a).

Note: some structures refine better in MSR1a than others.

On Fri, Jun 3, 2011 at 3:14 AM, Peter Blaha
 wrote:
> The implementation of ? :FSUM in WIEN2k_11 might not work properly in all
> cases.
> Most likely, you can forget this statement (or estimate the sum of forces
> manually
> taking into account eventually MULT > 1 !!!).
> The next release should have this ok (and it will be called :FCHECK)
>
> Am 03.06.2011 10:06, schrieb Laurence Marks:
>>
>> It is hard to say as you don't provide enough information.
>> In the second case you apparently have a structure without a center
>> ofsymmetry and something very, very bad is going on along the z axis asthe
>> sum of forces should be zero with OK RKMAX/RMT etc.
>> On Fri, Jun 3, 2011 at 2:27 AM, Lyudmila V. Dobysheva
>> ?wrote:> ?Dear WIEN developers,>> ?I started using the new optimization
>> scheme that is in mixer (MSR1a). In one> ?calculation I had lines> ?:FSUM ?:
>> Sum of forces Fx,Fy,Fz ? 0.0 ? 0.0 ? 0.0> ?(and it worked
>> well)>> ?Another calculation has lines like (1):> ?:FSUM ?: Sum of forces
>> Fx,Fy,Fz ? 0.0 ? 0.0 ?-1466.20200> ?and in addtion some remark just
>> after :RTO lines ?(2):> ?Note: symmetry trapping> ?I do not know yet whether
>> it works good as the process is going on. Energy is> ?decreasing, but forces
>> still not.>> ?What these 1 and 2 mean and aren't they bad?>> ?Best regards>
>> ? ?Lyudmila Dobysheva>
>> ?-->
>> ?Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.> ?426001 Izhevsk,
>> ul.Kirova 132> ?RUSSIA>
>> ?-->
>> ?Tel.:7(3412) 442118 (home), 218988(office), 250614(F
>
> ax)> ?E-mail: lyu at otf.pti.udm.ru> ? ? ? ? ?lyuka17 at mail.ru>
> ?lyu at otf.fti.udmurtia.su>
> ?http://fti.udm.ru/content/view/25/103/lang,english/>
> ?-->
> ?___> ?Wien mailing list>
> ?Wien at zeus.theochem.tuwien.ac.at>
> ?http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>>
>>
>> -- Laurence MarksDepartment of Materials Science and EngineeringMSE Rm
>> 2036 Cook Hall2220 N Campus DriveNorthwestern UniversityEvanston, IL 60208,
>> USATel: (847) 491-3996 Fax: (847) 491-7820email: L-marks at northwestern dot
>> eduWeb: www.numis.northwestern.eduChair, Commission on Electron
>> Crystallography of IUCRwww.numis.northwestern.edu/Research is to see what
>> everybody else has seen, and to think whatnobody else has thoughtAlbert
>> Szent-Gyorgi___Wien mailing
>> listWien at 
>> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
> --
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-15671 ? ? ? ? ? ? FAX: +43-1-58801-15698
> Email: blaha at theochem.tuwien.ac.at ? ?WWW:
> http://info.tuwien.ac.at/theochem/
> --
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>



-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi

[Wien] new optimization scheme

[Laurence Marks]

It is hard to say as you don't provide enough information.

In the second case you apparently have a structure without a center of
symmetry and something very, very bad is going on along the z axis as
the sum of forces should be zero with OK RKMAX/RMT etc.

On Fri, Jun 3, 2011 at 2:27 AM, Lyudmila V. Dobysheva
 wrote:
> Dear WIEN developers,
>
> I started using the new optimization scheme that is in mixer (MSR1a). In one
> calculation I had lines
> :FSUM ?: Sum of forces Fx,Fy,Fz ? 0.0 ? 0.0 ? 0.0
> (and it worked well)
>
> Another calculation has lines like (1):
> :FSUM ?: Sum of forces Fx,Fy,Fz ? 0.0 ? 0.0 ?-1466.20200
> and in addtion some remark just after :RTO lines ?(2):
> Note: symmetry trapping
> I do not know yet whether it works good as the process is going on. Energy is
> decreasing, but forces still not.
>
> What these 1 and 2 mean and aren't they bad?
>
> Best regards
> ?Lyudmila Dobysheva
> --
> Phys.-Techn. Institute of Ural Br. of Russian Ac. of Sci.
> 426001 Izhevsk, ul.Kirova 132
> RUSSIA
> --
> Tel.:7(3412) 442118 (home), 218988(office), 250614(Fax)
> E-mail: lyu at otf.pti.udm.ru
> ? ? ? ?lyuka17 at mail.ru
> ? ? ? ?lyu at otf.fti.udmurtia.su
> http://fti.udm.ru/content/view/25/103/lang,english/
> --
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>



-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi