Re: [Wien] hyperfine field question in ORB package for the aluminum

[Jing-Han Chen]

Dear Prof. Blaha

  It works very well after TEMP broadening is turned on. Thanks for your
suggestion.


2013/10/15 Peter Blaha 

> Hi,
>
> I guess I never suggested B=1 T, but anyway, what you should check is
> if the calculated HFF vary linear with the applied field.
>
> I could imagine that with such calculations where you should have some
> "artificial" degeneracy of the 4 Al atoms, the TETRA method makes some
> small problem. In any case, it looks already fairly similar.
>
> Have you ever tried TEMP (with a small broadening ??, so that you do not
> destroy the magnetic shift).
> In addition, I suggest to increase the IFFT factor in case.in0 to 4 or 6,
> so that aliasing problems are reduced.
>
> Otherwise I would need to check this out myself.
>
>
> On 10/15/2013 06:25 PM, Jing-Han Chen wrote:
>
>> Dear Prof. Blaha and other wien2k users:
>>
>> (I posted a similar message yesterday, apologies in case this appears as
>> a repeat; the first message has not appeared on the list, perhaps
>> reflected due to included images.)
>>
>> Regarding tests of the hyperfine fields in aluminum metal, we had
>> thought about the issue of insufficient k-points, however we thought we
>> had a handle on this issue. In a 9 T field, a rough calculation shows
>> that the thin spin-polarized shell at Ef represents about 1/3000 of the
>> BZ volume for fcc-Al. We ran a script gradually increasing the number of
>> k-points, with a result (shown in
>> http://people.physics.tamu.**edu/jhchen/points.png)
>> that the HFF settles
>> down within about 20% of the expected value for 10,000 k-points in B=9T,
>> with fluctuations dying down to the order of 10% and less in the range
>> 30,000 - 80,000 k-points. We also ran a test for linearity in B at a
>> setting of 10,000 k-points, and the results appeared to be quite linear
>> up to 100 T (shown in 
>> http://people.physics.tamu.**edu/jhchen/field.png
>> ).
>>
>> We ran the test treating fcc-Al as simple cubic with 4 sites in order to
>> be sure we understood how the field is applied in ORB, and expected if
>> anything better convergence since the expanded cell gives a greater
>> k-point density. However the results seem strange: with several k-point
>> settings we found that in general, the HFF approached the expected value
>> for fcc-Al after a relatively small number of iterations, yet without
>> quite converging, and finally the HFF values diverged, with one or more
>> going large and negative. We had not tried as many variations as for fcc
>> since the results are much slower to obtain converged HFF.
>>
>> Following the suggestion of Prof. Blaha after our last posting we tried
>> increasing to very large field and k-point values, and did finally get
>> convergence (more than 10 last iterations of HFF is the same) for a
>> setting of 10 k-points and 1  T, yielding 4 reasonably close
>> positive values as in the following:
>>
>> --
>> :HFF001:  143.345   0.000   0.572
>> 143.917 (KGAUSS)
>> :HFF002:  143.344   0.000   0.572
>> 143.916 (KGAUSS)
>> :HFF003:  144.427   0.000   0.583
>> 145.010 (KGAUSS)
>> :HFF004:  143.344   0.000   0.572
>> 143.916 (KGAUSS)
>> --
>>
>> However we are concerned that the HFF values are still not identical,
>> whereas at 10,000 T the spin-polarized shell at Ef represents a
>> significant fraction of the BZ, and the spin energy is quite large. We
>> expected this to be more than enough k-points for random sampling of the
>> shell at Ef.  For this reason, and in particular in light of the strange
>> behavior in which the HFF values almost converge before diverging to
>> widely separated values, is it possible that there might be some other
>> issue that we are overlooking?
>>
>> Any suggestions would be appreciated.
>>
>>
>> 2013/10/7 Peter Blaha > >
>>
>>
>> The hyperfine field for a metal is coming mainly from the contact
>> term due to the induced spin-polarization by the magnetic field.
>>
>> You should notice, that a field of 9 T is (for theoretical
>> calculations) an extremely small field, causing a very small
>> spin-splitting of the states near EF, which causes the HFF.
>> I suppose all you see is numerical noise.
>>
>> Since only the states at EF are of interest (the field can only
>> reoccupy states within a few mRy (or less) around EF), you need to
>> converge your calculation with respect to:
>>
>> a) the k-mesh   (test MUCH larger meshes (1, 5 10 k or
>> more)
>> b) the magnetic field (increase it and test fields up to 1000 T),
>> You are not interested in the absolute number, but in ppm, i.e. the
>> relative induced field.
>>
>> c) The angular momentum component of the hFF introduced by
>> case.vorbup/dn is NOT correct. 

