subject:"\[Wien\] Problems in the 1st step of the SCF cycle of mBj"

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Luis Carlos Ogando Dacal

Dear all,

   I would like to confirm that the first solution posted by Dr. Gavin Abo
works !! I followed section 11.1.1 of the Users Guide (ifort case) and the
 SCF cycle with mBJ is running without problems.
   There is only a little misprint in the WIEN2k_12 Users Guide, it is "add
-lfftw2xf_intel"... instead of "add -lfftw2xf"...  (at least for
 ifort 2011.3.174).
   Thank you very much for the help,
Luis Ogando




2012/8/24 Fecher, Gerhard 

> Gavin is right, COMPLEX(8) is the same as  COMPLEX*16
> COMPLEX(8) is also the same as DOUBLE COMPLEX (16 bytes, (128 bits))
> and fits to
> REAL(8)  (8 bytes, (64 bits))
> as it consists of two real 8 bytes numbers
>
>
> 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 "Gavin
> Abo [gsabo at crimson.ua.edu]
> Gesendet: Freitag, 24. August 2012 02:00
> An: A Mailing list for WIEN2k users
> Betreff: Re: [Wien] Problems in the 1st step of the SCF cycle of mBj
>
> I believe "complex(kind=8)" is the same as "complex*16", just a different
> notation for it.
>
> If the suggested possible fix works, an if statement in vresp.F to use the
> lines like "DWORK(:)" for fftw2/3 and "DWORK(*)" for fftpack would be
> needed.  Else, probably the original fft_modules.F and vresp.F would have
> to be used with some type of changes in fftpack_helpers.f instead.
>
> On 8/23/2012 5:24 PM, Laurence Marks wrote:
>
> Can you change everything to complex*16 ? It makes sense to do everything
> with double precision, I would be concerned with the accuracy of complex*8
> as well as mixing precisions.
>
> ---
> Professor Laurence Marks
> Department of Materials Science and Engineering
> Northwestern University
> www.numis.northwestern.edu<http://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
>
> On Aug 23, 2012 6:19 PM, "Gavin Abo"  gsabo at crimson.ua.edu>> wrote:
> The situational problem with the fftpack routine might be due to some
> inconsistency in the array usage.  Maybe Prof. Blaha can provide or confirm
> whether the fix below works properly.
>
> Lines 392-294 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) :: DWORK(:)
> complex(kind=8) :: CWORK(:)
> complex(kind=8) :: C(LDC1,LDC2,N3,2)
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(:)
> COMPLEX*16   CWORK(:)
>
> It runs without error with the following changes.
>
> Lines 392-293 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) DWORK(*)
> complex(kind=8) CWORK(*)
>
>   "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(*)
> COMPLEX*16   CWORK(*)
>
> as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"
>
> On 8/23/2012 12:58 PM, Gavin Abo wrote:
> I was able to reproduce the error with your files when the fftpack routine
> is used in Wien2k 12.1.  Ran a couple cycles, and the error did not appear
> when fftw3 was used instead.  So a possible solution may be to use the
> fftw3 library.
>
> The fftw3 may be faster than the fftpack, so you probably want to use it
> anyway.  It should be easy to use the fftw3 on Debian. fftw3 might already
> be installed or I believe you can install it with:
>
> apt-get install libfftw3-dev
>
> Open the Makefile in a text editor:
>
> vi $WIENROOT/SRC_lapw0/Makefile
>
> Edit and save settings to use for sequential (non-mpi):
>
> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3 -traceback
> R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
> -lmkl_core -openmp -lpthread -lfftw3
>
> In $WIENROOT/SRC_lapw0:
>
> make
> cp lapw0 ..
>
> As described in section 11.1.1 of the Wien2k 12.1 userguide, the same can
> be done with lapw2.  Instructions for using the possible faster mkl-fftw3
> for sequential (non-mpi) instead of the above described fftw3 from a Debian
> repository is also given.
>
> On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
> Dear Wien2k users and developers,
>
>I would like to report the same problem sent to the list by Dr. Eitel
> Peltzer.
>I am running WIEN2k_12.1 on a DELL

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Laurence Marks

Yes, my email was a little lazy, apologies.

On this general theme, two comments. First, fftw is certainly "better" than
fftpack both in speed and (more importantly) accuracy. You may want to take
some care when compiling fftw and set appropriate CFLAGS yourself. The
configure options in fftw are a bit old and I do not think it is being
updated. However, since this is only important in lapw2 it is not
supercritical.

Second, be a little cautious about using the mkl interface. If you get them
working then in my tests they are better. However, there have been bugs so
older versions of the interface are broken.
---
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
On Aug 23, 2012 7:00 PM, "Gavin Abo"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Laurence Marks

Yes, my email was a little lazy, apologies.

