[Wien] problem with lapw2

2011-06-03 Thread 水牧 仁一朗
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] LAPW2 problem

2011-06-03 Thread 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] LAPW2 problem

2011-06-03 Thread 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]quot; im Auftrag von quot;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] bug for spaghetti for monoclinic CXZ lattices AND spin-orbit

2011-06-03 Thread 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] new optimization scheme

2011-06-03 Thread 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] new optimization scheme

2011-06-03 Thread 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
lyu at otf.pti.udm.ru 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


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

2011-06-03 Thread 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)

Most likely the lines are too long for gfortran (see 

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

2011-06-03 Thread 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] new optimization scheme

2011-06-03 Thread 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

2011-06-03 Thread 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] Magnetic properties or 5d metals

2011-06-03 Thread 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 
 http://www.wien2k.at/reg_user/textbooks/Constraint_U.pdf
 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] DOS

2011-06-03 Thread 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] Volume optimization and Struct File

2011-06-03 Thread 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] lapw2

2011-06-03 Thread 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] Magnetic material relaxation, RMT, MAE calculations

2011-06-03 Thread 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