Re: fractional occupancy and composition within GSAS

2009-12-02 Thread Brian Toby
The short answer here is read the code that does this, which I have not done 
anytime recently. 

What I recall is the unit cell composition is simply the sum of site 
multiplicities times the fractional occupancy for each site grouped by atom 
type. 

The way I come up with z is something of a kludge -- I think I look for the 
largest integer divisor for all the non fractionally occupied sites. If anyone 
has a better suggestion on how to do this, I'd like to hear it.

Brian
Sent via BlackBerry from T-Mobile

-Original Message-
From: Irvin Telepeni irvin.telep...@nottingham.ac.uk
Date: Wed, 02 Dec 2009 17:07:02 
To: rietveld_l@ill.fr
Subject: fractional occupancy and composition within GSAS

Hi, 

 

I'd like to know how GSAS (EXPGUI) calculates the atomic composition
(through the RESULTS menu) of one phase with respect to the atomic
fractional occupancy? How can I get to the same composition values from
my fractional occupancies? 

 

Cheers,

 

Irvin 

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


Re:

2005-07-02 Thread Brian Toby
Dear Milinda, 

I have added you to my mailing list for information about EXPGUI (the GSAS user interface). When I have time, I make updates and send out mail to that list. If you have questions, you likely want to join the Rietveld mail server, where people have discussions on the technique and software. That list is at rietveld_l@ill.fr and you can find instructions on how to subscribe at 
http://ccp14.sims.nrc.ca/ccp/ccp14/ftp-mirror/howardflack/pub/soft/crystal/stxnews/riet/using.htm

(the ccp14 site also has many good tutorials, plus there are a few on my site, see link below)

There is also an archive of the Rietveld list:
x-tad-biggerhttp://www.mail-archive.com/rietveld_l@ill.fr/ 

Brian/x-tad-bigger

Brian H. Toby, Ph.D.Leader, Crystallography Team
[EMAIL PROTECTED]  NIST Center for Neutron Research, Stop 8563
voice: 301-975-4297 National Institute of Standards  Technology
FAX: 301-921-9847Gaithersburg, MD 20899-8563
http://www.ncnr.nist.gov/xtal


On Jul 1, 2005, at 1:32 PM, milinda a wrote:

Hello Brian,

I am a graduate student at University of Houston. I
use GSAS to model Nanoclusters embedded in zeolite. I
have some questions regarding my refinments. Please
add me to the GSAS mailing list. Thank you.

Regards!

Milinda






__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 


Re: DBWS vs other refinement programs

2005-07-01 Thread Brian Toby
http://danse.cacr.caltech.edu/polls/results.php?sid=22 

Of course, the number of people using Rietveld software is more than 269 (number of answers in the survey) 

The number of respondents to the survey is ~150, but Rietveld users (at least the ones who took the time to participate) on average use more than one package, which is why there are >>150 answers.

Brian

Re: mismatch between ICSD cif file and GSAS

2005-05-17 Thread Brian Toby
On May 17, 2005, at 12:31 AM, Donald Wang wrote:
x-tad-biggerAfter 1/8 offset, it appears that the pattern from live plot is a good match to ICSD-generated pattern, which basically solved my problem.  I am very happy and grateful./x-tad-bigger
x-tad-bigger /x-tad-bigger
x-tad-biggerThere is still a little problem.  The multiplicity column did not change at all (in EXPGUI).  Please explain./x-tad-bigger

Yes -- this one is a known EXPGUI bug. EXPGUI does not compute the multiplicity values directly, but rather it reads them from the .EXP file. GENLES will update them, but only if the atom [coordinate?] is varied. When you move an atom in EXPGUI from one site to another by editing coordinates the multiplicity does not get updated, but as you found the diffraction intensity calculation comes out right.

The right way to address this problem would be to have EXPGUI invoke the section of EXPEDT that computes multiplicities, but that is not going to happen any time soon. One thing that I could do fairly easily would be to set the multiplicity to zero when an atom position is edited. Anyone want to speak in favor or against this idea?

Brian

Re: Laboratory Information Management Systems (LIMS)