On this general theme, two comments. First, fftw is certainly "better" than
fftpack both in speed and (more importantly) accuracy. You may want to take
some care when compiling fftw and set appropriate CFLAGS yourself. The
configure options in fftw are a bit old and I do not think it is being
updated. However, since this is only important in lapw2 it is not
supercritical.

Second, be a little cautious about using the mkl interface. If you get them
working then in my tests they are better. However, there have been bugs so
older versions of the interface are broken.

---
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
On Aug 23, 2012 7:00 PM, "Gavin Abo"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Laurence Marks

Yes, my email was a little lazy, apologies.

On this general theme, two comments. First, fftw is certainly "better" than
fftpack both in speed and (more importantly) accuracy. You may want to take
some care when compiling fftw and set appropriate CFLAGS yourself. The
configure options in fftw are a bit old and I do not think it is being
updated. However, since this is only important in lapw2 it is not
supercritical.

Second, be a little cautious about using the mkl interface. If you get them
working then in my tests they are better. However, there have been bugs so
older versions of the interface are broken.

---
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
On Aug 23, 2012 7:00 PM, "Gavin Abo"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Laurence Marks

Yes, my email was a little lazy, apologies.

On this general theme, two comments. First, fftw is certainly "better" than
fftpack both in speed and (more importantly) accuracy. You may want to take
some care when compiling fftw and set appropriate CFLAGS yourself. The
configure options in fftw are a bit old and I do not think it is being
updated. However, since this is only important in lapw2 it is not
supercritical.

Second, be a little cautious about using the mkl interface. If you get them
working then in my tests they are better. However, there have been bugs so
older versions of the interface are broken.

---
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
On Aug 23, 2012 7:00 PM, "Gavin Abo"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Laurence Marks

Yes, my email was a little lazy, apologies.

On this general theme, two comments. First, fftw is certainly "better" than
fftpack both in speed and (more importantly) accuracy. You may want to take
some care when compiling fftw and set appropriate CFLAGS yourself. The
configure options in fftw are a bit old and I do not think it is being
updated. However, since this is only important in lapw2 it is not
supercritical.

Second, be a little cautious about using the mkl interface. If you get them
working then in my tests they are better. However, there have been bugs so
older versions of the interface are broken.

---
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
 On Aug 23, 2012 7:00 PM, "Gavin Abo"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-24 Thread Fecher, Gerhard

Gavin is right, COMPLEX(8) is the same as  COMPLEX*16
COMPLEX(8) is also the same as DOUBLE COMPLEX (16 bytes, (128 bits))
and fits to
REAL(8)  (8 bytes, (64 bits))
as it consists of two real 8 bytes numbers
 

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 "Gavin Abo [gsabo at 
crimson.ua.edu]
Gesendet: Freitag, 24. August 2012 02:00
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] Problems in the 1st step of the SCF cycle of mBj

I believe "complex(kind=8)" is the same as "complex*16", just a different 
notation for it.

If the suggested possible fix works, an if statement in vresp.F to use the 
lines like "DWORK(:)" for fftw2/3 and "DWORK(*)" for fftpack would be needed.  
Else, probably the original fft_modules.F and vresp.F would have to be used 
with some type of changes in fftpack_helpers.f instead.

On 8/23/2012 5:24 PM, Laurence Marks wrote:

Can you change everything to complex*16 ? It makes sense to do everything with 
double precision, I would be concerned with the accuracy of complex*8 as well 
as mixing precisions.

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

On Aug 23, 2012 6:19 PM, "Gavin Abo" mailto:gsabo at 
crimson.ua.edu>> wrote:
The situational problem with the fftpack routine might be due to some 
inconsistency in the array usage.  Maybe Prof. Blaha can provide or confirm 
whether the fix below works properly.

Lines 392-294 in SRC_lapw0/fft_modules.F:

real(kind=8) :: DWORK(:)
complex(kind=8) :: CWORK(:)
complex(kind=8) :: C(LDC1,LDC2,N3,2)

Lines 21-22 in SRC_lapw0/vresp.F:

DOUBLE PRECISION   DWORK(:)
COMPLEX*16   CWORK(:)

It runs without error with the following changes.

Lines 392-293 in SRC_lapw0/fft_modules.F:

real(kind=8) DWORK(*)
complex(kind=8) CWORK(*)

  "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??

Lines 21-22 in SRC_lapw0/vresp.F:

DOUBLE PRECISION   DWORK(*)
COMPLEX*16   CWORK(*)

as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"

On 8/23/2012 12:58 PM, Gavin Abo wrote:
I was able to reproduce the error with your files when the fftpack routine is 
used in Wien2k 12.1.  Ran a couple cycles, and the error did not appear when 
fftw3 was used instead.  So a possible solution may be to use the fftw3 library.

