[Wien] Some interesting observation with "runsp_lapw -so -orb"on Mac OSX
Zhu, Jianxin
jxzhu at lanl.gov
Tue Dec 18 16:43:51 CET 2012
-----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...
Indeed I wanted to simply calculate the FM state with spin-orbit coupling
and "LDA+U", that is,
"runsp_lapw -so -orb". Attached please find the initial structure file for
intended for the running mode "run_lapw" or "run_lapw -so" (for PM state
without or with spin-orbit coupling and of course no LDA+U). In this
structure file, I have only one atom (fcc Np for example).
I then proceeded to run "initso_lapw" and chose to run "symmetso" (for FM
state) and took the newly generated structure file. It still has only one
atom but now with number of symmetry operation reduced from 48 and 16. I
then re-ran "init_lapw" and "initso_lapw" for the FM state, during which I
saw the following in the fcc-"Np.outsymso" file:
fcc Np s-o calc. M|| 0.00 0.00 1.00
ATOMIC POSITIONS:
1 0.00000000 0.00000000 0.00000000
PGLSYM: THE CRYSTAL SYSTEM IS CUBIC
PGLSYM: ORDER OF LATTICE POINT GROUP (NO BASE) = 48
PGBSYM: ORDER OF LATTICE SPACE GROUP (WITH BASE) = 48
PGBSYM: SPACE GROUP IS SYMMORPHIC
PGBSYM: SPACE GROUP CONTAINS INVERSION
WARNING !!!!!!
nsym found by symmetry differs from iord read in struct 48 16
Symmetry operation 1
1.00000 0.00000 0.00000
0.00000 -1.00000 0.00000
0.00000 0.00000 -1.00000
0.00000 0.00000 0.00000
1.0000 0.0000 0.0000 0.0000
0.0000 -1.0000 0.0000 0.0000
0.0000 0.0000 -1.0000 0.0000
this is operation 10 in struct file
Symmetry operation 2
1.00000 0.00000 0.00000
0.00000 0.00000 -1.00000
0.00000 -1.00000 0.00000
0.00000 0.00000 0.00000
1.0000 0.0000 0.0000 0.0000
0.0000 0.0000 -1.0000 0.0000
0.0000 -1.0000 0.0000 0.0000
WARNING !!!!!
this symmetry operation was not found in struct!!
...
This file has occurrences of "WARNING". But I ignored, and a few steps
during "initso_lapw" are attached here
...
In spinpolarized case SO may reduce symmetry.
The program symmetso dedects the proper symmetry and creates new struct and
input files. (Note, equivalent atoms could become inequivalent in some
cases).
Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y
0.017u 0.021s 0:00.16 18.7% 0+0k 0+13io 0pf+0w
A new structure for SO calculations has been created (_so).
If you commit it will create new fcc-Np.struct, in1(c), in2c, inc,
clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous
calculations)
NOTE: Files for -orb (fcc-Np.indm(c),inorb,dmatup/dn) must be adapted
manually
Do you want to use the new structure for SO calculations ? (y/N)
Spinorbit is now ready to run.
% runsp_lapw -so -orb -cc 0.001 -NI -i 2 -p
LAPW0 END
LAPW1 END
LAPW1 END
LAPWSO END
LAPW2 - FERMI; weighs written
LAPW2 END
LAPW2 - FERMI; weighs written
LAPW2 END
LAPWDM END
CORE END
MIXER END
in cycle 2 ETEST: 0 CTEST: 0
LAPW0 END
ORB END
LAPW1 END
LAPW1 END
LAPWSO END
forrtl: severe (59): list-directed I/O syntax error, unit 30, file
/Volumes/Macintosh_HD2/lapw_dta/fcc-Np/fcc-Np.energysoup_1
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
cp: .in.tmp: No such file or directory
> stop error
However, if I run the exactly same thing on the linux cluster, it just
runs fine and no such error appears.
I agree with you that there must be some problem with $SCRATCH.
For your convenience (if you want to test it on whatever machine you
have), I also attach the "inorb" and "indmc" files.
Now I am changing the
>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
I will let you know.
Best regards,
Jianxin
>
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcc-Np.indmc
Type: application/octet-stream
Size: 212 bytes
Desc: fcc-Np.indmc
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121218/840e1269/attachment.dll>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcc-Np.inorb
Type: application/octet-stream
Size: 286 bytes
Desc: fcc-Np.inorb
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121218/840e1269/attachment-0001.dll>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcc-Np.struct
Type: application/octet-stream
Size: 1796 bytes
Desc: fcc-Np.struct
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121218/840e1269/attachment-0002.dll>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcc-Np.struct_PM
Type: application/octet-stream
Size: 3703 bytes
Desc: fcc-Np.struct_PM
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121218/840e1269/attachment-0003.dll>
More information about the Wien
mailing list