Re: [sdpd] Recent Congress and comiing ones about SDPD

[Robin Shirley <R.Shirley...@surrey.ac.uk>]

> If you were going to exploit anisotropic peak broadening for indexing
> also (in principle it could help) then the things you might want to
> list in an input file would be the position, intensity and width of a
> peak. Most peak fitting programs already write this out.

No disagreement so far.

> Then for the anisotropic thermal expansion, texture, cation
> substitutions etc which might also be used - you'd want to read in a
> series of datafiles and something telling you what they are (differing
> in intensities, or positions, or widths, or some combination of the
> three).

Exactly.  Deciding how to specify and manage those multiple datasets is
the issue here.

> In practice it's more normal for standardisation to reflect standard
> practices, rather than to standardise before the methods are
> implemented (how many compliant C++ compilers are available now?).

However, in this case standard practices don't seem to exist either.

> Seems like anyone who has the resources to write a program using this
> kind of information will get to define the standard format for the
> future, and we should be grateful to them for doing it.

Yes, indeed.  But those who might write the program may well not possess
suitable data - I certainly don't.  So this would call for collaboration
between those with specialist software experience and those with access
to relevant datasets.  If someone on the sdpd list with suitable
multi-environments test datasets were to make these available, that
might provide a starting point.

> Interconverting file formats remains much easier than indexing!

Agreed!

Robin

--------------------------

To:            sdpd...@yahoogroups.com
From:          Jon Wright <wright...@esrf.fr>
Date:          Mon, 29 Sep 2003 09:46:24 +0200
Subject:       Re: [sdpd] Recent Congress and comiing ones about SDPD
Reply-to:      sdpd...@yahoogroups.com

Robin Shirley wrote:

>Thus, while people don't collect multi-environment/multi-texture
>datasets routinely and store them in some standard format (i.e. more
>predictable than an idiosyncratic portmanteau CIF file), there won't be
>sufficient of a constituency for indexing software authors to write for.

If you were going to exploit anisotropic peak broadening for indexing 
also (in principle it could help) then the things you might want to list 
in an input file would be the position, intensity and width of a peak. 
Most peak fitting programs already write this out. Then for the 
anisotropic thermal expansion, texture, cation substitutions etc which 
might also be used - you'd want to read in a series of datafiles and 
something telling you what they are (differing in intensities, or 
positions, or widths, or some combination of the three). In practice 
it's more normal for standardisation to reflect standard practices, 
rather than to standardise before the methods are implemented (how many 
compliant C++ compilers are available now?). Seems like anyone who has 
the resources to write a program using this kind of information will get 
to define the standard format for the future, and we should be grateful 
to them for doing it. Interconverting file formats remains much easier 
the indexing!

Cheers,

Jon

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/UIYolB/TM
---------------------------------------------------------------------~->

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/