Menu
▾
▴
difdaf-devel — Discussion list for developers and users.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(31) |
Mar
|
Apr
(8) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marcin W. <wo...@if...> - 2007-07-25 05:31:10
|
Hi, it's already 3 years since the last post to this mailing list :-) This year fityk is participating in Google Summer of Code program, and one of students is working on a library, that will read various x-y file formats. It will be a bit different that we were discussing 3 years ago. Any x-y data can be supported (not only powder diffraction, but also e.g. XPS). The library reads x-y values, and has only minimal support for extracting additional informations (i.e. it should be possible to get wavelength from file, but the way how wavelength can be obtained can be different for each format). Below is a message I sent today to a few people: This summer one of students in Google Summer of Code program, Peng Zhang, is writing a library for reading x-y data (and a converting tool: all formats to ascii CSV/TSV). I'm a mentor for this project. The aim is to make a library for reading various file formats that contain data plottable in 2D (more or less equivalent of two column ascii file), and are not too complicated (no Excel or Origin files). We are focused on experimental data - all formats produced by diffractometers, spectrometers, MCAs, etc. At this moment, we have some powder diffraction formats (Bruker .raw v1-3 and a few text formats) and ISO VAMAS (XPS data). If you have documentation of any other formats, you can send it to us (wo...@gm..., zha...@gm...). We are willing to include even exotic ones, e.g. formats from a specific synchrotron station. Just send us one or more sample files and explanation of the format (e.g. scan of paper documentation). In a year or two, this library and converting program should be included in most of Linux distributions, because it will be used by at least one package (fityk), that is already there (in Debian, Ubuntu, Fedora, Mandriva and a few other distros, and in FreeBSD). You may forward this email... Marcin -- Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ |
|
From: <ben...@id...> - 2004-05-25 11:40:39
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Marcin W. <wo...@if...> - 2004-04-15 16:44:05
|
On Thu, 15 Apr 2004, Stefan Krumm wrote: > > So I scanned it and put on www. > > Hmm, I would be cautious about doing that without WRITTEN permission from > Bruker. Not to run into copyright issues... Right. So I removed it. Marcin -- Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ |
|
From: Stefan K. <kr...@ge...> - 2004-04-15 14:41:14
|
Am Donnerstag, 15. April 2004 13:26 schrieb Marcin Wojdyr: > So I scanned it and put on www. Hmm, I would be cautious about doing that without WRITTEN permission from=20 Bruker. Not to run into copyright issues... Such things can quickly turn expensive. Too many laywers earning too few=20 money. ;-) I am working on the bruker things anyway. Didn't put anything in CVS yet, b= ut=20 soon. Stefan =2D-=20 Dr. Stefan Krumm FON: +49 (0)9131 85 26063 Institut f=FCr Geologie und MIneralogie FAX: +49 (0)9131 85 29295 Universitaet Erlangen-Nuernberg Schlossgarten 5 91054 Erlangen Germany http://www.geol.uni-erlangen.de |
|
From: Marcin W. <wo...@if...> - 2004-04-15 11:25:33
|
Hi, I was looking for descriptions of file formats and found only two in my lab: Bruker .RAW (v1 and v2) and Canberra MCA. So I scanned it and put on www. Do you have descriptions of other formats? Or is it available somewhere on www? I added link to it and SF icon (it is required by SF) to difdaf web page. Now I have to suspend work on difdaf for 1-2 weeks. Then I'd like to add Canberra .mca and .rit (8-columns) formats. Marcin -- Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ |
|
From: Favre-Nicolin V. <vi...@us...> - 2004-04-14 20:18:10
|
> I just added to CVS unfinished support for cpi.cpp and simple testing > program, also unfinished, (convert.cpi). > I haven't made changes I wrote in previous mail yet, first I'll try to > learn more about CIFs. Will try that. Right now am in the middle of an ESRF experiment, so real= ly=20 too busy. Will be better in may, after abstract deadline. > On Wed, 7 Apr 2004, Stefan Krumm wrote: > > P.S. thanks for the advice, Vincent! I didn't notice your mail yesterday > > and will try it this afternoon. And I aggree, we should stay as standrad > > compliant as possible. Not too much work to type string(...). > > Was it in private email? Yes. Cheers, Vincent =2D-=20 Vincent Favre-Nicolin Universit=E9 Joseph Fourier http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Marcin W. <wo...@if...> - 2004-04-14 15:44:43
|
Hi, I just added to CVS unfinished support for cpi.cpp and simple testing program, also unfinished, (convert.cpi). I haven't made changes I wrote in previous mail yet, first I'll try to learn more about CIFs. On Wed, 7 Apr 2004, Stefan Krumm wrote: > P.S. thanks for the advice, Vincent! I didn't notice your mail yesterday and > will try it this afternoon. And I aggree, we should stay as standrad > compliant as possible. Not too much work to type string(...). Was it in private email? Marcin -- Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ |
|
From: Marcin W. <wo...@if...> - 2004-04-08 11:49:55
|
Hi,
I started implementing .cpi file format.
In this and many other formats only intensities are listed (and start
positon and step). I can compute position and guess standard deviation,
but sometimes the positions and sigmas are not needed (e.g. when
converting to other constant-step format).
So i think class DiffractogramPoint is not neccessary. We can have
vector<float> position, intensity, sigma, time;
in class Diffractogram and some method for accessing it, eg:
bool AppendPoint(float intensity)
bool AppendPoint(float position, float intensity)
bool AppendPoint(float position, float intensity, float sigma)
bool AppendPoint(float position, float intensity, float sigma, float time)
Only one of above functions would be used for one Diffractogram.
int GetPointCount()
bool HasListedPositions()
bool HasListedSigmas()
bool HasListedTimes()
float GetPointIntensity(int n)
void GetPoint(int n, float *position, float *intensity, float *sigma, float *time)
function above could compute missing value for position and sigma.
Perhaps also functions like GeneratePositionList().
and functions for accessing directly vectors
const vector<float>& GetAllIntensities() const { return intensities; }
etc.
What do you think about it?
Marcin
--
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/
|
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-04-07 20:29:09
|
> what's your opinion about command line parsing. > Should we use one of the existing libraries (which one?) or should we write > our own routine(s)? Parsing arguments for the command-line should not be too hard, so I do not know if using a library is really necessary ? unless you have complex commands in mind. Command-line parsing for Fox (see near line 207+ http://cvs.sourceforge.net/viewcvs.py/objcryst/Fox/src/Fox.cpp?annotate=1.31) seemed quite easy. > P.S. thanks for the advice, Vincent! I didn't notice your mail yesterday > and will try it this afternoon. And I aggree, we should stay as standrad > compliant as possible. Not too much work to type string(...). I hope it works... I did not not have the time to try it - a bit busy with an experiment beginning at the ESRF. vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Stefan K. <aa...@ge...> - 2004-04-07 09:03:50
|
Dear friends, what's your opinion about command line parsing. Should we use one of the existing libraries (which one?) or should we write= =20 our own routine(s)? Best regards, Stefan P.S. thanks for the advice, Vincent! I didn't notice your mail yesterday an= d=20 will try it this afternoon. And I aggree, we should stay as standrad=20 compliant as possible. Not too much work to type string(...). :-) =2D-=20 Dr. Stefan Krumm Institut f=FCr Geologie Schlossgarten 5 D-91054 Erlangen +49 9131 852 6063 http://www.geol.uni-erlangen.de |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-15 23:40:39
|
Hi, > for the time beeing, I would prefer simplicity over elegance. As Vincent > said, checking of the program during development will be done after simple > compilation without installing something somewhere. > If we have all important formats declared in a single place in main, it > will be possible to swtich over to complerte dynamical declaration when > things have settled a bit. OK, I changed code a bit in the CVS. Right now the registration requires (a) the declaration of a DifDafFormat object (see the ncolumns.cpp file) (I got rid of the extra FormatRegistration class, one class is sufficient), (b) the _use_ of this object in the code, currently at the top of the main.cpp file. It works but there's a big catch. For this global registration thing, we are having global variables (the formats) stored into another global variable (the list). The problem is, there is no garantee on the initialization order of these variables. So if the list is not initialized before the variables, we get a crash. I moved the static list of formats in the DifDafFormat class, because (a) it makes more sense there and (b) I hoped that the static variables of class DifDafFormat would be initialized before any object of that class, but it does not work. So the current code works (just compile and run difdaf), but if in the makefile you exchange the difdaf.o and ncolumns.o files order, it crashes because the linking and initialization order changes. There does not seem to be a clean way out of this by using dynamical registration through global variables. It will work for now with gcc, but is probably not portable. So we'll have to think later about how to do it. I guess right now the important thing is to add other formats and see if it's working OK. Cheers, -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Stefan K. <kr...@ge...> - 2004-02-15 10:12:57
|
Am Samstag, 14. Februar 2004 14:56 schrieb Favre-Nicolin Vincent: > =A0 =A0Any thoughts ? Hi, for the time beeing, I would prefer simplicity over elegance. As Vincent sa= id,=20 checking of the program during development will be done after simple=20 compilation without installing something somewhere. If we have all important formats declared in a single place in main, it wil= l=20 be possible to swtich over to complerte dynamical declaration when things=20 have settled a bit. chees, Stefan =2D-=20 Dr. Stefan Krumm FON: +49 (0)9131 85 26063 Institut f=FCr Geologie und MIneralogie FAX: +49 (0)9131 85 29295 Universitaet Erlangen-Nuernberg Schlossgarten 5 91054 Erlangen Germany http://www.geol.uni-erlangen.de |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-14 14:00:27
|
Hi, Run into a little problem. Classical but had forgotten that... The issue is, for the declaration of import/export functions we use global variables that exist only in the file where the functions are coded. The problem is, these variables are _never_ accessed and therefore referenced. Of course the linker sees this, and strips them when producing the executable. The consequence is that the functions never get registered. It works in the CVS version (you can see the registration message when running difdaf), but when separating between several files it does not work any more. It is a well-known issue, for which the standard solution (A) is to link everything in a _shared_ library rather than use a static linkage. This is a bit annoying as to get things working, the library must of course be moved to somewhere in the library path, while developpers often work without 'installing' the compiled object before testing. The other solution (B) is, of course, to reference all FormatRegistartion objects in the main program and fake doing something so that it is not stripped out. It kills a bit the dynamical nature of the of the registration. Now that I think about it, it is probably possible to have a number of formats referenced in the main, _and_ other formats dynamically declared (as long as they are in *.so libs). Any thoughts ? Vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-12 15:05:25
|
OK, I commited the last discussed changes, and also added a small main program which does nothing, so that we can see the registration messages. Looks like it's working. I guess now we can add other formats, and test ho the import/export actually works. Vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-12 13:05:00
|
Hi, > > b) I am now a bit doubting about the CifDataName approach. The constraint > > of using CIF data name may be a bit annoying (how to store a generic > > comment ? The filename from which the data was imported ?). So although > > it looks nice, it may actually be pointless. maybe we shoud just write > > our own enumeration of tags that are useful ? And also add an array of > > description for each tag ? What do you think ? > > I don't know (CIF or not). I think we can extend CifDataName if we need, > adding new entries with our prefix. Ok. > BTW, there is no need to prepend '_' in _pd..., > eg. if we have in .dic's: > data_atom_site_U_equiv_geom_mean > data_pd_meas_rocking_axis > we just cut 'data_' in both. Or perhaps we should leave it or replace > with another prefix? Actually in the cif there is a '_' at the beginning (e.g. http://journals.iucr.org/c/issues/2004/02/00/iz1037/iz1037Isup2.rtv). However I did forget it at the beginning of the 'core' cid dictionnary names. So let's remove it everywhere, it's not useful. > The array of descriptions would be useful, eg. for dumping all > informations from file in human-readable format. For CIF we can > generate it from .dic files. OK, Will have to add a global map<CifDataName,string>. > From next mail: > > This would have the double advantage that we could use it in the > > command-line interface of the difdaf program (e.g. name=bruker, command = > > difdaf -o bruker ...). Was that what you had in mind ? > > Yes, I was thinking about it. But as Stefan and you wrote in next posts, > file extensions and full name / description would also be useful. Ok, let's do that. > And it should be possible to verify file format. Do you think > that separate function should be used, or import function can return > a value / throw exception? it's probably easier to throw an exception, since a CheckImport() would basically do the same thing as the Import() function. Vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Marcin W. <wo...@if...> - 2004-02-12 12:47:28
|
On Thu, 12 Feb 2004, Favre-Nicolin Vincent wrote: > 1) For the generic storage, as suggested I have changed to using > map<CifDataName,vector<float> > and same for strings. I have removed the > non-vector versions. It won't really hurt for those parameters that only need Yes, right. > b) I am now a bit doubting about the CifDataName approach. The constraint of > using CIF data name may be a bit annoying (how to store a generic comment ? > The filename from which the data was imported ?). So although it looks nice, > it may actually be pointless. maybe we shoud just write our own enumeration > of tags that are useful ? And also add an array of description for each tag ? > What do you think ? I don't know (CIF or not). I think we can extend CifDataName if we need, adding new entries with our prefix. BTW, there is no need to prepend '_' in _pd..., eg. if we have in .dic's: data_atom_site_U_equiv_geom_mean data_pd_meas_rocking_axis we just cut 'data_' in both. Or perhaps we should leave it or replace with another prefix? The array of descriptions would be useful, eg. for dumping all informations from file in human-readable format. For CIF we can generate it from .dic files. From next mail: > This would have the double advantage that we could use it in the > command-line interface of the difdaf program (e.g. name=bruker, command = > difdaf -o bruker ...). Was that what you had in mind ? Yes, I was thinking about it. But as Stefan and you wrote in next posts, file extensions and full name / description would also be useful. And it should be possible to verify file format. Do you think that separate function should be used, or import function can return a value / throw exception? Marcin -- Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-12 12:01:27
|
Hi, > Just a question: > what about adding a default file extension to the FormatRegistration > function? Could be useful for setting filters in a file dialog in a GUI > version. FormatRegistration(const std::string name, > const std::string extension, > void (*ptr_import)(Diffractogram&, std::istream &), > void (*ptr_export)(const Diffractogram&, std::ostream &)); Sure we can add this, it can be useful for automatic recognition. We could have 3 strings actually - the extension - the short name (without any space,...), which can be used for command-line selection of formats. - the long description > Another one: > did I get this right? Will it be possible to register a format from eg. the > bruker class without having a definition in difdaf.h /cpp? Yes. > I thought the constructor of the bruker class could call something like: > > > DIFDAF_REGISTER_FORMAT( > "Bruker/AXS", > "raw", > &ImportBruker, > &ExportBruker); > > ImportBruker() etc defined in bruker.h > ???? Not exactly. If you do it this way, you need to create a Bruker class first to have it registered. As Marcin suggested, by making a *global* variable (but only visible in the bruker.cpp file), you ensure that this variable is created _before_ the program begins, and upon creation the variable takes care of the registration. > Dictionary or not: Hmmm, really difficult. I see the odds and evens.... > Standard on the one hand, lot of overhead finding the correct CIF variable > name on the other. I leave that to you. Can you check if you see any data for which we don't have any variable name? Vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Stefan K. <aa...@ge...> - 2004-02-12 10:51:46
|
Hi,
you are really busy, guys!
Just a question:
what about adding a default file extension to the FormatRegistration functi=
on?
Could be useful for setting filters in a file dialog in a GUI version.
FormatRegistration(const std::string name,
const std::string extension,
void (*ptr_import)(Diffractogram&, std::istream &),
void (*ptr_export)(const Diffractogram&, std::ostream &));
Another one:
did I get this right? Will it be possible to register a format from eg. the=
=20
bruker class without having a definition in difdaf.h /cpp?
I thought the constructor of the bruker class could call something like:
DIFDAF_REGISTER_FORMAT(
"Bruker/AXS",
"raw",
&ImportBruker,
&ExportBruker);
ImportBruker() etc defined in bruker.h
????
Would be great to have it this way. The format is so complex that having th=
e=20
routines in difdaf.cpp will make that file very unhandy.
Dictionary or not: Hmmm, really difficult. I see the odds and evens....
Standard on the one hand, lot of overhead finding the correct CIF variable=
=20
name on the other. I leave that to you.
Stefan
=2D-=20
Dr. Stefan Krumm
Institut f=FCr Geologie
Schlossgarten 5
D-91054 Erlangen
+49 9131 852 6063
http://www.geol.uni-erlangen.de
|
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-12 00:29:33
|
> go. Do we restrict ourselves to names without spaces, parenthesis, etc... > and use as initially put by Marcin: > #define REGISTER_FORMAT(name, im, ex) \ > FormatRegistration f_reg_##name(#name, im, ex); > ? This would have the double advantage that we could use it in the command-line interface of the difdaf program (e.g. name=bruker, command = difdaf -o bruker ...). Was that what you had in mind ? Vincent -- Vincent Favre-Nicolin http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-12 00:18:56
|
Hi,
I have uploaded the new version to the CVS. Here are changes:
1) For the generic storage, as suggested I have changed to using
map<CifDataName,vector<float> > and same for strings. I have removed the
non-vector versions. It won't really hurt for those parameters that only need
one entry, and the API is simpler than if we had 4 containers (2 vectorized
and 2 not).
As for integer parameters, they probably can be stored as float without too
much problem. Of course we have to take care at the implicit conversion. One
of the most stupid thing with C++ is that there seem to be no standard
function to compute the ceil or floor or round as an integer value (i.e.
these functions return floating point value- I wonder what idiot created
that).
2) I have added the registration function that Marcin suggested. It's the
ideal way to keep track of new formats. I have just changed a bit the
registration, and the function to get list of all formats is a static
function of the Diffractogram class (I thought this may be better than a
global function,toi recognize difdaf when used in the middle of some other
code).
Ok... I had changed the registration macro to add a __LINE__ to avoid the
problem with the uniqueness of the function, but apparently the preprocessor
does not exapnd __LINE__ inside the macro so this will have to go. Do we
restrict ourselves to names without spaces, parenthesis, etc... and use as
initially put by Marcin:
#define REGISTER_FORMAT(name, im, ex) \
FormatRegistration f_reg_##name(#name, im, ex);
?
3) I have added the import & export for the 2theta I sig(I) file... Although I
still have to try it.
4) Added an Exception class that can print a message.
Next:
a) try actually running a main program !
b) I am now a bit doubting about the CifDataName approach. The constraint of
using CIF data name may be a bit annoying (how to store a generic comment ?
The filename from which the data was imported ?). So although it looks nice,
it may actually be pointless. maybe we shoud just write our own enumeration
of tags that are useful ? And also add an array of description for each tag ?
What do you think ?
Vincent
--
Vincent Favre-Nicolin
http://v.favrenicolin.free.fr
ObjCryst & Fox : http://objcryst.sourceforge.net
|
|
From: Marcin W. <wo...@if...> - 2004-02-11 14:20:42
|
On Wed, 11 Feb 2004, Favre-Nicolin Vincent wrote:
> I still have to write down the example to see how things are working. The
> generic storage for info/parameters still has a few things to be resolved:
> - handling multiple entries coreesponding to the same keyword (e.g. several
> operators, several comments)
Hmm, if the order of entries matters, I can see two solutions:
1) add map<CifDataName,vector<float>> and map<CifDataName,vector<string>>
to map<CifDataName,float> and map<CifDataName,string>.
2) change multimap<...,float> to map<...,pair<float,int>>,
where "int" is a counter. And the same for string.
I hope that you will think out a better solution.
BTW, what about integers? Do you want to store them as floats?
> - storing parameters that are multiple by nature (e.g. the two wavelengths of
> an X-Ray tube, with their associated intensity ratio)
If order of parameters with the same CifDataName is preserved,
n-th wavelength corresponds to n-th ratio.
> I'll add a simple example on the morrow to give a better idea, but you can
> tell me if you like/hate current code.
I like it :)
I was thinking about separation of "core" and file format modules.
IMHO adding a new module should not require changing of core.
Module should register itself (during compilation).
When importing/exporting file of given format the name of the format
would be searched and corresponding import/export functions would be
called. What do you think about it? It is illlustrated below:
::::::::::::::
pattern.h
::::::::::::::
#ifndef PATTERN__H__
#define PATTERN__H__
#include <fstream>
#include <string>
#include <vector>
class PowderPattern
{
};
struct FormatFuncs
{
std::string name;
void (*import_file)(PowderPattern&, std::istream &);
void (*export_file)(PowderPattern&, std::ostream &);
};
extern std::vector<FormatFuncs> formats;
class FormatRegistration
{
public:
FormatRegistration(std::string name,
void (*ptr_import)(PowderPattern&, std::istream &),
void (*ptr_export)(PowderPattern&, std::ostream &));
};
std::string get_list_of_formats();
#define REGISTER_FORMAT(name, im, ex) \
FormatRegistration f_reg_##name(#name, im, ex);
#endif //PATTERN__H__
::::::::::::::
format1.cpp
::::::::::::::
#include "pattern.h"
using namespace std;
void foo_import (PowderPattern&, std::istream &)
{
}
void foo_export (PowderPattern&, std::ostream &)
{
}
REGISTER_FORMAT(foo, foo_import, foo_export);
::::::::::::::
format2.cpp
::::::::::::::
#include "pattern.h"
using namespace std;
void format2_import (PowderPattern&, std::istream &)
{
}
void format2_export (PowderPattern&, std::ostream &)
{
}
FormatRegistration format_2("format_2", format2_import, format2_export);
::::::::::::::
main.cpp
::::::::::::::
#include "pattern.h"
#include <iostream>
using namespace std;
int main()
{
cout << "List of formats:\n";
cout << get_list_of_formats();
return 0;
}
::::::::::::::
pattern.cpp
::::::::::::::
#include "pattern.h"
using namespace std;
FormatRegistration::FormatRegistration(string name,
void (*ptr_import)(PowderPattern&, istream &),
void (*ptr_export)(PowderPattern&, ostream &))
{
FormatFuncs ff;
ff.name = name;
ff.import_file = ptr_import;
ff.export_file = ptr_export;
formats.push_back(ff);
}
string get_list_of_formats()
{
string s;
for (vector<FormatFuncs>::const_iterator i = formats.begin();
i != formats.end(); ++i)
s += i->name + "\n";
return s;
}
std::vector<FormatFuncs> formats;
|
|
From: Favre-Nicolin V. <vi...@us...> - 2004-02-10 23:47:47
|
Hi, Done a bit more work and added it to the CVS. The doxygen doc will now b= e=20 automatically updated every night on sourceforge. Checkout with: cvs -d:ext:LO...@cv...:/cvsroot/difdaf co difdaf I still have to write down the example to see how things are working. Th= e=20 generic storage for info/parameters still has a few things to be resolved: - handling multiple entries coreesponding to the same keyword (e.g. severa= l=20 operators, several comments) - storing parameters that are multiple by nature (e.g. the two wavelengths= of=20 an X-Ray tube, with their associated intensity ratio) I'll add a simple example on the morrow to give a better idea, but you c= an=20 tell me if you like/hate current code. Vincent =2D-=20 Vincent Favre-Nicolin Universit=E9 Joseph Fourier http://v.favrenicolin.free.fr ObjCryst & Fox : http://objcryst.sourceforge.net |
|
From: L. C. <lz...@dl...> - 2004-02-10 06:34:57
|
I believe it is microseconds - though maybe getting some example ISIS HRPD TOF data would be good (from Anders?). HRPD data has non-constant step - so would give one of the more challenging examples. > I guess step scan and TOF are the main scan to support, though. I do not > know if quantitative data analysis is done with the other scan types. Some people use continous scans for their work, and people using an INEL PSD would have a stationary detector. Plus some types still go to energy dispersive beamlines. Lachlan. > > Hi Lachlan, > > Just a quick question (which may require a long answer, though). We are > working on the difdaf design, and one question is what we should include as > info for each point of a scan. Particularly, how to store TOF data ? Is it > _just_ a matter of replacing the 2theta field by a 'time' (in microseconds). > I'm only talking about *storing* the data, not treating it, of course. > Any thoughts ? > > On a side note, there are other methods for scan, quoting from the CIF > Powder dic : > > ########### > data_pd_meas_scan_method > _name '_pd_meas_scan_method' > _category pd_meas_method > _type char > loop_ _enumeration > _enumeration_detail step 'step scan' > cont 'continuous scan' > tof 'time of flight' > disp 'energy-dispersive' > fixed 'stationary detector' > _definition > ; Code identifying the method for scanning reciprocal space. > The designation `fixed' should be used for measurements where > film, a stationary position-sensitive or area detector > or other non-moving detection mechanism is used to > measure diffraction intensities. > ########### > > I guess step scan and TOF are the main scan to support, though. I do not > know if quantitative data analysis is done with the other scan types. > > Vincent > -- > Vincent Favre-Nicolin > http://v.favrenicolin.free.fr > ObjCryst & Fox : http://objcryst.sourceforge.net > > -- ----------------------- Lachlan M. D. Cranswick Neutron Program for Materials Research (NPMR), National Research Council (NRC), Postal Address: NPMR, NRC, Building 459, Station 18, Chalk River Laboratories, Chalk River, Ontario, Canada, K0J 1J0 Fax: (613) 584-4040 Tel (work): (613) 584-8811 Office: ext 3719 ; C2 diff: ext 3039 Email: lac...@nr... WWW: http://neutron.nrc.ca/ Tel (home): (613) 584-4226 WWW: http://lachlan.bluehaze.com.au/ Home Email: la...@me... Mobile/Cell phone: 613 401 3433 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.) |
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-10 00:03:18
|
Hi Lachlan,
Just a quick question (which may require a long answer, though). We are
working on the difdaf design, and one question is what we should include as
info for each point of a scan. Particularly, how to store TOF data ? Is it
_just_ a matter of replacing the 2theta field by a 'time' (in microseconds).
I'm only talking about *storing* the data, not treating it, of course.
Any thoughts ?
On a side note, there are other methods for scan, quoting from the CIF
Powder dic :
###########
data_pd_meas_scan_method
_name '_pd_meas_scan_method'
_category pd_meas_method
_type char
loop_ _enumeration
_enumeration_detail step 'step scan'
cont 'continuous scan'
tof 'time of flight'
disp 'energy-dispersive'
fixed 'stationary detector'
_definition
; Code identifying the method for scanning reciprocal space.
The designation `fixed' should be used for measurements where
film, a stationary position-sensitive or area detector
or other non-moving detection mechanism is used to
measure diffraction intensities.
###########
I guess step scan and TOF are the main scan to support, though. I do not
know if quantitative data analysis is done with the other scan types.
Vincent
--
Vincent Favre-Nicolin
http://v.favrenicolin.free.fr
ObjCryst & Fox : http://objcryst.sourceforge.net
|
|
From: Favre-Nicolin V. <vi...@fa...> - 2004-02-09 23:54:46
|
Hi,
OK, I had a few hours to begin coding but it's not yet ready so I'll put
that into the cvs only tomorrow. To store most info using in a 'generic' way
as proposed, I copied all keywords ("data names") from the CIF Powder and
Core dictionnaries. I have commented a good part of the core dic keywords as
they will not be used. We'll need to ducument those that we actually use.
(maybe _only_ those that we actually use should be uncommented, in fact. That
would also allow putting a few doxygen-style information for these. Will do
that tomorrow)
The 2 headers are now @:
http://difdaf.sourceforge.net/difdaf.h
http://difdaf.sourceforge.net/cif_data_name.h
And the doxygen documentation @ http://difdaf.sourceforge.net/
I'll continue tomorrow with this, and try to add a basic Import function
(for a 3-column file or a basic format recognized by fullprof) as an example.
Vincent
--
Vincent Favre-Nicolin
http://v.favrenicolin.free.fr
ObjCryst & Fox : http://objcryst.sourceforge.net
|