Re: [Wien] lapw0 hang with mbj calculation for slab

[NACIR M. TIT]

Can you please remove my name (my email address= n...@uaeu.ac.ae) from your 
mailing List. Please do. I would appreciate that very much. Thanks!

**
Dr. Nacir Tit
Professor of Computational Physics
Physics Department
UAE University
Al-Ain
United Arab Emirates
Tel: +971 3 7136 326
Fax: +971 3 7671 291
Email: n...@uaeu.ac.ae
**

From: wien-boun...@zeus.theochem.tuwien.ac.at 
[wien-boun...@zeus.theochem.tuwien.ac.at] on behalf of Peter Blaha 
[pbl...@theochem.tuwien.ac.at]
Sent: Friday, October 18, 2013 3:36 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] lapw0 hang with mbj calculation for slab

For mBJ it is ALWAYS a good idea to use a larger IFFTfactor (complete
cycle).

For a surface, case.in0_grr should not be present.

However, you need a file case.grr (normally prepared when case.in0_grr
is present). This file (or the corresponding   avrg [(grad rho)/rho]
value) should be taken from a corresponding bulk calculation.

On 10/18/2013 12:37 PM, alpa dashora wrote:
> Dear Prof. Blaha,
>
> Thanks for reply. I am unable to understand the reply. In only one
> iteration FFT factor should be 4 or for complete mbj cycle it should be
> same or again changed to 2.
>
> Should I remove case.in0_grr file?
>
> Please clear it.
>   With regards,
>
>
>
> On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha
> mailto:pbl...@theochem.tuwien.ac.at>> wrote:
>
> Switch to PBE for one iteration.
> Increase  IFFTfactor from 2 to 4 in case.in0 (and, most likely,
> reduce RKMAX)
>
> Am 18.10.2013 05:55, schrieb alpa dashora:
>
> Dear Prof. Blaha and Wien2k users,
>
> I am trying to run mbj calculation for MoS2 10 layer slab. After
> few cycles lapw0 hanged. I have seen the earlier posts discussed
> on the same topics. I have used the
> vxclm2.f file as provided by Prof. Blaha and removed
> case.in0_grr file. I have also increased the Rmt*Kmax up to 9
> but still I am not able to solve my problem.
>
> Please suggest any other solution for this error or any other
> method to calculate the correct band gap.
>
> Thanks in advance.
>
> With kind regards,
>
> --
> Alpa Dashora
>
>
> _
> Wien mailing list
> w...@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. Materials Chemistry, TU Vienna
> Getreidemarkt 9, A-1060 Vienna, Austria
> Tel: +43-1-5880115671
> Fax: +43-1-5880115698
> email: pbl...@theochem.tuwien.ac.at
> 
> --__---
> _
> Wien mailing list
> w...@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
> 
>
>
>
>
> --
> Alpa Dashora
>
>
> ___
> 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.atWWW:
http://info.tuwien.ac.at/theochem/
--
___
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] installation issues

[Lawal Mohammed]

Thank you so much Prof. Peter Blaha, Abo Gavin, ...
The link you provided help. The issues are now resolved using two commands
1) yum install gnutplot gnuplot-x11   
2) yum install perl-CGI
in fedora 16 and18.

Another issue, in this regard, I got this error 

/home/mohammed/WIEN2K/lapw0: error while loading shared libraries: 
libmkl_intel_lp64.so: cannot open shared object file: No such file or directory 
>   stop error
while running scf, Chakrabarti Shamik suggested that it is because the path for 
the file (libmkl_intel_lp64.so) is not properly given during compilation of 
wien2k (during userconfig_lapw). If that is the case, can anybody please tell 
me how to set the path for that file properly.

Thanking you all in advance for your response.

Best regards.








On Friday, October 18, 2013 3:30 PM, Gavin Abo  wrote:
 
1- Is gnuplot installed on the non-working systems? Of note, it could be 
installed with "sudo apt-get install gnuplot" on older Ubuntu versions.  
However, I believe you have to use now "sudo apt-get install gnuplot 
gnuplot-x11" on recent Ubuntu versions, since it seems that they decided to 
remove gnuplot-x11 as a dependency of gnuplot.