The fftw3 may be faster than the fftpack, so you probably want to use it 
anyway.  It should be easy to use the fftw3 on Debian. fftw3 might already be 
installed or I believe you can install it with:

apt-get install libfftw3-dev

Open the Makefile in a text editor:

vi $WIENROOT/SRC_lapw0/Makefile

Edit and save settings to use for sequential (non-mpi):

FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -DFFTW3 -traceback
R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core 
-openmp -lpthread -lfftw3

In $WIENROOT/SRC_lapw0:

make
cp lapw0 ..

As described in section 11.1.1 of the Wien2k 12.1 userguide, the same can be 
done with lapw2.  Instructions for using the possible faster mkl-fftw3 for 
sequential (non-mpi) instead of the above described fftw3 from a Debian 
repository is also given.

On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
Dear Wien2k users and developers,

   I would like to report the same problem sent to the list by Dr. Eitel 
Peltzer.
   I am running WIEN2k_12.1 on a DELL Precision workstation with two QuadCore 
Xeon processors and Debian Linux. It was compiled using ifort 2011.3.174, icc 
and MKL. The compilation options were:

 O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML 
-traceback
 L   Linker Flags:$(FOPT) 
-L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
 P   Preprocessor flags   '-DParallel'
 R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64 
-lmkl_intel_thread -lmkl_core -openmp -lpthread

   I have followed section 4.5.9 of the Users Guide and everything is 0K until 
the change of indxc to 28 in case.in0 and 50 in case.in0_grr. After this, the 
SCF cycle stops in the second lapw0 run with the following error message:

hup: Command not found.
 LAPW0 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
lapw0  0040505E  c3fft_1_  119  
fftpack_helpers.f
lapw0

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Laurence Marks

Can you change everything to complex*16 ? It makes sense to do everything
with double precision, I would be concerned with the accuracy of complex*8
as well as mixing precisions.

---
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
 On Aug 23, 2012 6:19 PM, "Gavin Abo"  wrote:

>  The situational problem with the fftpack routine might be due to some
> inconsistency in the array usage.  Maybe Prof. Blaha can provide or confirm
> whether the fix below works properly.
>
> Lines 392-294 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) :: DWORK(:)
> complex(kind=8) :: CWORK(:)
> complex(kind=8) :: C(LDC1,LDC2,N3,2)
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(:)
> COMPLEX*16   CWORK(:)
>
> It runs without error with the following changes.
>
> Lines 392-293 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) DWORK(*)
> complex(kind=8) CWORK(*)
>
>   "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(*)
> COMPLEX*16   CWORK(*)
>
> as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"
>
> On 8/23/2012 12:58 PM, Gavin Abo wrote:
>
> I was able to reproduce the error with your files when the fftpack routine
> is used in Wien2k 12.1.  Ran a couple cycles, and the error did not appear
> when fftw3 was used instead.  So a possible solution may be to use the
> fftw3 library.
>
> The fftw3 may be faster than the fftpack, so you probably want to use it
> anyway.  It should be easy to use the fftw3 on Debian. fftw3 might already
> be installed or I believe you can install it with:
>
> *apt-get install libfftw3-dev*
>
> Open the Makefile in a text editor:
>
> *vi $WIENROOT/SRC_lapw0/Makefile*
>
> Edit and save settings to use for sequential (non-mpi):
>
> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML *-DFFTW3*-traceback
> R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
> -lmkl_core -openmp -lpthread* -lfftw3*
>
> In $WIENROOT/SRC_lapw0:
>
> *make
> cp lapw0 ..
> *
> As described in section 11.1.1 of the Wien2k 12.1 userguide, the same can
> be done with lapw2.  Instructions for using the possible faster mkl-fftw3
> for sequential (non-mpi) instead of the above described fftw3 from a Debian
> repository is also given.
>
> On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
>
> Dear Wien2k users and developers,
>
> I would like to report the same problem sent to the list by Dr. Eitel
> Peltzer.
>I am running WIEN2k_12.1 on a DELL Precision workstation with two
> QuadCore Xeon processors and Debian Linux. It was compiled using
> ifort 2011.3.174, icc and MKL. The compilation options were:
>
>   O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip
> -DINTEL_VML -traceback
>  L   Linker Flags:$(FOPT)
> -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
>  P   Preprocessor flags   '-DParallel'
>  R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64
> -lmkl_intel_thread -lmkl_core -openmp -lpthread
>
> I have followed section 4.5.9 of the Users Guide and everything is 0K
> until the change of indxc to 28 in case.in0 and 50 in case.in0_grr. After
> this, the SCF cycle stops in the second lapw0 run with the following error
> message:
>
>  hup: Command not found.
>  LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLineSource
>
> lapw0  0040505E  c3fft_1_  119
>  fftpack_helpers.f
> lapw0  00412D5B  fftpack_mp_c3fft_ 397
>  fft_modules.F
> lapw0  0047F4EC  vresp_106  vresp.F
> lapw0  00495769  xcpot3_   147
>  xcpot3.F
> lapw0  0045C064  MAIN__   1935  lapw0.F
> lapw0  00403D6C  Unknown   Unknown  Unknown
> libc.so.6  2B1096C82C8D  Unknown   Unknown  Unknown
> lapw0  00403C69  Unknown   Unknown  Unknown
>
>  >   stop error
>
>
> I am sending the case.struct and case.in0 files as requested by Prof.
> Blaha. I have also saved the previous PBE calculation and I can send it if
> necessary (8.5 MB).
>Thanks in advance,
>   Luis Ogando
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Gavin Abo

