[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