2- You likely need to install a missing Perl module.  For example,
  for Fedora:

https://ask.fedoraproject.org/question/8330/where-is-perl-module-cgipm-installed/

Since we don't know what operating systems you are using, you can
  search the Internet or your OS support (manual, forum, etc) on how
  to install these for your systems.

On 10/18/2013 12:27 AM, Lawal Mohammed wrote:

Dear users and developers 
>
>
>
>We are having problems with two of our systems, and couldn't figure out what 
>is wrong. Even after checking the mailing list.
> 1- We couldn't plot our output using rhoplot, For example,
  when we try  electron density plots for TiC, there was no
  visual. However, it works in some of our systems under the
  same condition.
> 2- When I try to copy/upload the original case struct file
  into a new directory for supercell calculations I got this msg
>
> Can't locate CGI.pm in @INC (@INC contains:
  /usr/local/lib64/perl5 /usr/local/share/perl5
  /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
  /usr/lib64/perl5 /usr/share/perl5 .) at
  /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3.
  BEGIN failed--compilation aborted at
  /home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3.
>
>
>
>However, it works on one of our system. If there are any info that anybody may 
>need to assist we will be grateful to provide.
>
>With best regards
>
>Mohammed lawal
>universiti Technologi Malaysia
>


___
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] lapw0 hang with mbj calculation for slab

[Peter Blaha]

For mBJ it is ALWAYS a good idea to use a larger IFFTfactor (complete 
cycle).


For a surface, case.in0_grr should not be present.

However, you need a file case.grr (normally prepared when case.in0_grr 
is present). This file (or the corresponding   avrg [(grad rho)/rho] 
value) should be taken from a corresponding bulk calculation.


On 10/18/2013 12:37 PM, alpa dashora wrote:

Dear Prof. Blaha,

Thanks for reply. I am unable to understand the reply. In only one
iteration FFT factor should be 4 or for complete mbj cycle it should be
same or again changed to 2.

Should I remove case.in0_grr file?

Please clear it.
  With regards,



On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha
mailto:pbl...@theochem.tuwien.ac.at>> wrote:

Switch to PBE for one iteration.
Increase  IFFTfactor from 2 to 4 in case.in0 (and, most likely,
reduce RKMAX)

Am 18.10.2013 05:55, schrieb alpa dashora:

Dear Prof. Blaha and Wien2k users,

I am trying to run mbj calculation for MoS2 10 layer slab. After
few cycles lapw0 hanged. I have seen the earlier posts discussed
on the same topics. I have used the
vxclm2.f file as provided by Prof. Blaha and removed
case.in0_grr file. I have also increased the Rmt*Kmax up to 9
but still I am not able to solve my problem.

Please suggest any other solution for this error or any other
method to calculate the correct band gap.

Thanks in advance.

With kind regards,

--
Alpa Dashora


_
Wien mailing list
w...@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. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pbl...@theochem.tuwien.ac.at

--__---
_
Wien mailing list
w...@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





--
Alpa Dashora


___
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.atWWW: 
http://info.tuwien.ac.at/theochem/

--
___
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] lapw0 hang with mbj calculation for slab

[alpa dashora]

Dear Prof. Blaha,

Thanks for reply. I am unable to understand the reply. In only one
iteration FFT factor should be 4 or for complete mbj cycle it should be
same or again changed to 2.

Should I remove case.in0_grr file?

Please clear it.
 With regards,



On Fri, Oct 18, 2013 at 11:30 AM, Peter Blaha
wrote:

> Switch to PBE for one iteration.
> Increase  IFFTfactor from 2 to 4 in case.in0 (and, most likely, reduce
> RKMAX)
>
> Am 18.10.2013 05:55, schrieb alpa dashora:
>
>> Dear Prof. Blaha and Wien2k users,
>>
>> I am trying to run mbj calculation for MoS2 10 layer slab. After few
>> cycles lapw0 hanged. I have seen the earlier posts discussed on the same
>> topics. I have used the
>> vxclm2.f file as provided by Prof. Blaha and removed case.in0_grr file. I
>> have also increased the Rmt*Kmax up to 9 but still I am not able to solve
>> my problem.
>>
>> Please suggest any other solution for this error or any other method to
>> calculate the correct band gap.
>>
>> Thanks in advance.
>>
>> With kind regards,
>>
>> --
>> Alpa Dashora
>>
>>
>> __**_
>> Wien mailing list
>> w...@zeus.theochem.tuwien.ac.**at 
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
>> w...@zeus.theochem.tuwien.ac.**at/index.html
>>
>>
> --
> --**---
> Peter Blaha
> Inst. Materials Chemistry, TU Vienna
> Getreidemarkt 9, A-1060 Vienna, Austria
> Tel: +43-1-5880115671
> Fax: +43-1-5880115698
> email: pbl...@theochem.tuwien.ac.at
> --**---
> __**_
> Wien mailing list
> w...@zeus.theochem.tuwien.ac.**at 
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  http://www.mail-archive.com/**
> w...@zeus.theochem.tuwien.ac.**at/index.html
>