I believe "complex(kind=8)" is the same as "complex*16", just a 
different notation for it.

If the suggested possible fix works, an if statement in vresp.F to use 
the lines like "DWORK(:)" for fftw2/3 and "DWORK(*)" for fftpack would 
be needed.  Else, probably the original fft_modules.F and vresp.F would 
have to be used with some type of changes in fftpack_helpers.f instead.

On 8/23/2012 5:24 PM, Laurence Marks wrote:
>
> Can you change everything to complex*16 ? It makes sense to do 
> everything with double precision, I would be concerned with the 
> accuracy of complex*8 as well as mixing precisions.
>
> ---
> 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
>
> On Aug 23, 2012 6:19 PM, "Gavin Abo"  > wrote:
>
> The situational problem with the fftpack routine might be due to
> some inconsistency in the array usage.  Maybe Prof. Blaha can
> provide or confirm whether the fix below works properly.
>
> Lines 392-294 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) :: DWORK(:)
> complex(kind=8) :: CWORK(:)
> complex(kind=8) :: C(LDC1,LDC2,N3,2)
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(:)
> COMPLEX*16   CWORK(:)
>
> It runs without error with the following changes.
>
> Lines 392-293 in SRC_lapw0/fft_modules.F:
>
> real(kind=8) DWORK(*)
> complex(kind=8) CWORK(*)
>
>   "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??
>
> Lines 21-22 in SRC_lapw0/vresp.F:
>
> DOUBLE PRECISION   DWORK(*)
> COMPLEX*16   CWORK(*)
>
> as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"
>
> On 8/23/2012 12:58 PM, Gavin Abo wrote:
>> I was able to reproduce the error with your files when the
>> fftpack routine is used in Wien2k 12.1.  Ran a couple cycles, and
>> the error did not appear when fftw3 was used instead.  So a
>> possible solution may be to use the fftw3 library.
>>
>> The fftw3 may be faster than the fftpack, so you probably want to
>> use it anyway.  It should be easy to use the fftw3 on Debian.
>> fftw3 might already be installed or I believe you can install it
>> with:
>>
>> *apt-get install libfftw3-dev*
>>
>> Open the Makefile in a text editor:
>>
>> *vi $WIENROOT/SRC_lapw0/Makefile*
>>
>> Edit and save settings to use for sequential (non-mpi):
>>
>> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML *-DFFTW3*
>> -traceback
>> R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread
>> -lmkl_core -openmp -lpthread*-lfftw3*
>>
>> In $WIENROOT/SRC_lapw0:
>>
>> *make
>> cp lapw0 ..
>> *
>> As described in section 11.1.1 of the Wien2k 12.1 userguide, the
>> same can be done with lapw2. Instructions for using the possible
>> faster mkl-fftw3 for sequential (non-mpi) instead of the above
>> described fftw3 from a Debian repository is also given.
>>
>> On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
>>> Dear Wien2k users and developers,
>>>
>>>I would like to report the same problem sent to the list by
>>> Dr. Eitel Peltzer.
>>>I am running WIEN2k_12.1 on a DELL Precision workstation with
>>> two QuadCore Xeon processors and Debian Linux. It was compiled
>>> using ifort 2011.3.174, icc and MKL. The compilation options were:
>>>
>>>  O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad
>>> -ip -DINTEL_VML -traceback
>>>  L   Linker Flags:$(FOPT)
>>> -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
>>>  P   Preprocessor flags   '-DParallel'
>>>  R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64
>>> -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -openmp -lpthread
>>>
>>>I have followed section 4.5.9 of the Users Guide and
>>> everything is 0K until the change of indxc to 28 in case.in0 and
>>> 50 in case.in0_grr. After this, the SCF cycle stops in the
>>> second lapw0 run with the following error message:
>>>
>>> hup: Command not found.
>>>  LAPW0 END
>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>> Image  PCRoutine  Line  
>>>  Source
>>> lapw0  0040505E  c3fft_1_119
>>>  fftpack_helpers.f
>>> lapw0  00412D5B  fftpack_mp_c3fft_
>>> 397  fft_modules.F
>>> lapw0  0047F4EC  vresp_106
>>>  vresp.F
>>> lapw0  00495769  xcpot3_ 147
>>>  xcpot3.F
>>> lapw0

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Gavin Abo

