[Wien] Wien2k 13 installation without FFTW3
Dear Wien2k users, I installed wien2k 13 in my machine and I noted that now, when we configure the parallel instalation, the siteconfig script asks for what FFTW we have installed. I have just FFTW2, so this is the one I chose. The instalation was sucessfull, without errors. Then I tested the instalation and I got an error message at mixer, saying that it could not find the fftw3 libraries. I thought it was strange, since I wanted to install using FFTW2. I looked at the Makefile for Mixer and at the compiler options was -DFFTW3 and at the libraries -lfftw3. So I changed -DFFTW3 to -DFFTW2 and -lfftw3 to -lfftw and compiled again. This time the calculation was sucessfull. So I tried to minimize the internal forces at the structure and this time I got the same error message at the Pairhess program. Again I looked at the Makefile and it was using FFTW3 instead of FFTW2. I did the same modification and the program run sucessfully. Now, I have two questions: 1) Can I change the Makefile at these programs so that they use FFTW2 or do they need FFTW3? 2) Are there any other programs in which I have to change the Makefile manually, so that they use FFTW2 instead of FFTW3? Thank you very much for your attention. Best regards, Michel Lacerda This message was sent using IMP, the Internet Messaging Program. ___ 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 13 installation without FFTW3
A quick answer about mixer pairhess; neither use any version of fftw so changing the Makefile is completely safe. I have not analyzed the new siteconfig/Makefile structure in wien2k_13 in detail, the FFTW* options are new, maybe there are some minor glitches in them (what you found looks like a bug) which Peter will presumably cure. On Fri, Jun 28, 2013 at 9:10 AM, mic...@if.usp.br mic...@if.usp.br wrote: Dear Wien2k users, I installed wien2k 13 in my machine and I noted that now, when we configure the parallel instalation, the siteconfig script asks for what FFTW we have installed. I have just FFTW2, so this is the one I chose. The instalation was sucessfull, without errors. Then I tested the instalation and I got an error message at mixer, saying that it could not find the fftw3 libraries. I thought it was strange, since I wanted to install using FFTW2. I looked at the Makefile for Mixer and at the compiler options was -DFFTW3 and at the libraries -lfftw3. So I changed -DFFTW3 to -DFFTW2 and -lfftw3 to -lfftw and compiled again. This time the calculation was sucessfull. So I tried to minimize the internal forces at the structure and this time I got the same error message at the Pairhess program. Again I looked at the Makefile and it was using FFTW3 instead of FFTW2. I did the same modification and the program run sucessfully. Now, I have two questions: 1) Can I change the Makefile at these programs so that they use FFTW2 or do they need FFTW3? 2) Are there any other programs in which I have to change the Makefile manually, so that they use FFTW2 instead of FFTW3? Thank you very much for your attention. Best regards, Michel Lacerda This message was sent using IMP, the Internet Messaging Program. ___ 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 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
Re: [Wien] Wien2k 13 installation without FFTW3
Respected Community Members I just want to give a suggestion. I see off and on emails regarding WIEN2k installation. May any one make a screen video of installating WIEN2k with proper pre-requisite and a test run with parallel Job submission. Screen video recordings can be used to illustrate many complex things beside installation. Personally I got a lot of benefit by turning on Screen recorder on my system whenever someone teach me something which requires a lot of steps with multiple selection of options. Best wishes Masood Universiti Tecknologi Malaysia From: mic...@if.usp.br mic...@if.usp.br To: wien@zeus.theochem.tuwien.ac.at Sent: Friday, June 28, 2013 10:10 PM Subject: [Wien] Wien2k 13 installation without FFTW3 Dear Wien2k users, I installed wien2k 13 in my machine and I noted that now, when we configure the parallel instalation, the siteconfig script asks for what FFTW we have installed. I have just FFTW2, so this is the one I chose. The instalation was sucessfull, without errors. Then I tested the instalation and I got an error message at mixer, saying that it could not find the fftw3 libraries. I thought it was strange, since I wanted to install using FFTW2. I looked at the Makefile for Mixer and at the compiler options was -DFFTW3 and at the libraries -lfftw3. So I changed -DFFTW3 to -DFFTW2 and -lfftw3 to -lfftw and compiled again. This time the calculation was sucessfull. So I tried to minimize the internal forces at the structure and this time I got the same error message at the Pairhess program. Again I looked at the Makefile and it was using FFTW3 instead of FFTW2. I did the same modification and the program run sucessfully. Now, I have two questions: 1) Can I change the Makefile at these programs so that they use FFTW2 or do they need FFTW3? 2) Are there any other programs in which I have to change the Makefile manually, so that they use FFTW2 instead of FFTW3? Thank you very much for your attention. Best regards, Michel Lacerda This message was sent using IMP, the Internet Messaging Program. ___ 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] survey results
As a follow up, can I request a little more information comparing the New and Old setrmt algorithms perhaps in a FAQ. I just noticed a very large difference between them for bulk LaAlO3, e.g. Old: atom Z RMT-max RMT 1 8.0 1.77 1.77 2 13.0 1.77 1.77 3 57.0 2.5 2.5 New atom Z RMT-max RMT 1 8.0 1.95 1.95 2 13.0 1.60 1.60 3 57.0 2.5 2.5 I assume that the New algorithm is better and this is right, but it would be helpful to know why O is now being chosen so much larger than Al, more like the relative atomic radii On Thu, Jun 27, 2013 at 1:47 PM, Peter Blaha pbl...@theochem.tuwien.ac.at wrote: I've updatedhttp://www.wien2k.at/reg_user/faq/rkmax.html Maybe it helps if I put a link in w2web in the initialization section next to the RKmax input/editing ? (But which experienced user is using w2web for intialization ?) Am 27.06.2013 16:49, schrieb Stefaan Cottenier: One week ago, a two-question survey was posted on this mailing list. Here comes the result and a discussion/interpretation of the data. The goal of the survey was to collect quantitative information on the following hypothesis: In the transition from code development to code usage, inevitable some awareness and knowledge about fine (?) details gets lost. Developers tend to think that users know more than they actually do. While users tend to think that there are less hidden subtleties than there actually are. It might well be that grey intermediate area of supposed/lacking knowledge is far larger than either of both parties thinks it is. The discussion of one week ago about the relation between RKmax and Rmt offered an opportunity to collect some data to examine this hypothesis. The topic was one about which an experienced user could think: You can't use wien2k properly if you don't know this. While a 'general user' could think: I can survive without this. 34 people filled out the survey. Less than the 100 I hoped for, but nevertheless sufficient for meaningful conclusions. The results can be found for a while at https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf (attachment too large for this list). 1/3 of the respondents say they could have given the right answer on the RKmax question themselves. 2/3 say this was new for them. As one can expect that users who have no clue at all about the topic are less likely to take part in the survey, it seems fair to conclude that 75% or more of the wien2k community was not aware about this RKmax issue. A number that might surprise some people. Whereas the first question of the survey roughly probes 'understanding', the second question of the survey asked about 'experience' (measured as the amount of years someone has been using wien2k). Slightly less than one half of the respondents were relatively new users (3y), the other half were quite to very much experienced (3y, 7y). It is interesting to correlate the answers on both questions in a knowledge-vs-experience graph (3th page of https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf ) : It is reassuring to observe in this correlation that roughly spoken understanding seems to increase as a function of experience (or time). Nevertheless, even in the category of the most experienced users (7y), there are still almost twice as many who were not aware of the RKmax issue than those who were (26% vs. 15%). This is only a rough observation, that does not pretend to be a statistically significant scientific study. It does point to a trend, however. The bottom line: is there anything all of us, as a community, can do to improve the knowledge transfer towards 'general users'? Feel free to discuss this on this mailing list, and in particular, to post suggestions. Stefaan ___ 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. 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 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 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] error in lapw2
i'm working on ternary compound with spinel symmetry. When I do runsp_lapw, the SCF failsafter 8 iterations wiith the following error: *L2main-QTL-B.GT.15 Ghostbands check scf files * * *I read something about this error such as : The scf cycle fails after a few iterations which gives some suggestions for this error : http://www.wien2k.at/reg_user/faq/scf.html I chose the suggestion number 4 : reduce the mixing parameter from 0.2 to 0.1 then restart the cycle with runsp_lapw but the error still ! can some help me please best regards ___ 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 13 installation without FFTW3
This looks a bit strange to me, but of course maybe it happens due to some special way you run siteconfig. a) In my Makefiles, fftw appears ONLY in the programs which have a parallel option (lapw0,1,2,dstart,hf). All other codes do not have fftw in the Makefile. b) Without checking: maybe it could happen because i) you selected firstFFTW3 ii) then respecified the sequential FOPT (here the FFTW2 got inserted into the Makefiles) iii) then you changed in the parallel options the FFTW2-FFTW3, but you did NOT respecify the sequential OPTIONS. But then still, I do not understand why it happens just for mixer and pairhess As was mentioned before, the non-parallel programs don't need FFTWs (but they do not harm, as long as you put them in correctly). Check $WIENROOT/OPTIONS. What is in the two FFTW... lines (and FFTW should not appear in any other lines. You can run siteconfig again, specify compiler options and save then. This should rewrite the Makefiles correctly. On 06/28/2013 04:10 PM, mic...@if.usp.br wrote: Dear Wien2k users, I installed wien2k 13 in my machine and I noted that now, when we configure the parallel instalation, the siteconfig script asks for what FFTW we have installed. I have just FFTW2, so this is the one I chose. The instalation was sucessfull, without errors. Then I tested the instalation and I got an error message at mixer, saying that it could not find the fftw3 libraries. I thought it was strange, since I wanted to install using FFTW2. I looked at the Makefile for Mixer and at the compiler options was -DFFTW3 and at the libraries -lfftw3. So I changed -DFFTW3 to -DFFTW2 and -lfftw3 to -lfftw and compiled again. This time the calculation was sucessfull. So I tried to minimize the internal forces at the structure and this time I got the same error message at the Pairhess program. Again I looked at the Makefile and it was using FFTW3 instead of FFTW2. I did the same modification and the program run sucessfully. Now, I have two questions: 1) Can I change the Makefile at these programs so that they use FFTW2 or do they need FFTW3? 2) Are there any other programs in which I have to change the Makefile manually, so that they use FFTW2 instead of FFTW3? Thank you very much for your attention. Best regards, Michel Lacerda This message was sent using IMP, the Internet Messaging Program. ___ 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] error in lapw2
Did you also do point 1+2 of the faq page ? Did you check the Another possibility of that page. Did you see any changes. Is the error again in the 8th iteration ? grep :DIS case.scf Very often with the new mixer versions, ghostbands appear due to user-errors or due to a special case where the energy parameters need hand-tuning. Buth without details, nobody can help. On 06/28/2013 05:45 PM, ben amara imen wrote: i'm working on ternary compound with spinel symmetry. When I do runsp_lapw, the SCF failsafter 8 iterations wiith the following error: *L2main-QTL-B.GT.15 Ghostbands check scf files * **I read something about this error such as : The scf cycle fails after a few iterations which gives some suggestions for this error : http://www.wien2k.at/reg_user/faq/scf.html I chose the suggestion number 4 : reduce the mixing parameter from 0.2 to 0.1 then restart the cycle with runsp_lapw but the error still ! can some help me please best regards ___ 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] survey results
The answer is simple: it is a bug.
As listed on the faq page http://www.wien2k.at/reg_user/faq/rkmax.html
the necessary RKmax for Al and O are both 6.5.
Therefore the spheres should be equal.
These RKmax estimates come from total energy tests of an atom in a
simple box.
For Al, however, the convergence depends a lot on the semicore-treatment
and at first I had obtained a RKmax=4.5 for Al, but later on it was
updated to 6.5.
Unfortunately, setrmt has the Al in both, the 4.5 and 6.5 section and
thus uses 4.5, which will then make the Al sphere smaller than O.
# Li, Al, Si
sub rkm4_5 {
my ($a) = @_ ;
if ( $a == 3 || $a == 13 || $a == 14 ) {
return 1;
Removing a == 13 from the above, should fix the problem.
I'll update the sources.
On 06/28/2013 05:24 PM, Laurence Marks wrote:
As a follow up, can I request a little more information comparing the
New and Old setrmt algorithms perhaps in a FAQ. I just noticed a very
large difference between them for bulk LaAlO3, e.g.
Old:
atom Z RMT-max RMT
1 8.0 1.77 1.77
2 13.0 1.77 1.77
3 57.0 2.5 2.5
New
atom Z RMT-max RMT
1 8.0 1.95 1.95
2 13.0 1.60 1.60
3 57.0 2.5 2.5
I assume that the New algorithm is better and this is right, but it
would be helpful to know why O is now being chosen so much larger than
Al, more like the relative atomic radii
On Thu, Jun 27, 2013 at 1:47 PM, Peter Blaha
pbl...@theochem.tuwien.ac.at wrote:
I've updatedhttp://www.wien2k.at/reg_user/faq/rkmax.html
Maybe it helps if I put a link in w2web in the initialization section next to
the
RKmax input/editing ? (But which experienced user is using w2web for
intialization ?)
Am 27.06.2013 16:49, schrieb Stefaan Cottenier:
One week ago, a two-question survey was posted on this mailing list.
Here comes the result and a discussion/interpretation of the data.
The goal of the survey was to collect quantitative information on the
following hypothesis:
In the transition from code development to code usage, inevitable some
awareness and knowledge about fine (?) details gets lost. Developers tend to think
that users know
more than they actually do. While users tend to think that there are less
hidden subtleties than there actually are. It might well be that grey
intermediate area of
supposed/lacking knowledge is far larger than either of both parties thinks it
is.
The discussion of one week ago about the relation between RKmax and Rmt offered
an opportunity to collect some data to examine this hypothesis. The topic was
one about
which an experienced user could think: You can't use wien2k properly if you don't know
this. While a 'general user' could think: I can survive without this.
34 people filled out the survey. Less than the 100 I hoped for, but
nevertheless sufficient for meaningful conclusions. The results can be found
for a while at
https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf
(attachment too large for this list).
1/3 of the respondents say they could have given the right answer on the RKmax
question themselves. 2/3 say this was new for them. As one can expect that
users who have no
clue at all about the topic are less
likely to take part in the survey, it seems fair to conclude that 75% or more
of the wien2k community was not aware about this RKmax issue. A
number that might surprise some people.
Whereas the first question of the survey roughly probes 'understanding', the
second question of the survey asked about 'experience' (measured as the amount
of years someone
has been using wien2k). Slightly less than one half of the respondents were relatively
new users (3y), the other half were quite to very much experienced (3y, 7y).
It is
interesting to correlate the answers on both questions in a
knowledge-vs-experience graph (3th page of
https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf ) :
It is reassuring to observe in this correlation that roughly spoken
understanding seems to increase as a function of experience (or time).
Nevertheless, even in the
category of the most experienced users (7y), there are still almost twice as
many who were not aware of the RKmax issue than those who were (26% vs. 15%).
This is only a rough observation, that does not pretend to be a statistically
significant scientific study. It does point to a trend, however.
The bottom line: is there anything all of us, as a community, can do to improve
the knowledge transfer towards 'general users'? Feel free to discuss this on
this mailing
list, and in particular, to post suggestions.
Stefaan
___
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. Materials Chemistry, TU
Re: [Wien] survey results
Thanks, it looked unusual. Removing || 13 fixes it, i.e. (for others)
# Li, Si
sub rkm4_5 {
my ($a) = @_ ;
if ( $a == 3 || $a == 14 ) {
return 1;
} else {
return 0;
}
}
On Fri, Jun 28, 2013 at 11:13 AM, Peter Blaha
pbl...@theochem.tuwien.ac.at wrote:
The answer is simple: it is a bug.
As listed on the faq page http://www.wien2k.at/reg_user/faq/rkmax.html
the necessary RKmax for Al and O are both 6.5.
Therefore the spheres should be equal.
These RKmax estimates come from total energy tests of an atom in a
simple box.
For Al, however, the convergence depends a lot on the semicore-treatment
and at first I had obtained a RKmax=4.5 for Al, but later on it was
updated to 6.5.
Unfortunately, setrmt has the Al in both, the 4.5 and 6.5 section and
thus uses 4.5, which will then make the Al sphere smaller than O.
# Li, Al, Si
sub rkm4_5 {
my ($a) = @_ ;
if ( $a == 3 || $a == 13 || $a == 14 ) {
return 1;
Removing a == 13 from the above, should fix the problem.
I'll update the sources.
On 06/28/2013 05:24 PM, Laurence Marks wrote:
As a follow up, can I request a little more information comparing the
New and Old setrmt algorithms perhaps in a FAQ. I just noticed a very
large difference between them for bulk LaAlO3, e.g.
Old:
atom Z RMT-max RMT
1 8.0 1.77 1.77
2 13.0 1.77 1.77
3 57.0 2.5 2.5
New
atom Z RMT-max RMT
1 8.0 1.95 1.95
2 13.0 1.60 1.60
3 57.0 2.5 2.5
I assume that the New algorithm is better and this is right, but it
would be helpful to know why O is now being chosen so much larger than
Al, more like the relative atomic radii
On Thu, Jun 27, 2013 at 1:47 PM, Peter Blaha
pbl...@theochem.tuwien.ac.at wrote:
I've updatedhttp://www.wien2k.at/reg_user/faq/rkmax.html
Maybe it helps if I put a link in w2web in the initialization section next
to the
RKmax input/editing ? (But which experienced user is using w2web for
intialization ?)
Am 27.06.2013 16:49, schrieb Stefaan Cottenier:
One week ago, a two-question survey was posted on this mailing list.
Here comes the result and a discussion/interpretation of the data.
The goal of the survey was to collect quantitative information on the
following hypothesis:
In the transition from code development to code usage, inevitable some
awareness and knowledge about fine (?) details gets lost. Developers tend
to think that users know
more than they actually do. While users tend to think that there are less
hidden subtleties than there actually are. It might well be that grey
intermediate area of
supposed/lacking knowledge is far larger than either of both parties
thinks it is.
The discussion of one week ago about the relation between RKmax and Rmt
offered an opportunity to collect some data to examine this hypothesis.
The topic was one about
which an experienced user could think: You can't use wien2k properly if
you don't know this. While a 'general user' could think: I can survive
without this.
34 people filled out the survey. Less than the 100 I hoped for, but
nevertheless sufficient for meaningful conclusions. The results can be
found for a while at
https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf
(attachment too large for this list).
1/3 of the respondents say they could have given the right answer on the
RKmax question themselves. 2/3 say this was new for them. As one can
expect that users who have no
clue at all about the topic are less
likely to take part in the survey, it seems fair to conclude that 75% or
more of the wien2k community was not aware about this RKmax issue. A
number that might surprise some people.
Whereas the first question of the survey roughly probes 'understanding',
the second question of the survey asked about 'experience' (measured as
the amount of years someone
has been using wien2k). Slightly less than one half of the respondents
were relatively new users (3y), the other half were quite to very much
experienced (3y, 7y). It is
interesting to correlate the answers on both questions in a
knowledge-vs-experience graph (3th page of
https://dl.dropboxusercontent.com/u/10829484/Results%20RKmax%20survey.pdf
) :
It is reassuring to observe in this correlation that roughly spoken
understanding seems to increase as a function of experience (or time).
Nevertheless, even in the
category of the most experienced users (7y), there are still almost twice
as many who were not aware of the RKmax issue than those who were (26% vs.
15%).
This is only a rough observation, that does not pretend to be a
statistically significant scientific study. It does point to a trend,
however.
The bottom line: is there anything all of us, as a community, can do to
improve the knowledge transfer towards 'general users'? Feel free to
discuss this on this mailing
list, and in particular,
Re: [Wien] Wien2k 13 installation without FFTW3
Dear professor Blaha, Thank you for your reply. I don't remember exactly what I did. Here is my OPTIONS file: current:FOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -I/opt/intel/mkl/10.2.5.035/include -I/opt/intel/impi/4.0.0.028/intel64/include current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -I/opt/intel/mkl/10.2.5.035/include/em64t/lp64 current:FFTW_OPT:-DFFTW2 -I/data1/fftw2/include current:FFTW_LIBS:-lfftw_mpi -lfftw -L/data1/fftw2/lib current:LDFLAGS:-L/opt/intel/mkl/10.2.5.035/lib/em64t -pthread current:DPARALLEL:'-DParallel' current:R_LIBS:-L/opt/intel/mkl/10.2.5.035/lib/em64t -lmkl_cdft_core -lmkl_blacs_intelmpi_lp64 -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread -L/opt/intel/mkl/10.1.3.027/lib/em64t current:RP_LIBS:-L/opt/intel/mkl/10.2.5.035/lib/em64t -lmkl_blas95_lp64 -lmkl_lapack95_lp64 -lmkl_scalapack_lp64 -lmkl_cdft_core -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lmkl_blacs_intelmpi_lp64 -L/opt/intel/mkl/10.1.3.027/lib/em64t/-lfftw2xf_intel -lpthread -lm current:MPIRUN:mpirun -np _NP_ -machinefile_HOSTS_ _EXEC_ current:MKL_TARGET_ARCH: I removed the Makefiles for Mixer and Pairhess, run siteconfig again and saved the options. It seemms to have worked, at least the Makefiles for mixer and pairhess are correct now. Thank you very much! Michel Lacerda Quoting Peter Blaha pbl...@theochem.tuwien.ac.at: This looks a bit strange to me, but of course maybe it happens due to some special way you run siteconfig. a) In my Makefiles, fftw appears ONLY in the programs which have a parallel option (lapw0,1,2,dstart,hf). All other codes do not have fftw in the Makefile. b) Without checking: maybe it could happen because i) you selected firstFFTW3 ii) then respecified the sequential FOPT (here the FFTW2 got inserted into the Makefiles) iii) then you changed in the parallel options the FFTW2-FFTW3, but you did NOT respecify the sequential OPTIONS. But then still, I do not understand why it happens just for mixer and pairhess As was mentioned before, the non-parallel programs don't need FFTWs (but they do not harm, as long as you put them in correctly). Check $WIENROOT/OPTIONS. What is in the two FFTW... lines (and FFTW should not appear in any other lines. You can run siteconfig again, specify compiler options and save then. This should rewrite the Makefiles correctly. On 06/28/2013 04:10 PM, mic...@if.usp.br wrote: Dear Wien2k users, I installed wien2k 13 in my machine and I noted that now, when we configure the parallel instalation, the siteconfig script asks for what FFTW we have installed. I have just FFTW2, so this is the one I chose. The instalation was sucessfull, without errors. Then I tested the instalation and I got an error message at mixer, saying that it could not find the fftw3 libraries. I thought it was strange, since I wanted to install using FFTW2. I looked at the Makefile for Mixer and at the compiler options was -DFFTW3 and at the libraries -lfftw3. So I changed -DFFTW3 to -DFFTW2 and -lfftw3 to -lfftw and compiled again. This time the calculation was sucessfull. So I tried to minimize the internal forces at the structure and this time I got the same error message at the Pairhess program. Again I looked at the Makefile and it was using FFTW3 instead of FFTW2. I did the same modification and the program run sucessfully. Now, I have two questions: 1) Can I change the Makefile at these programs so that they use FFTW2 or do they need FFTW3? 2) Are there any other programs in which I have to change the Makefile manually, so that they use FFTW2 instead of FFTW3? Thank you very much for your attention. Best regards, Michel Lacerda This message was sent using IMP, the Internet Messaging Program. ___ 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 This message was sent using IMP, the Internet Messaging Program.
[Wien] band structure dependence on symmetry and complex calculation
Dear wein2k users, I have calculated the band structure of the Fe2VAl lattice (fm3m, 225) for the two cases. *case one* : using the space group (225) defined structure with three atoms. *case two* : by seeing the structure of Fe2VAl in xcrysden, i have generated the case.struct file with 16 atomic unit cell (8-Fe, 4-V, 4-Al) with a 16 number of co-ordinates such that the structure looks same as in *case one*. But, in this structure file, i have used space group as a primitive (1). Using the Powder cell software, i also checked the XRD of the structures from the both cases and similar diffraction pattern were found. I run the volume optimization and min positions before running the spin polarized SCF calculation. However, In the First case (space group structure), we run the calculation without complex (no inversion). But, in the second case (primitive), we did the calculations with keeping complex ON. Now, i done the spaghetti plots for these two structures. For the space group case, we have observed indirect band picture between gamma and X k-points (X point will always followed by gamma). This nature is already reported in the literature also. But, for the second case with primitive structure, i have found the direct band like picture in which both band are touching at the gamma point. In preparing the case.klist and case.klist_band, i have used similar k-point co-ordinates for the both cases. Why the bands above the Fermi level would not shift to x point in the primitive case. Is there any effect of removing the symmetry on the band structure even though we did calculations on the similar structure...? or else in the first case, calculations did with complex OFF while in the second case with complex ON. Is this difference will change the band structure nature...? I could not attach the obtained figures, because i sent same mail with figures in few days before but it is not published in wien2k mailing list due to limitations in the mail content size. thanks in advance and waiting for your replies. regards, Ch. Venkatesh, C/o. Prof. V. Srinivas Dr. S. K. Srivastava Department of Physics Meteorology, IIT Kharagpur. ph: +91-3222-283848 (Lab) +919445909693 ___ 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] band structure dependence on symmetry and complex calculation
I have the feeling that your problem is related to the Bravais lattice which is F-centered and Primitive in the first and second cases. It is not related to the way the calculation is done (complex or not). Indeed, when you are using the space group Foum-3m, WIEN2k is doing the calculation in the related primitive cell which is 4-times smaller than the F-centered one. In constrast when you are doing the calculation with the initial structure but keeping the P1 symmetry, WIEN2k do the calculation for the full-cell. Thus in the reciprocal space the directions will be different and thus the path. On the other hand, could you provide the 2 structures to check that you didn't forget atoms in the case of the P1 symmetry calculation. Best Regards Xavier Le 6/28/2013 7:18 PM, venkatesh chandragiri a écrit : Dear wein2k users, I have calculated the band structure of the Fe2VAl lattice (fm3m, 225) for the two cases. *case one* : using the space group (225) defined structure with three atoms. *case two* : by seeing the structure of Fe2VAl in xcrysden, i have generated the case.struct file with 16 atomic unit cell (8-Fe, 4-V, 4-Al) with a 16 number of co-ordinates such that the structure looks same as in *case one*. But, in this structure file, i have used space group as a primitive (1). Using the Powder cell software, i also checked the XRD of the structures from the both cases and similar diffraction pattern were found. I run the volume optimization and min positions before running the spin polarized SCF calculation. However, In the First case (space group structure), we run the calculation without complex (no inversion). But, in the second case (primitive), we did the calculations with keeping complex ON. Now, i done the spaghetti plots for these two structures. For the space group case, we have observed indirect band picture between gamma and X k-points (X point will always followed by gamma). This nature is already reported in the literature also. But, for the second case with primitive structure, i have found the direct band like picture in which both band are touching at the gamma point. In preparing the case.klist and case.klist_band, i have used similar k-point co-ordinates for the both cases. Why the bands above the Fermi level would not shift to x point in the primitive case. Is there any effect of removing the symmetry on the band structure even though we did calculations on the similar structure...? or else in the first case, calculations did with complex OFF while in the second case with complex ON. Is this difference will change the band structure nature...? I could not attach the obtained figures, because i sent same mail with figures in few days before but it is not published in wien2k mailing list due to limitations in the mail content size. thanks in advance and waiting for your replies. regards, Ch. Venkatesh, C/o. Prof. V. Srinivas Dr. S. K. Srivastava Department of Physics Meteorology, IIT Kharagpur. ph: +91-3222-283848 (Lab) +919445909693 ___ 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] band structure dependence on symmetry and complex calculation
This is related to what is called backfolding. Remeber basic solid state theory: A direct lattice with lattice constant a, has a reciprocal lattice with b=2pi/a Now double the direct lattice (a'=2a), the reciprocal lattice b'=2pi/a'= pi/a Now now pi/a referes to the X point in the original lattice, but this same pi/a is a full reciprocal lattice vector for the supercell and thus appears at Gamma. This is called backfolding of of the second half of the Gamma-Delta-X branch back to Gamma-Delta(now X')-Gamma. There fore the original Gamma-X gap is now a direct Gamma-Gamma gap. Am 28.06.2013 19:18, schrieb venkatesh chandragiri: Dear wein2k users, I have calculated the band structure of the Fe2VAl lattice (fm3m, 225) for the two cases. *case one* : using the space group (225) defined structure with three atoms. *case two* : by seeing the structure of Fe2VAl in xcrysden, i have generated the case.struct file with 16 atomic unit cell (8-Fe, 4-V, 4-Al) with a 16 number of co-ordinates such that the structure looks same as in *case one*. But, in this structure file, i have used space group as a primitive (1). Using the Powder cell software, i also checked the XRD of the structures from the both cases and similar diffraction pattern were found. I run the volume optimization and min positions before running the spin polarized SCF calculation. However, In the First case (space group structure), we run the calculation without complex (no inversion). But, in the second case (primitive), we did the calculations with keeping complex ON. Now, i done the spaghetti plots for these two structures. For the space group case, we have observed indirect band picture between gamma and X k-points (X point will always followed by gamma). This nature is already reported in the literature also. But, for the second case with primitive structure, i have found the direct band like picture in which both band are touching at the gamma point. In preparing the case.klist and case.klist_band, i have used similar k-point co-ordinates for the both cases. Why the bands above the Fermi level would not shift to x point in the primitive case. Is there any effect of removing the symmetry on the band structure even though we did calculations on the similar structure...? or else in the first case, calculations did with complex OFF while in the second case with complex ON. Is this difference will change the band structure nature...? I could not attach the obtained figures, because i sent same mail with figures in few days before but it is not published in wien2k mailing list due to limitations in the mail content size. thanks in advance and waiting for your replies. regards, Ch. Venkatesh, C/o. Prof. V. Srinivas Dr. S. K. Srivastava Department of Physics Meteorology, IIT Kharagpur. ph: +91-3222-283848 (Lab) +919445909693 ___ 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. 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 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