-- 
Alpa Dashora
___
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(R) Xeon(R) CPU X5550 @ 2.67GHz vs Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

[Peter Blaha]

As was mentioned before, such a big case needs   mpi  in order to run 
efficiently.


As a "quick" small improvement  set the OMP_NUM_THREAD variable to 2 or 
4.   This should give a speedup of about 2 and in the dayfile you should 
see that not 905% of the cpu was used, but 180% or so.



On 10/18/2013 10:51 AM, Yundi Quan wrote:

First, thank Peter. I should have described my problem thoroughly.

:RKM  : MATRIX SIZE 9190LOs:1944  RKM= 4.88  WEIGHT= 2.00  PGR

The reduced RKM is 4.88. The reduced matrix size is 9190 which is about 2/5 of 
the full matrix. So that explains a lot. I'm using P1 symmetry. Therefore, the 
complex veion of lapw1, lapw2 are used. Compared with LDA calculations, LSDA 
almost doubles lapw1 and lapw2.

I'm using P1 symmetry. Therefore, symmetry cannot reduce the number of stars 
(i.e. planes waves) in the interstitial region or the number of spherical 
harmonics inside the muffin-tin sphere. I guess that's why my job takes so 
long. And moreover, I'm only using k-point parallel without mpi.

Oxygen is the smallest atom in the unit cell. Reducing RKMAX to 6.5 is what I'm 
going to do first.

One of the clusters to which I have access has 8 cores per node and 8GB memory 
per node. Given the constraint of memory, I wonder how to improve the core 
usage when calculating compounds with large unit cells. For the compound I'm 
currently working on, I request one core per node and 8 nodes(=nkp) per job. So 
7*8=56 cores are wasted while running my job. I'm in dire need of help.


Yundi


On Oct 17, 2013, at 10:58 PM, Peter Blaha  wrote:


