[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Peter Blaha
pblaha at theochem.tuwien.ac.at
Thu Dec 20 17:03:14 CET 2012
I think the best fix is what you told me before:
Modify lapwso and insert the write statement.
Alternatively one can play with compiler options, but this may slow down
the code.
On 12/20/2012 04:57 PM, Zhu, Jianxin wrote:
> Dear Peter,
>
> I pull the discussion back to the mailing list.
>
> For the observations I made these days, they were collected on the machine
> under Mac OSX 10.6.8 installed with Intel Compiler 11.1/089.
> Therefore, the program listed only the error ---
>
> forrtl: severe (24): end-of-file during read, unit 30, file
> /Users/jxzhu/Research/lapw_dta/fcc-Np/fcc-Np.energysoup
>
>
> I just tested the case on another machine under Mac OSX 10.7.4 installed
> with Intel Composer 2013.1.119.
> There is more information given in addition to error ---
>
> forrtl: severe (24): end-of-file during read, unit 30, file
> /Users/jxzhu/Research/lapw_dta/fcc-Np/fcc-Np.energysoup
>
> Image PC Routine Line Source
>
>
> Stack trace terminated abnormally.
> cp: .in.tmp: No such file or directory
>
>> stop error
>
>
>
> The OPTIONS for all wien2k.12.1 compilations on these machines is the same
> and has the following
>
> current:FOPT:-free -mp1 -prec-div -pc80 -pad -align -traceback
> current:FPOPT:-FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -DFFTW3
> current:LDFLAGS:$(FOPT) -L/opt/intel/Composer/mkl/lib
> current:DPARALLEL:'-DParallel'
> current:R_LIBS:-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
> -lpthread
> current:RP_LIBS:-lmkl_scalapack_lp64 -lmkl_solver_lp64 -lmkl_blacs_lp64
> -L/opt/local/fftw3/lib/ -lfftw3_mpi -lfftw3 $(R_LIBS)
> current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
>
>
>
> Do you have a suggestion on the change with compiler option to get a
> simple fix?
>
> Thanks,
>
> Jianxin
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
> Date: Thu, 20 Dec 2012 10:11:06 +0100
> To: Jian-Xin Zhu <jxzhu at lanl.gov>
> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so
> -orb"on Mac OSX
>
>> Seems to be some compiler bug. Always possible (and of course of
>> interest for other mac users as well !)
>>
>> Am 20.12.2012 05:42, schrieb Zhu, Jianxin:
>>> Dear Peter,
>>>
>>> I take this discussion off the mailing list. Since the issue is so
>>> specific,
>>> I am afraid it will offend other users if I post it to the mailing list.
>>>
>>> I have done a few more tests. The issue becomes even more interesting.
>>>
>>> When I simply insert the following
>>>
>>> !BGN JXZ
>>> write(*,*) 'Finish initialization of structure parameter in
>>> lapwso!'
>>> !END JXZ
>>>
>>> between line 57 and line 58 in the original lapwso.f file, that is,
>>>
>>>
>>> ...
>>> CALL init_struct
>>> !BGN JXZ
>>> write(*,*) 'Finish initialization of structure parameter in
>>> lapwso!'
>>> !END JXZ
>>> CALL init_ams
>>> ...
>>>
>>> the code then runs just fine regardless of how long the absolute path of
>>> SCRATCH.
>>> By this, I mean that the command line script "runsp_lapw -so -orb -cc
>>> 0.0001 -NI -i 10", runs successfully.
>>>
>>> But I don't understand why it works this way.
>>>
>>> Best regards,
>>>
>>> Jianxin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
>>> Reply-To: A Mailing list for WIEN2k users
>>> <wien at zeus.theochem.tuwien.ac.at>
>>> Date: Tue, 18 Dec 2012 07:55:08 +0100
>>> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
>>> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so
>>> -orb"on Mac OSX
>>>
>>>> Of course SO breaks cubic symmetry and reduces symmetry. You MUST use
>>>> symmetso during
>>>> initso.
>>>> However, it is not necessary to change from F to P symmetry and
>>>> introduce
>>>> 4 atoms, unless you want to introduce some possible non-equivalency of
>>>> the
>>>> atoms in your cell.
>>>>
>>>> In any case, this cannot be the reason about your SCRATCH-problem,
>>>> which
>>>> seems
>>>> to be something completely different now...
>>>>
>>>> Am 17.12.2012 21:15, schrieb Zhu, Jianxin:
>>>>> Peter,
>>>>>
>>>>> Instead of doing change to the source code, I am asking myself a
>>>>> question.
>>>>> For an original fcc structure in the paramagnetic state, by which I
>>>>> mean
>>>>> there is only one atom in case.struct,
>>>>> can it still be used for the "runsp_lapw -so -orb" for a ferromagnetic
>>>>> state?
>>>>>
>>>>> The answer seems to be negative.
>>>>> Because when we have spin-orbit coupling in a magnetic state, the
>>>>> symmetry
>>>>> can be reduced and the equivalent atoms can be reduced.
>>>>> However, if the structure file has only one atom (like fcc Fe), there
>>>>> is
>>>>> no degree of freedom to adjust the number of non-equivalent atoms.
>>>>> Therefore, I change the structure file to have 4 atoms (the same
>>>>> element,
>>>>> two non-equivalent types) like
>>>>>
>>>>>
>>>>> P LATTICE,NONEQUIV.ATOMS: 2221_Pm-3m
>>>>> MODE OF CALC=RELA unit=bohr
>>>>> 8.140000 8.140000 8.140000 90.000000 90.000000 90.000000
>>>>> ATOM 1: X=0.00000000 Y=0.00000000 Z=0.00000000
>>>>> MULT= 1 ISPLIT= 2
>>>>> Np1 NPT= 781 R0=0.00000500 RMT= 2.50000 Z: 93.0
>>>>> LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
>>>>> 0.0000000 1.0000000 0.0000000
>>>>> 0.0000000 0.0000000 1.0000000
>>>>> ATOM -2: X=0.50000000 Y=0.50000000 Z=0.00000000
>>>>> MULT= 3 ISPLIT=-2
>>>>> -2: X=0.00000000 Y=0.50000000 Z=0.50000000
>>>>> -2: X=0.50000000 Y=0.00000000 Z=0.50000000
>>>>> Np2 NPT= 781 R0=0.00000500 RMT= 2.50000 Z: 93.0
>>>>> LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
>>>>> 0.0000000 1.0000000 0.0000000
>>>>> 0.0000000 0.0000000 1.0000000
>>>>> 48 NUMBER OF SYMMETRY OPERATIONS
>>>>> -1 0 0 0.00000000
>>>>> 0-1 0 0.00000000
>>>>> 0 0-1 0.00000000
>>>>> ....
>>>>>
>>>>>
>>>>> During the initso_lapw run, I accept the new structure file from
>>>>> symmetso.
>>>>> The new structure file then contains
>>>>>
>>>>> P 3 221
>>>>> RELA
>>>>> 8.140000 8.140000 8.140000 90.000000 90.000000 90.000000
>>>>> ATOM -1: X=0.00000000 Y=0.00000000 Z=0.00000000
>>>>> MULT= 1 ISPLIT=-2
>>>>> Np1 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
>>>>> LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
>>>>> 0.0000000 1.0000000 0.0000000
>>>>> 0.0000000 0.0000000 1.0000000
>>>>> ATOM -2: X=0.50000000 Y=0.50000000 Z=0.00000000
>>>>> MULT= 1 ISPLIT=-2
>>>>> Np2 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
>>>>> LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
>>>>> 0.0000000 1.0000000 0.0000000
>>>>> 0.0000000 0.0000000 1.0000000
>>>>> ATOM -3: X=0.00000000 Y=0.50000000 Z=0.50000000
>>>>> MULT= 2 ISPLIT= 8
>>>>> -3: X=0.50000000 Y=0.00000000 Z=0.50000000
>>>>> Np3 NPT= 781 R0=.000005000 RMT= 2.50000 Z: 93.00000
>>>>> LOCAL ROT MATRIX: 1.0000000 0.0000000 0.0000000
>>>>> 0.0000000 1.0000000 0.0000000
>>>>> 0.0000000 0.0000000 1.0000000
>>>>> 16 NUMBER OF SYMMETRY OPERATIONS
>>>>> 1 0 0 0.00000000
>>>>> 0 1 0 0.00000000
>>>>> 0 0 1 0.00000000
>>>>> ...
>>>>>
>>>>> Now the code runs properly on my Mac OSX machines.
>>>>>
>>>>> Please advise whether this adjustment makes sense to you.
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Jianxin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
>>>>> Reply-To: A Mailing list for WIEN2k users
>>>>> <wien at zeus.theochem.tuwien.ac.at>
>>>>> Date: Mon, 17 Dec 2012 17:52:30 +0100
>>>>> To: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
>>>>> Subject: Re: [Wien] Some interesting observation with "runsp_lapw -so
>>>>> -orb"on Mac OSX
>>>>>
>>>>>> I have another guess, also I'm not sure if it fixes the problem. It
>>>>>> could be that some long pathnames get truncated:
>>>>>>
>>>>>> When reading the filnames which are stored in the def files, some
>>>>>> "older" programs (like lapwso) have still
>>>>>>
>>>>>> character*80 ...,fname,...
>>>>>>
>>>>>> while others have changed this to character*180
>>>>>>
>>>>>> Change in lapwso.f:
>>>>>>
>>>>>> character*80 deffn,errfn,fname
>>>>>> to
>>>>>> character*80 deffn,errfn
>>>>>> character*180 fname
>>>>>>
>>>>>>
>>>>>> Let me know if this fixes the problem.
>>>>>>
>>>>>> PS: Is there no other information when lapwso does not write the
>>>>>> energyso files ? It should complain that it cannot read the vector
>>>>>> files.
>>>>>>
>>>>>> *error files, *outputso file ???
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/17/2012 04:38 PM, Zhu, Jianxin wrote:
>>>>>>> Peter,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Peter Blaha <pblaha at theochem.tuwien.ac.at>
>>>>>>> Reply-To: A Mailing list for WIEN2k users
>>>>>>> <wien at zeus.theochem.tuwien.ac.at>
>>>>>>> Date: Mon, 17 Dec 2012 07:59:04 +0100
>>>>>>> To: A Mailing list for WIEN2k users
>>>>>>> <wien at zeus.theochem.tuwien.ac.at>
>>>>>>> Subject: Re: [Wien] Some interesting observation with "runsp_lapw
>>>>>>> -so
>>>>>>> -orb"on Mac OSX
>>>>>>>
>>>>>>>> I do not have a Mac, so cannot test it. But:
>>>>>>>>
>>>>>>>> does the $SCRATCH directory exist ?
>>>>>>>>
>>>>>>>> what gives: ls -alsrp $SCRATCH
>>>>>>>>
>>>>>>>> do you see the vectorup/dn file generated by lapw1 ?
>>>>>>>
>>>>>>> ...4312510 Dec 17 08:32 nfcc.vectordn
>>>>>>> ...205826 Dec 17 08:32 nfcc.vectorsodn
>>>>>>> ...205826 Dec 17 08:32 nfcc.vectorsoup
>>>>>>> ...4312510 Dec 17 08:32 nfcc.vectorup
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> cat uplapw1.def
>>>>>>>> cat lapwso.def
>>>>>>>
>>>>>>> cat uplapw1.def
>>>>>>> 4,'nfcc.klist', 'unknown','formatted',0
>>>>>>> 5,'nfcc.in1', 'old', 'formatted',0
>>>>>>> 6,'nfcc.output1up','unknown','formatted',0
>>>>>>> 10,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorup',
>>>>>>> 'unknown','unformatted',9000
>>>>>>> 11,'nfcc.energyup', 'unknown','formatted',0
>>>>>>> 18,'nfcc.vspup', 'old', 'formatted',0
>>>>>>> 19,'nfcc.vnsup', 'unknown','formatted',0
>>>>>>> 20,'nfcc.struct', 'old', 'formatted',0
>>>>>>> 21,'nfcc.scf1up', 'unknown','formatted',0
>>>>>>> 55,'nfcc.vec', 'unknown','formatted',0
>>>>>>> 71,'nfcc.nshup', 'unknown','formatted',0
>>>>>>>
>>>>>>> 200,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.storeHinvup',
>>>>>>> 'replace','unformatted',9000
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> cat lapwso.def
>>>>>>> 4 ,'nfcc.in1', 'old', 'formatted',0
>>>>>>> 5 ,'nfcc.inso', 'old', 'formatted',0
>>>>>>> 6 ,'nfcc.outputso', 'unknown','formatted',0
>>>>>>> 8 ,'nfcc.scfso', 'unknown','formatted',0
>>>>>>> 9 ,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectordn',
>>>>>>> 'old', 'unformatted',9000
>>>>>>> 10 ,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorup',
>>>>>>> 'unknown', 'unformatted',9000
>>>>>>> 18,'nfcc.vspdn', 'old','formatted',0
>>>>>>> 19,'nfcc.vspup', 'unknown','formatted',0
>>>>>>> 20 ,'nfcc.struct', 'old', 'formatted',0
>>>>>>> 22,'nfcc.vnsdn', 'old','formatted',0
>>>>>>> 23,'nfcc.vnsup', 'unknown','formatted',0
>>>>>>> 41,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorsodn',
>>>>>>> 'unknown','unformatted',9000
>>>>>>> 42,'/Volumes/Macintosh_HD2/scratch/wien2k_scratch/nfcc.vectorsoup',
>>>>>>> 'unknown','unformatted',9000
>>>>>>> 44,'nfcc.vect1', 'unknown','unformatted',9000
>>>>>>> 45,'nfcc.normsodn', 'unknown','formatted',0
>>>>>>> 46,'nfcc.normsoup', 'unknown','formatted',0
>>>>>>> 51,'nfcc.energysodn', 'unknown','formatted',9000
>>>>>>> 52,'nfcc.energysoup', 'unknown','formatted',9000
>>>>>>> 53,'nfcc.energydum', 'unknown','formatted',9000
>>>>>>> 54,'nfcc.energydn', 'old','formatted',9000
>>>>>>> 55 ,'nfcc.energyup', 'unknown', 'formatted',9000
>>>>>>> 11,'nfcc.vorbdn', 'unknown','formatted',0
>>>>>>> 12,'nfcc.vorbup', 'unknown','formatted',0
>>>>>>> 13,'nfcc.vorbdu', 'unknown','formatted',0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Are the definitions correct ? Do you see the correct path in these
>>>>>>>> def
>>>>>>>> files
>>>>>>>> for the vector files ? Or is a "/" missing ???
>>>>>>>
>>>>>>> I see the correct path and no "/" is missing.
>>>>>>>
>>>>>>>>
>>>>>>>> Maybe the Mac-filesystem does not allow for a path of arbitrary
>>>>>>>> lenght
>>>>>>>> (similar as
>>>>>>>> upper/lower case problems ....) ?
>>>>>>>
>>>>>>>
>>>>>>> If I run other modes like "runsp_lapw -so" or "runsp_lapw -orb",
>>>>>>> etc.,
>>>>>>> there is no problem.
>>>>>>>
>>>>>>>>
>>>>>>>> Eventually, set the SCRATCH variable to
>>>>>>>> /Volumes/Macintosh_HD2/scratch/wien2k_scratch/
>>>>>>>> (with a "/" at the end). The wien2k-scripts should append this
>>>>>>>> automatically, but maybe
>>>>>>>> the sed command behaves differently on the Mac ?
>>>>>>>
>>>>>>>
>>>>>>> As shown above with "cat", the slash "/" is indeed appended
>>>>>>> automatically.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jianxin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Am 17.12.2012 06:02, schrieb Zhu, Jianxin:
>>>>>>>>> Dear Peter and Wien2k users,
>>>>>>>>>
>>>>>>>>> I think it is much more fruitful to get help from you.
>>>>>>>>>
>>>>>>>>> I have always been observing interesting issues with "runsp_lapw
>>>>>>>>> so
>>>>>>>>> orb" (or "runsp_c_lapw so orb") on my Mac OSX machine.
>>>>>>>>>
>>>>>>>>> If I define the scratch as something like ---
>>>>>>>>>
>>>>>>>>> [] jxzhu% echo $SCRATCH
>>>>>>>>> /Volumes/Macintosh_HD2/scratch/wien2k_scratch
>>>>>>>>>
>>>>>>>>> By running wien2k with the above mentioned mode, I get the error
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [] jxzhu% runsp_lapw -so -orb -cc 0.001 -NI -i 1
>>>>>>>>> LAPW0 END
>>>>>>>>> ORB END
>>>>>>>>> ORB END
>>>>>>>>> LAPW1 END
>>>>>>>>> LAPW1 END
>>>>>>>>> LAPWSO END
>>>>>>>>> forrtl: severe (59): list-directed I/O syntax error, unit 30, file
>>>>>>>>> /Users/jxzhu/nfcc/nfcc.energysoup
>>>>>>>>> Image PC Routine Line
>>>>>>>>> Source
>>>>>>>>> lapw2c 00000001001274AC Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 0000000100125FD4 Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 00000001000F852E Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 00000001000AF83A Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 00000001000AF009 Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 00000001000DA81E Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 000000010003AF56 _fermi_tetra_ 516
>>>>>>>>> fermi_tmp_.F
>>>>>>>>> lapw2c 000000010003A476 _fermi_ 111
>>>>>>>>> fermi_tmp_.F
>>>>>>>>> lapw2c 000000010006E463 _MAIN__ 278
>>>>>>>>> lapw2_tmp_.F
>>>>>>>>> lapw2c 000000010000108C Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>> lapw2c 0000000100001024 Unknown Unknown
>>>>>>>>> Unknown
>>>>>>>>>
>>>>>>>>> > stop error
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The problem is that the "x lapwso up orb" does not generate
>>>>>>>>> eigenvalues properly.
>>>>>>>>>
>>>>>>>>> However, if I specify the scratch as something below (or with the
>>>>>>>>> absolute path being not greater than 22 characters in length)
>>>>>>>>>
>>>>>>>>> [] jxzhu% echo $SCRATCH
>>>>>>>>> /Users/jxzhu/scratch
>>>>>>>>>
>>>>>>>>> By running wien2k with the above mentioned mode, no error appears
>>>>>>>>>
>>>>>>>>> [] jxzhu% runsp_lapw -so -orb -cc 0.001 -NI -i 1
>>>>>>>>> LAPW0 END
>>>>>>>>> ORB END
>>>>>>>>> ORB END
>>>>>>>>> LAPW1 END
>>>>>>>>> LAPW1 END
>>>>>>>>> LAPWSO END
>>>>>>>>> LAPW2 END
>>>>>>>>> LAPW2 END
>>>>>>>>> LAPWDM END
>>>>>>>>> CORE END
>>>>>>>>> CORE END
>>>>>>>>> MIXER END
>>>>>>>>>
>>>>>>>>> > charge in SCF NOT CONVERGED
>>>>>>>>>
>>>>>>>>> If I look into the file nfcc.energysoup, I see the command "x
>>>>>>>>> lapwso
>>>>>>>>> up orb" does generate eigenvalues properly.
>>>>>>>>>
>>>>>>>>> This kind of issues only happen on Mac OSX machines (I am using
>>>>>>>>> 10.6.8,
>>>>>>>>> and the wien2k is compiled with Intel 11.1/089) but not on linux
>>>>>>>>> machines.
>>>>>>>>> In addition, on the same Mac OSX machine, the running modes like
>>>>>>>>> "runsp_lapw so" and "runsp_lapw orb" simply work fine.
>>>>>>>>>
>>>>>>>>> I very much appreciate if you can help reproduce this on your Mac
>>>>>>>>> OSX
>>>>>>>>> machines and share your experience on how to fix it (if it is
>>>>>>>>> true).
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>>
>>>>>>>>> Jianxin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Wien mailing list
>>>>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -----------------------------------------
>>>>>>>> Peter Blaha
>>>>>>>> Inst. Materials Chemistry, TU Vienna
>>>>>>>> Getreidemarkt 9, A-1060 Vienna, Austria
>>>>>>>> Tel: +43-1-5880115671
>>>>>>>> Fax: +43-1-5880115698
>>>>>>>> email: pblaha at theochem.tuwien.ac.at
>>>>>>>> -----------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> P.Blaha
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> --
>>>>>> --
>>>>>> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
>>>>>> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
>>>>>> Email: blaha at theochem.tuwien.ac.at WWW:
>>>>>> http://info.tuwien.ac.at/theochem/
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> --
>>>>>> --
>>>>>> _______________________________________________
>>>>>> Wien mailing list
>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>
>>>>> _______________________________________________
>>>>> Wien mailing list
>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>
>>>>
>>>> --
>>>> -----------------------------------------
>>>> Peter Blaha
>>>> Inst. Materials Chemistry, TU Vienna
>>>> Getreidemarkt 9, A-1060 Vienna, Austria
>>>> Tel: +43-1-5880115671
>>>> Fax: +43-1-5880115698
>>>> email: pblaha at theochem.tuwien.ac.at
>>>> -----------------------------------------
>>>> _______________________________________________
>>>> Wien mailing list
>>>> Wien at zeus.theochem.tuwien.ac.at
>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>
>>>
>>
>> --
>> 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
>
--
P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.at WWW:
http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------
More information about the Wien
mailing list