2005-04-25 Thread Brian Toby
At 14:43 22/04/2005, Angus P. Wilkinson 
[EMAIL PROTECTED]  wrote:
Do none of the user facilities have a data management system in place 
for their instruments?
Well yes Angus :-) For the past 30+ years ILL has stored all 
instrument data as simple ASCII files with a data format described in 
the first few lines of the file.
I presume we all archive data files -- but a data management system 
records far more about the data and sample (metadata as the informatics 
folks like to say) than what shows up in the run header. We can locate 
all the data that were collected at 1500 K, but how about finding 
studies on all the samples that were quenched from 1500 K prior to 
measurement?

Brian


Re: Change format

2005-03-30 Thread Brian Toby
your data are free format with intensities as a real variable. Using
excel or any equivalent you can convert in integer intensities (e.g.
multiplying by ten to avoid errors with low values) which is the usual
data input (counts).
Step 2 is then to convert the free 2th-I (real-integer) file into GSAS
format (no 2th, 10 int per line) using any of the conversion programs.
If the numbers are real values then they are not counts. They may be 
counts per second or something else. One needs to have uncertainty 
estimates for these intensities before one can do a meaningful Rietveld 
refinement (with any code). Following the above procedure, by 
multiplying them by an arbitrary constant and then inputting them to 
GSAS as if they were counts will cause GSAS to compute the 
uncertainties as the square-root of the intensities, something that is 
quite unlikely to be true. This will cause the refinement to be 
weighted improperly and the r-factors to be wrong.

I can sympathize with the temptation to skip the details (like 
understanding exactly what your data represent) to get on with the 
science, but the eventual result is a study that is not suitable for 
publication.

Brian


Re: RIET:CLAY: IUCr 2005: Crystallographic Software Fayre at IUCr Florence, Italy 2005 Congress

2005-03-14 Thread Brian Toby
I should think about doing something -- what makes most sense CMPR, 
EXPGUI, GSAS2CIF  or pdCIFplot? I tend to think CIF is the most 
important with the Acta's now asking for powder CIFs. What to you think?

BTW, at least for me, invited talks matter and other talks don't. As 
part of my goal of self promotion, err, as improving recognition for 
software generators, I suggest that people be invited to make 
presentations in future Congresses.

Brian
On Sunday, March 13, 2005, at 02:19  AM, L. Cranswick wrote:
Crystallographic Software Fayre at IUCr Florence, Italy 2005 Congress
 (Wednesday 24th August until Tuesday 30th August 2005)
  http://www.ccp14.ac.uk/projects/iucr2005-softwarefayre/