The situational problem with the fftpack routine might be due to some 
inconsistency in the array usage.  Maybe Prof. Blaha can provide or 
confirm whether the fix below works properly.

Lines 392-294 in SRC_lapw0/fft_modules.F:

 real(kind=8) :: DWORK(:)
 complex(kind=8) :: CWORK(:)
 complex(kind=8) :: C(LDC1,LDC2,N3,2)

Lines 21-22 in SRC_lapw0/vresp.F:

 DOUBLE PRECISION   DWORK(:)
 COMPLEX*16   CWORK(:)

It runs without error with the following changes.

Lines 392-293 in SRC_lapw0/fft_modules.F:

 real(kind=8) DWORK(*)
 complex(kind=8) CWORK(*)

   "complex(kind=8) C(LDC1,LDC2,N3,2)" needed too??

Lines 21-22 in SRC_lapw0/vresp.F:

 DOUBLE PRECISION   DWORK(*)
 COMPLEX*16   CWORK(*)

as the subroutine in SRC_lapw0/fftpack_helpers.f has "DWORK(*)"

On 8/23/2012 12:58 PM, Gavin Abo wrote:
> I was able to reproduce the error with your files when the fftpack 
> routine is used in Wien2k 12.1.  Ran a couple cycles, and the error 
> did not appear when fftw3 was used instead.  So a possible solution 
> may be to use the fftw3 library.
>
> The fftw3 may be faster than the fftpack, so you probably want to use 
> it anyway.  It should be easy to use the fftw3 on Debian. fftw3 might 
> already be installed or I believe you can install it with:
>
> *apt-get install libfftw3-dev*
>
> Open the Makefile in a text editor:
>
> *vi $WIENROOT/SRC_lapw0/Makefile*
>
> Edit and save settings to use for sequential (non-mpi):
>
> FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML *-DFFTW3* 
> -traceback
> R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread 
> -lmkl_core -openmp -lpthread*-lfftw3*
>
> In $WIENROOT/SRC_lapw0:
>
> *make
> cp lapw0 ..
> *
> As described in section 11.1.1 of the Wien2k 12.1 userguide, the same 
> can be done with lapw2.  Instructions for using the possible faster 
> mkl-fftw3 for sequential (non-mpi) instead of the above described 
> fftw3 from a Debian repository is also given.
>
> On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
>> Dear Wien2k users and developers,
>>
>>I would like to report the same problem sent to the list by Dr. 
>> Eitel Peltzer.
>>I am running WIEN2k_12.1 on a DELL Precision workstation with two 
>> QuadCore Xeon processors and Debian Linux. It was compiled using 
>> ifort 2011.3.174, icc and MKL. The compilation options were:
>>
>>  O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip 
>> -DINTEL_VML -traceback
>>  L   Linker Flags:$(FOPT) 
>> -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
>>  P   Preprocessor flags   '-DParallel'
>>  R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64 
>> -lmkl_intel_thread -lmkl_core -openmp -lpthread
>>
>>I have followed section 4.5.9 of the Users Guide and everything is 
>> 0K until the change of indxc to 28 in case.in0 and 50 in 
>> case.in0_grr. After this, the SCF cycle stops in the second lapw0 run 
>> with the following error message:
>>
>> hup: Command not found.
>>  LAPW0 END
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image  PCRoutine  LineSource
>> lapw0  0040505E  c3fft_1_119 
>>  fftpack_helpers.f
>> lapw0  00412D5B  fftpack_mp_c3fft_ 397 
>>  fft_modules.F
>> lapw0  0047F4EC  vresp_106  vresp.F
>> lapw0  00495769  xcpot3_ 147  xcpot3.F
>> lapw0  0045C064  MAIN__   1935  lapw0.F
>> lapw0  00403D6C  Unknown Unknown  Unknown
>> libc.so.6  2B1096C82C8D  Unknown Unknown  Unknown
>> lapw0  00403C69  Unknown Unknown  Unknown
>>
>> >   stop error
>>
>>
>>I am sending the case.struct and case.in0 files as requested by 
>> Prof. Blaha. I have also saved the previous PBE calculation and I can 
>> send it if necessary (8.5 MB).
>>Thanks in advance,
>>   Luis Ogando

-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread ei...@iflysib.unlp.edu.ar

Dear Wien users,

   I did what Peter Blaha suggest, download the SRC_lapw0.tar and  
compile again, here appeared an error, in my distribution of ubuntu,  
the library fftw3xf does not exist, then I followed the suggestions of  
Gavin Abo, installing the libfftw3-dev and making the changes in the  
makefile. I compile lapw0 again without any errors. The self  
consistent cycle is running without problem.