You still did not tell us the matrix size for the truncated RKmax, but yes,
the scaling is probably ok.   (scaling goes with n^3; i.e. in case of of
matrix size 12000 and 24000 we expect almost a factor of 8 !!! in cpu time.
It also explaines the memory 

You also did not tell us if you have inversion or not.

One of my real cases with  NMAT= 21500   takes 400 sec on 64 cores (mpi), so one
could estimate something like 2 sec on a single core, which comes to the 
right order
of magnitude compared to your case.

And: you may have 72 inequivalent atoms, but you did not tell us how many atoms 
in total you have.
The total number of atoms is the important info !!

Probably you can reduce RKMAX (you did not tell us which atom has RMT=1.65 
(probably O ??)
and most likely you should use mpi AND iterative diagonalization.

As I said, a case with 72 atoms (or whatever you have) can run in minutes on a 
reasonable cluster
and with a proper optimized setup (not just the defaults).


Am 17.10.2013 18:05, schrieb Yundi Quan:

Thanks a lot.
On cluster A, RKM was automatically reduced to 4.88 while on cluster B RKM was 
kept at 7. I didn't expect this, though I was aware that WIEN2k would 
automatically reduce
RKM in some cases. But is it reasonable for an iteration to run for eight hours 
with the following parameters?
Minimum sphere size: 1.65000 Bohr.
Total k-mesh : 8
Gmax : 12

:RKM  : MATRIX SIZE23486LOs:1944  RKM= 7.00  WEIGHT= 2.00  PGR:
:RKM  : MATRIX SIZE23486LOs:1944  RKM= 7.00  WEIGHT= 2.00  PGR:


On Thu, Oct 17, 2013 at 8:54 AM, Peter Blaha mailto:pbl...@theochem.tuwien.ac.at>> wrote:

The Xeon X5550 processor is a 4 core processor and your cluster may have 
combined a few of them on one node (2-4 ?) Anyway, 14 cores are not really 
possible ??

Have you done more than just looking on the total time ?

Is the machines file the same on both clusters ? Such a machines file does 
NOT use  mpi.

One guess in case you really use mpi on cluster B (with a different 
.machines file): In the sequential run (A) the basis set is limited by NMATMAX, 
in the mpi-parallel
run it is not (or it is scaled up by sqrt(N-core)).
So it could be that run A has a MUCH smaller RKMAX than run (B).
Check grep :RKM case.scf   of the two runs.
What are the real matrix sizes 

Alternatively, NMATMAX could be chosen differently on the two machines 
since somebody else installed WIEN2k.

Please compare carefully the resulting case.output1_1 files and eventually 
send the RELEVANT PARTS OF THEM.


In any case, a 72 atom cell should NOT take 2 h / iteration (or even 8 ??).

What are your sphere sizes ???, what gives :RKM in case.scf ???

At least one can set   OMP_NUM_THREAD=2 or 4   and speed up the code by a 
factor of almost 2. (You should see in the dayfile something close to 200 % 
instead of ~100%

 >   c1208-ib(1) 26558.265u 17.956s 7:34:14.39 97.5%0+0k 0+0io 0pf+0w

In essence:  A matrix size of 1 (real, with inversion) lapw1 should 
take in the order of 10 min  (no mpi, maybe with OMP_NUM_THREAD=2)



On 10/17/2013 04:33 PM, Yundi Quan wrote:

Thanks for your reply.
a). both machines are set up in a way that once a node is assigned to a
job, it cannot be assigned to another.
b). The .machines file looks like this
1:node1
1:node2
1:

Re: [Wien] Intel(R) Xeon(R) CPU X5550 @ 2.67GHz vs Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

[Yundi Quan]

First, thank Peter. I should have described my problem thoroughly.

:RKM  : MATRIX SIZE 9190LOs:1944  RKM= 4.88  WEIGHT= 2.00  PGR

The reduced RKM is 4.88. The reduced matrix size is 9190 which is about 2/5 of 
the full matrix. So that explains a lot. I'm using P1 symmetry. Therefore, the 
complex veion of lapw1, lapw2 are used. Compared with LDA calculations, LSDA 
almost doubles lapw1 and lapw2. 

I'm using P1 symmetry. Therefore, symmetry cannot reduce the number of stars 
(i.e. planes waves) in the interstitial region or the number of spherical 
harmonics inside the muffin-tin sphere. I guess that's why my job takes so 
long. And moreover, I'm only using k-point parallel without mpi.

Oxygen is the smallest atom in the unit cell. Reducing RKMAX to 6.5 is what I'm 
going to do first.

One of the clusters to which I have access has 8 cores per node and 8GB memory 
per node. Given the constraint of memory, I wonder how to improve the core 
usage when calculating compounds with large unit cells. For the compound I'm 
currently working on, I request one core per node and 8 nodes(=nkp) per job. So 
7*8=56 cores are wasted while running my job. I'm in dire need of help.


Yundi


On Oct 17, 2013, at 10:58 PM, Peter Blaha  wrote:

> You still did not tell us the matrix size for the truncated RKmax, but yes,
> the scaling is probably ok.   (scaling goes with n^3; i.e. in case of of
> matrix size 12000 and 24000 we expect almost a factor of 8 !!! in cpu time.
> It also explaines the memory 
> 
> You also did not tell us if you have inversion or not.
> 
> One of my real cases with  NMAT= 21500   takes 400 sec on 64 cores (mpi), so 
> one
> could estimate something like 2 sec on a single core, which comes to the 
> right order
> of magnitude compared to your case.
> 
> And: you may have 72 inequivalent atoms, but you did not tell us how many 
> atoms in total you have.
> The total number of atoms is the important info !!
> 
> Probably you can reduce RKMAX (you did not tell us which atom has RMT=1.65 
> (probably O ??)
> and most likely you should use mpi AND iterative diagonalization.
> 
> As I said, a case with 72 atoms (or whatever you have) can run in minutes on 
> a reasonable cluster
> and with a proper optimized setup (not just the defaults).
> 
> 
> Am 17.10.2013 18:05, schrieb Yundi Quan:
>> Thanks a lot.
>> On cluster A, RKM was automatically reduced to 4.88 while on cluster B RKM 
>> was kept at 7. I didn't expect this, though I was aware that WIEN2k would 
>> automatically reduce
>> RKM in some cases. But is it reasonable for an iteration to run for eight 
>> hours with the following parameters?
>> Minimum sphere size: 1.65000 Bohr.
>> Total k-mesh : 8
>> Gmax : 12
>> 
>> :RKM  : MATRIX SIZE23486LOs:1944  RKM= 7.00  WEIGHT= 2.00  PGR:
>> :RKM  : MATRIX SIZE23486LOs:1944  RKM= 7.00  WEIGHT= 2.00  PGR:
>> 
>> 
>> On Thu, Oct 17, 2013 at 8:54 AM, Peter Blaha > > wrote:
>> 
>>The Xeon X5550 processor is a 4 core processor and your cluster may have 
>> combined a few of them on one node (2-4 ?) Anyway, 14 cores are not really 
>> possible ??
>> 
>>Have you done more than just looking on the total time ?
>> 
>>Is the machines file the same on both clusters ? Such a machines file 
>> does NOT use  mpi.
>> 
>>One guess in case you really use mpi on cluster B (with a different 
>> .machines file): In the sequential run (A) the basis set is limited by 
>> NMATMAX, in the mpi-parallel
>>run it is not (or it is scaled up by sqrt(N-core)).
>>So it could be that run A has a MUCH smaller RKMAX than run (B).
>>Check grep :RKM case.scf   of the two runs.
>>What are the real matrix sizes 
>> 
>>Alternatively, NMATMAX could be chosen differently on the two machines 
>> since somebody else installed WIEN2k.
>> 
>>Please compare carefully the resulting case.output1_1 files and 
>> eventually send the RELEVANT PARTS OF THEM.
>> 
>> 
>>In any case, a 72 atom cell should NOT take 2 h / iteration (or even 8 
>> ??).
>> 
>>What are your sphere sizes ???, what gives :RKM in case.scf ???
>> 
>>At least one can set   OMP_NUM_THREAD=2 or 4   and speed up the code by a 
>> factor of almost 2. (You should see in the dayfile something close to 200 % 
>> instead of ~100%
>> 
>> >   c1208-ib(1) 26558.265u 17.956s 7:34:14.39 97.5%0+0k 0+0io 0pf+0w
>> 
>>In essence:  A matrix size of 1 (real, with inversion) lapw1 should 
>> take in the order of 10 min  (no mpi, maybe with OMP_NUM_THREAD=2)
>> 
>> 
>> 
>>On 10/17/2013 04:33 PM, Yundi Quan wrote:
>> 
>>Thanks for your reply.
>>a). both machines are set up in a way that once a node is assigned to 
>> a
>>job, it cannot be assigned to another.
>>b). The .machines file looks like this
>>1:node1
>>1:node2
>>1:node3
>>1:node4
>>1:node5
>>1:node6
>>1:node7
>>1:node8
>>  

Re: [Wien] installation issues

[Gavin Abo]

1- Is gnuplot installed on the non-working systems? Of note, it could be 
installed with "sudo apt-get install gnuplot" on older Ubuntu versions.  
However, I believe you have to use now "sudo apt-get install gnuplot 
gnuplot-x11" on recent Ubuntu versions, since it seems that they decided 
to remove gnuplot-x11 as a dependency of gnuplot.


2- You likely need to install a missing Perl module.  For example, for 
Fedora:


https://ask.fedoraproject.org/question/8330/where-is-perl-module-cgipm-installed/

Since we don't know what operating systems you are using, you can search 
the Internet or your OS support (manual, forum, etc) on how to install 
these for your systems.


On 10/18/2013 12:27 AM, Lawal Mohammed wrote:

Dear users and developers

We are having problems with two of our systems, and couldn't figure 
out what is wrong. Even after checking the mailing list.
 1- We couldn't plot our output using rhoplot, For example, when we 
try  electron density plots for TiC, there was no visual. However, it 
works in some of our systems under the same condition.
 2- When I try to copy/upload the original case struct file into a new 
directory for supercell calculations I got this msg


 Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib64/perl5 
/usr/local/share/perl5 /usr/lib64/perl5/vendor_perl 
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at 
/home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3. BEGIN 
failed--compilation aborted at 
/home/mohammed/WIEN2K/SRC_w2web/htdocs/util/upload2.pl line 3.


However, it works on one of our system. If there are any info that 
anybody may need to assist we will be grateful to provide.


With best regards
Mohammed lawal
universiti Technologi Malaysia


___
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