Thanks to PC hardware arranged by the conference organisers, there will
be a non-Commercial Crystallographic Software Fayre at the IUCr 
Florence
2005 Congress (http://www.iucr2005.it/) from Wednesday 24th August 
until
Tuesday 30th August 2005. This is being organised by Richard Stephenson
(CCP14, University College London) and Lachlan Cranswick (NRC Canada,
Chalk River Laboratories).

The Software Fayre was the following for general usage:
   8 PCs running Windows and Linux connected by a local area 
network

A computer projector system and microphone system will also be 
available
for formal software demonstrations (E-mail Richard Stephenson at
[EMAIL PROTECTED] if you would like to book some time
slots).

Besides making informal use of the computers in between booked time
slots, non-commercial software authors and interested users are invited
to to book time slots to allow the presentation of formal software
demonstrations. Bookings of time slots are done through Richard
Stephenson (E-mail: [EMAIL PROTECTED]).
Current bookings are viewable at:
  http://www.ccp14.ac.uk/projects/iucr2005-softwarefayre/software.htm
More detailed information is available at the 2005 Crystallographic
Software Fayre homepage at:
  http://www.ccp14.ac.uk/projects/iucr2005-softwarefayre/
Please Email [EMAIL PROTECTED] if you have any queries,
or bookings you would like to make.
Richard and Lachlan.
--
---
Lachlan M. D. Cranswick
Contact outside working hours /
  Coordonnees en dehors des heures de travail:
E-mail / courriel: [EMAIL PROTECTED]   Home Tel: (613) 584-4226
Mobile/Cell: 613 401 3433   WWW: http://lachlan.bluehaze.com.au/
P.O. Box 2057, Deep River, Ontario, Canada, K0J 1P0
(please use clear titles in any Email - otherwise messages might
accidentally get put in the SPAM list due to large amount of junk
Email being received. If you don't get an expected reply to any
messages, please try again.)
(Essayez d'utiliser des titres explicites - sans quoi vos messages
pourraient aboutir dans un dossier de rebuts, du fait de la quantite
tres importante de pourriels recue. Si vous n'obtenez pas la reponse
attendue, merci de bien vouloir renvoyer un message.)




Re: Rigid body constraints on perovskite structured materials

2004-11-12 Thread Brian Toby
I will wade in on this topic quickly.
Rigid body constraints can be used for two linked bodies pretty easily 
-- what one does is define the origin of each body as an atom that  
shared between each body (note that this atom needs to be present in 
the atom list twice, so adjust occupancies to total accordingly.) Then 
one can constrain the origin for each body to be the same and but still 
give each body independent orientations. This trick could be used for 
more complex situations where more than two bodies share a single atom, 
but off-hand, I don't see this helping in the case of a perovskite.

One other idea that could help is the following: you could define your 
perovskite blocks individually without any regard to linkages, but then 
use soft-constraints (really strong ones!) to keep the linking atoms 
tied together. Again, you will need to define the linking atoms 
multiple times (so some many need to be dummy atoms or split 
occupancies), but this should work for any arbitrarily complex 
arrangement of bodies.

Brian
On Friday, November 12, 2004, at 10:50  AM, Sang-Heon Shim wrote:
I wonder if the rigid-body constraints of GSAS can be used for the
polyhedra which are linked each other, such as octahedra in perovskite
structured materials.  Or is the application of the rigid-body
constraints strictly restricted to isolated polyhedra in crystal
structures?



Re: Instument parameter file

2004-03-18 Thread Brian Toby
 Theoretically U,V,W should not be refined at all as they describe instrumental 
 broadening

This is true only when there is no Gaussian strain present. 

Brian


Re: Sequential refinement with GSAS

2001-08-31 Thread Brian Toby

 I need to make Rietveld analysis with big amount of data files and I would
 like to ask you if you know is it possible to make GSAS refinement for many
 files at the same time or is there some procedure to do analysis
 automatically for some consequence of files.

I agree that this is a valuable task, but I seem to have enough to do
already. I will suggest, though, that a fair amount of the groundwork in
reading  writing GSAS files, as well as running GSAS programs can be
performed using code in EXPGUI. I am happy to help, if someone else
wants to take this task on. 

As an example, below is a short tcl script that creates a new .EXP file
based on a template, changing the data file, the title, a,b  c and then
runs
POWPREF  GENLES. I wrote it quickly, so the script would need some
neatening up so that it could be run on Windows  Unix.

# basic definitions needed by EXPGUI routines
set expgui(gsasdir) /home/gsas
set expgui(gsasexe) /home/gsas/exe
set env(GSASBACKSPACE) 1
set expgui(autoiconify) 0
set expgui(debug) 0
# source files
source ${expgui(gsasdir)}/expgui/readexp.tcl
source ${expgui(gsasdir)}/expgui/gsascmds.tcl
# load exp file
cd /home/toby/test/
expload GARNET.EXP
mapexp
# make changes
expinfo title set GARNET 300K
histinfo 1 file set GARNET300.RAW
phaseinfo 1 a set [expr 1.0001 * [phaseinfo 1 a]]
phaseinfo 1 b set [expr 1.0001 * [phaseinfo 1 b]]
phaseinfo 1 c set [expr 1.0001 * [phaseinfo 1 c]]
# save  run 
expwrite GARNET300.EXP
forknewterm POWPREF $expgui(gsasexe)/powpref GARNET300 
forknewterm GENLES  $expgui(gsasexe)/genles  GARNET300

Anyone who has read this far without losing their last meal is welcome
to contact me.

Brian