Thanks for the help.

  Eitel


This message was sent using IMP, the Internet Messaging Program.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Peter Blaha

Most likely the calculation of the mBJ potential on some grid-points in 
the interstitial has failed.

This could come from:
i) a bad starting (incorrect/incompatible case.vsp, case.vresp and 
clmsum files).
ii) since you have a structure with huge vacuum region or very heave 
atoms ???
iii) lousy convergence parameters (too small RKmax, GMAX, FFTW-grid in 
case.in0),...
iv) a problem in our bBJ routines (possible, but now rather unlikely)

Can you run mBJ in other cases ?

Restore the PBE calc and run a few PBE cycles, rm *.bro*, retry mBJ.

increase FFTW-mesh in case.in0

If nothing helps, you need to send me the specific case and I have to 
test it myself.

Am 23.08.2012 15:12, schrieb eitel at iflysib.unlp.edu.ar:
> Dear Wien users,
>
> I have had problems when I try to run the cycle mBJ, on in the first
> iteration, the error is:
>
>   LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLineSource
> lapw0  00404F58  c3fft_1_  119
> fftpack_helpers.f
> lapw0  00411EC1  fftpack_mp_c3fft_ 397
> fft_modules.F
> lapw0  0047B3ED  vresp_106  vresp.F
> lapw0  004913E8  xcpot3_   147
> xcpot3.F
> lapw0  004582D9  MAIN__   1935  lapw0.F
> lapw0  00403CEC  Unknown   Unknown  Unknown
> libc.so.6  2B57EE0B7EFF  Unknown   Unknown  Unknown
> lapw0  00403BE9  Unknown   Unknown  Unknown
>
>>   stop error
>
> can someone tell me what is the origin for this error?
>
>Thanking in advance.
>
>Eitel Peltzer
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>

-- 
Peter Blaha
Inst.Materials Chemistry
TU Vienna
Getreidemarkt 9
A-1060 Vienna
Austria
+43-1-5880115671

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread ei...@iflysib.unlp.edu.ar

   Dear Prof. Blaha,

I carefully followed the suggestions, but nothing improved, I ran  
another material and the result was exactly the same. The problem  
appears when I run the mBJ cycle and apparently due the the change in  
case.in0 of the value 13 for 28. I am sending you the struct file.

   best

  Eitel

PS: I am using the 12.1 version.


Peter Blaha  ha escrito:

> Most likely the calculation of the mBJ potential on some grid-points in
> the interstitial has failed.
>
> This could come from:
> i) a bad starting (incorrect/incompatible case.vsp, case.vresp and
> clmsum files).
> ii) since you have a structure with huge vacuum region or very heave  
>  atoms ???
> iii) lousy convergence parameters (too small RKmax, GMAX, FFTW-grid in
> case.in0),...
> iv) a problem in our bBJ routines (possible, but now rather unlikely)
>
> Can you run mBJ in other cases ?
>
> Restore the PBE calc and run a few PBE cycles, rm *.bro*, retry mBJ.
>
> increase FFTW-mesh in case.in0
>
> If nothing helps, you need to send me the specific case and I have to
> test it myself.
>
> Am 23.08.2012 15:12, schrieb eitel at iflysib.unlp.edu.ar:
>> Dear Wien users,
>>
>> I have had problems when I try to run the cycle mBJ, on in the first
>> iteration, the error is:
>>
>>  LAPW0 END
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image  PCRoutineLineSource
>> lapw0  00404F58  c3fft_1_  119
>> fftpack_helpers.f
>> lapw0  00411EC1  fftpack_mp_c3fft_ 397
>> fft_modules.F
>> lapw0  0047B3ED  vresp_106  vresp.F
>> lapw0  004913E8  xcpot3_   147
>> xcpot3.F
>> lapw0  004582D9  MAIN__   1935  lapw0.F
>> lapw0  00403CEC  Unknown   Unknown  Unknown
>> libc.so.6  2B57EE0B7EFF  Unknown   Unknown  Unknown
>> lapw0  00403BE9  Unknown   Unknown  Unknown
>>
>>>  stop error
>>
>> can someone tell me what is the origin for this error?
>>
>>   Thanking in advance.
>>
>>   Eitel Peltzer
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>
> -- 
> Peter Blaha
> Inst.Materials Chemistry
> TU Vienna
> Getreidemarkt 9
> A-1060 Vienna
> Austria
> +43-1-5880115671
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.




This message was sent using IMP, the Internet Messaging Program.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Gavin Abo

I was able to reproduce the error with your files when the fftpack 
routine is used in Wien2k 12.1.  Ran a couple cycles, and the error did 
not appear when fftw3 was used instead.  So a possible solution may be 
to use the fftw3 library.

