Bruce: I have recently encountered a weird problem with TkAtoms. Let me detail it setp by step. 1. Start TkAtoms and build a model from scratch. 2. Press the "Run Atoms" button. The output of this is correct and can be saved to disk. 3. Save the "atoms.inp" file associated with the model that has been successfully run and exit TkAtoms. 4. Start TkAtoms again and load the previous "atoms.inp" file. 5. Press the "Run Atoms" button again. This time the output (the FEFF input file) is completely different than in step 2. It is also completely incorrect. Many of the x,y,z coordinates are set to zero. In fact the x coordinate is always zero. If I clear the data boxes and re-enter the original numbers, the results are correct once again. This is extremely confusing to me. I have only tried it with a single structure but it shows this behavior consistently. I have attached the offending atoms.inp file. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Research, Armour College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre@iit.edu http://www.iit.edu/~segre
Hi all, I encountered a problem similar to the one Carlo describes in his mail. I believe there is a bug in how TkAtoms reads 90 deg. angles from input files and (maybe) treats trigonal systems in hexagonal notation. Carlo: After reading in the input file, complete the lattice parametes by hand, i.e. enter the angles (90 deg) into the blank fields for alpha and beta. Then the calculation should work. If you don't enter the angles manually TkAtoms will obscure your structure. Watch the lattice parameters *after* running atoms! The value for the c axis will have changed so that a=b=c and you will get alpha=beta=gamma=120 deg. The other day I complained to Bruce about the calculation of the unit edge length (in the absorption card), printing out way to large sample thicknesses for an edge step of 1. In the meantime I noticed that the values for absorption length and unit edge length depend on whether I use the trigonal or the rhomohedral representation for my unit cell. Bruce: The values for the trigonal unit cell seem okay, maybe the problem is the treatment of the rhombohedral structure (not the specific wheight as I originally speculated). I have attached the two input files. Hope I could help! Best, Peter -- -------------------------------------------------------------- Peter Pfalzer Universitaet Augsburg Tel: +49-821-598-3215 Lehrstuhl fuer Experimentalphysik II Fax: +49-821-598-3411 Universitaetsstr. 1 D-86135 Augsburg Germany Peter.Pfalzer@physik.uni-augsburg.de -------------------------------------------------------------- ! This atoms input file was generated by TkAtoms 3.0beta7 ! Atoms written by and copyright (c) Bruce Ravel, 1998-2001 title = name: vanadium sesquioxide title = formula: V2O3 title = sites: V1,O1 title = refer1: Wyckoff vol 2, V, p 6-8 space = R -3 c a = 5.6470 b = 5.6470 c = 5.6470 alpha = 53.750 beta = 53.750 gamma = 53.750 core = V1 edge = K rmax = 6.0 shift 0.0000 0.0000 0.0000 atoms ! elem x y z tag occ. V 0.3463 0.3463 0.3463 V1 1.0000 O 0.5650 -0.0650 0.2500 O1 1.0000 ! This atoms input file was generated by TkAtoms 3.0beta7 ! Atoms written by and copyright (c) Bruce Ravel, 1998-2001 title = name: vanadium sesquioxide title = formula: V2O3 title = sites: V1,O1 title = refer1: Wyckoff vol 2, V, p 6-8 space = R -3 c a = 5.1050 b = 5.1050 c = 14.4490 alpha = 90.0 beta = 90.0 gamma = 120.0 core = V1 edge = K rmax = 6.0 shift 0.0000 0.0000 0.0000 atoms ! elem x y z tag occ. V 0.0000 0.0000 0.3463 V1 1.0000 O 0.3150 0.0000 0.2500 O1 1.0000
Hi folks, The problem Peter and Carlo wrote about seems to be a genuine bug in Atoms. As I understand it, the problem happens when you try to save the atoms.inp file. Apparently, something wrong is done whith the angles when trying to save. Hopefully Peter suggestion of being mindful of the angle values will help. Anyway, I am off to the synchrotron next week, so I probably won't be able to post a solution until the following week. On another topic: folks who are running unix, linux, or OSX and are updating from ifeffit 1.2.0 to 1.2.1 to benefit by the bugfix regarding the use of multiple k weights will need to rebuild my codes after doing so. Specifically, the perl wrapper needs to be rebuilt using the updating ifeffit library. If you do not rebuild my codes, then Artemis will continue to use the wrapper built with the older library. If you are using my horae-update script, you will need to use the brand-new --force command line argument to coerce the script to rebuild the codes even though the version number has not changed. Regards, B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
participants (3)
-
Bruce Ravel -
Carlo U. Segre -
Peter Pfalzer