The fftw3 may be faster than the fftpack, so you probably want to use it 
anyway.  It should be easy to use the fftw3 on Debian. fftw3 might 
already be installed or I believe you can install it with:

*apt-get install libfftw3-dev*

Open the Makefile in a text editor:

*vi $WIENROOT/SRC_lapw0/Makefile*

Edit and save settings to use for sequential (non-mpi):

FOPT = -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML *-DFFTW3* -traceback
R_LIBS = -lmkl_lapack95_lp64 -lmkl_intel_lp64 -lmkl_intel_thread 
-lmkl_core -openmp -lpthread*-lfftw3*

In $WIENROOT/SRC_lapw0:

*make
cp lapw0 ..
*
As described in section 11.1.1 of the Wien2k 12.1 userguide, the same 
can be done with lapw2.  Instructions for using the possible faster 
mkl-fftw3 for sequential (non-mpi) instead of the above described fftw3 
from a Debian repository is also given.

On 8/23/2012 8:06 AM, Luis Carlos Ogando Dacal wrote:
> Dear Wien2k users and developers,
>
>I would like to report the same problem sent to the list by Dr. 
> Eitel Peltzer.
>I am running WIEN2k_12.1 on a DELL Precision workstation with two 
> QuadCore Xeon processors and Debian Linux. It was compiled using 
> ifort 2011.3.174, icc and MKL. The compilation options were:
>
>  O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip 
> -DINTEL_VML -traceback
>  L   Linker Flags:$(FOPT) 
> -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
>  P   Preprocessor flags   '-DParallel'
>  R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64 
> -lmkl_intel_thread -lmkl_core -openmp -lpthread
>
>I have followed section 4.5.9 of the Users Guide and everything is 
> 0K until the change of indxc to 28 in case.in0 and 50 in case.in0_grr. 
> After this, the SCF cycle stops in the second lapw0 run with the 
> following error message:
>
> hup: Command not found.
>  LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutine  LineSource
> lapw0  0040505E  c3fft_1_  119  fftpack_helpers.f
> lapw0  00412D5B  fftpack_mp_c3fft_   397 
>  fft_modules.F
> lapw0  0047F4EC  vresp_  106  vresp.F
> lapw0  00495769  xcpot3_   147  xcpot3.F
> lapw0  0045C064  MAIN__ 1935  lapw0.F
> lapw0  00403D6C  Unknown   Unknown  Unknown
> libc.so.6  2B1096C82C8D  Unknown   Unknown  Unknown
> lapw0  00403C69  Unknown   Unknown  Unknown
>
> >   stop error
>
>
>I am sending the case.struct and case.in0 files as requested by 
> Prof. Blaha. I have also saved the previous PBE calculation and I can 
> send it if necessary (8.5 MB).
>Thanks in advance,
>   Luis Ogando
>
>
>
>
>
> 2012/8/23 mailto:eitel at iflysib.unlp.edu.ar>>
>
> Dear Wien users,
>
> I have had problems when I try to run the cycle mBJ, on in the
> first iteration, the error is:
>
>  LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLine  
>  Source
> lapw0  00404F58  c3fft_1_119
>  fftpack_helpers.f
> lapw0  00411EC1  fftpack_mp_c3fft_   397
>  fft_modules.F
> lapw0  0047B3ED  vresp_106  vresp.F
> lapw0  004913E8  xcpot3_   147  xcpot3.F
> lapw0  004582D9  MAIN__   1935  lapw0.F
> lapw0  00403CEC  Unknown Unknown  Unknown
> libc.so.6  2B57EE0B7EFF  Unknown Unknown  Unknown
> lapw0  00403BE9  Unknown Unknown  Unknown
>
>   stop error
>
>
> can someone tell me what is the origin for this error?
>
>   Thanking in advance.
>
>   Eitel Peltzer
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> 
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- next part --
An HTML attachment was scrubbed...
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Luis Carlos Ogando Dacal

Dear Wien2k users and developers,

   I would like to report the same problem sent to the list by Dr. Eitel
Peltzer.
   I am running WIEN2k_12.1 on a DELL Precision workstation with two
QuadCore Xeon processors and Debian Linux. It was compiled using
ifort 2011.3.174, icc and MKL. The compilation options were:

 O   Compiler options:-FR -mp1 -w -prec_div -pc80 -pad -ip
-DINTEL_VML -traceback
 L   Linker Flags:$(FOPT)
-L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 -pthread
 P   Preprocessor flags   '-DParallel'
 R   R_LIB (LAPACK+BLAS): -lmkl_lapack95_lp64 -lmkl_intel_lp64
-lmkl_intel_thread -lmkl_core -openmp -lpthread

   I have followed section 4.5.9 of the Users Guide and everything is 0K
until the change of indxc to 28 in case.in0 and 50 in case.in0_grr. After
this, the SCF cycle stops in the second lapw0 run with the following error
message:

hup: Command not found.
 LAPW0 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource

lapw0  0040505E  c3fft_1_  119
 fftpack_helpers.f
lapw0  00412D5B  fftpack_mp_c3fft_ 397
 fft_modules.F
lapw0  0047F4EC  vresp_106  vresp.F
lapw0  00495769  xcpot3_   147  xcpot3.F
lapw0  0045C064  MAIN__   1935  lapw0.F
lapw0  00403D6C  Unknown   Unknown  Unknown
libc.so.6  2B1096C82C8D  Unknown   Unknown  Unknown
lapw0  00403C69  Unknown   Unknown  Unknown

>   stop error


   I am sending the case.struct and case.in0 files as requested by Prof.
Blaha. I have also saved the previous PBE calculation and I can send it if
necessary (8.5 MB).
   Thanks in advance,
  Luis Ogando





2012/8/23 

> Dear Wien users,
>
> I have had problems when I try to run the cycle mBJ, on in the first
> iteration, the error is:
>
>  LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLineSource
> lapw0  00404F58  c3fft_1_  119
>  fftpack_helpers.f
> lapw0  00411EC1  fftpack_mp_c3fft_ 397
>  fft_modules.F
> lapw0  0047B3ED  vresp_106  vresp.F
> lapw0  004913E8  xcpot3_   147
>  xcpot3.F
> lapw0  004582D9  MAIN__   1935  lapw0.F
> lapw0  00403CEC  Unknown   Unknown  Unknown
> libc.so.6  2B57EE0B7EFF  Unknown   Unknown  Unknown
> lapw0  00403BE9  Unknown   Unknown  Unknown
>
>stop error
>>
>
> can someone tell me what is the origin for this error?
>
>   Thanking in advance.
>
>   Eitel Peltzer
>
> --**--**
> This message was sent using IMP, the Internet Messaging Program.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> __**_
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.**at 
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: BandChara.struct
Type: application/octet-stream
Size: 3927 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: BandChara.in1c
Type: application/octet-stream
Size: 1979 bytes
Desc: not available
URL:

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread ei...@iflysib.unlp.edu.ar

Dear Wien users,

I have had problems when I try to run the cycle mBJ, on in the first  
iteration, the error is:

  LAPW0 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource
lapw0  00404F58  c3fft_1_  119   
fftpack_helpers.f
lapw0  00411EC1  fftpack_mp_c3fft_ 397   
fft_modules.F
lapw0  0047B3ED  vresp_106  vresp.F
lapw0  004913E8  xcpot3_   147  xcpot3.F
lapw0  004582D9  MAIN__   1935  lapw0.F
lapw0  00403CEC  Unknown   Unknown  Unknown
libc.so.6  2B57EE0B7EFF  Unknown   Unknown  Unknown
lapw0  00403BE9  Unknown   Unknown  Unknown

>   stop error

can someone tell me what is the origin for this error?

   Thanking in advance.

   Eitel Peltzer


This message was sent using IMP, the Internet Messaging Program.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[Wien] Problems in the 1st step of the SCF cycle of mBj

2012-08-23 Thread Parker, David S.

I have had this problem too, only with mBJ, in the latest (2012) version
of WIEN, which I solved by using an earlier (in this case 2010) version of
lapw0 in WIENROOT.  This is obviously not an ideal solution, however, and
I wonder if there is a better way - perhaps a compilation option? - David
Parker

On 8/23/12 9:12 AM, "eitel at iflysib.unlp.edu.ar"
 wrote:

>Dear Wien users,
>
>I have had problems when I try to run the cycle mBJ, on in the first
>iteration, the error is:
>
>  LAPW0 END
>forrtl: severe (174): SIGSEGV, segmentation fault occurred
>Image  PCRoutineLineSource
>lapw0  00404F58  c3fft_1_  119
>fftpack_helpers.f
>lapw0  00411EC1  fftpack_mp_c3fft_ 397
>fft_modules.F
>lapw0  0047B3ED  vresp_106
>vresp.F
>lapw0  004913E8  xcpot3_   147
>xcpot3.F
>lapw0  004582D9  MAIN__   1935
>lapw0.F
>lapw0  00403CEC  Unknown   Unknown
>Unknown
>libc.so.6  2B57EE0B7EFF  Unknown   Unknown
>Unknown
>lapw0  00403BE9  Unknown   Unknown
>Unknown
>
>>   stop error
>
>can someone tell me what is the origin for this error?
>
>   Thanking in advance.
>
>   Eitel Peltzer
>
>
>This message was sent using IMP, the Internet Messaging Program.
>
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>___
>Wien mailing list
>Wien at zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

[Wien] Problems in the 1st step of the SCF cycle of mBj

17 matches

Site Navigation

Mail list logo

Footer information