[Fityk-users] Feature Request: Voigt/Gauss Area

[Markus Weigand]

Hello!

We in our department have recently discovered fityk, and found it a lot
better in terms of usability than Peakfit, which is currently in use.

But to be actually usable for XES/XPS , one would require area based
voigt/gauss functions (in contrast to the current height based ones).

Such an area-voigt would be defined by :position,area, gauss-width and
lorenz width.
(in contrast to the current position,height,gwidth,shape).

Would it be possible to implement those?

Best regards,

Markus Weigand

---
Markus....@physik.uni-wuerzburg.de

[Marcin Wojdyr]

On Fri, 24 Feb 2006, Markus Weigand wrote:

> But to be actually usable for XES/XPS , one would require area based
> voigt/gauss functions (in contrast to the current height based ones).

Yes, I've heard that area-based versions of peaks are sometimes more
convenient. I was thinking what is the simplest way to do it
internally, but haven't come to any conlusions.
So i'll add these functions, although I can't say when (probably
this winter or spring).

Could you write, why using Voigt-Area is better than using Voigt-Height
and reading a value of area?

BTW, there is also another issue with Voigt function, I'm using quite
rough approximation of it (it's calculated much faster than Gaussian),
is it exact enough for everyone?

Marcin

--
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/

[Markus Weigand]

Thanks for the swift response!

>
> Yes, I've heard that area-based versions of peaks are sometimes more
> convenient. I was thinking what is the simplest way to do it
> internally, but haven't come to any conlusions.
> So i'll add these functions, although I can't say when (probably
> this winter or spring).
>
> Could you write, why using Voigt-Area is better than using Voigt-Height
> and reading a value of area?

There is not really a big problem when just fitting single peaks, but
there are situations where you get multiple pairs of peaks, from two
different decay channels.
As the yield of a decay channel is proportional to the area of a peak,
not the height, with area-voigt one could just create another rule,
(i.e. %1[area]=%2[area]*x1, %3[area]=%4[area]*x1, ect).
While currently, there is no way at all (or not that i have found) to
access the area of the peaks at all for scripting.

> BTW, there is also another issue with Voigt function, I'm using quite
> rough approximation of it (it's calculated much faster than Gaussian),
> is it exact enough for everyone?

Well, i discovered fityk quite recently, and didn't work much with it
yet, but the few examples i crosschecked were not that different from
the peakfit 4.1 results.

But of course an (maybe optional, for the people with older computers)
more accurate model would not hurt at all, as currently the
computationally limiting factor while fitting is the console output
(going from "normal" -> "rather quite" more than halves the time for a
100 step fit of 4 voigts.... (from 1.5 or so down to under 0.5 seconds
on a 3 year old laptop).

> Marcin

best regards,

Markus Weigand

---
Markus....@physik.uni-wuerzburg.de

[David Hovis]

On Feb 24, 2006, at 9:44 AM, Marcin Wojdyr wrote:

Could you write, why using Voigt-Area is better than using Voigt-Height

and reading a value of area?

When I am fitting fluorescence peaks, I have peak doublets that overlap.  The area under one peak is roughly double the area under the other.   I have some very long cfityk scripts that allow me to hold the ratio of the peaks constant.

Basically, I make Height(peak2) = f(height of peak 1, width of peak 1, Lorentz fraction of peak 1, width of peak 2, Lorentz fraction of peak 2, a multiplier).

Using Voigt Area, I would be able to define Area(Peak2) = multiplier*Area(Peak1).

Frankly, I'd never heard of doing this before, but it would probably cut some of my scripts down by an order of magnitude in length and make them much easier to read and debug.

I could also see it as useful for fitting Kalpha1/Kalpha2 doublets in XRD.

I think I have a new favorite feature request. 

--David

PS: the pseduo Voigt peak (^S) gives perfectly good results for everything I've thrown up against it.  I've never found a situation where using the numerical approximation (^V) peak gives a meaningfully better fit.  ^S certainly has a speed advantage, and it would be (nearly) trivial to switch to the area definition.

[Marcin Wojdyr]

Hello Markus, David and all users,

I'll add area-based Voigt soon, so it will be available in next release.
As I understood, Voigt was the most important one.

For other functions, where it is possible to express area in terms
of other parameters, I'd like to find a way, which will allow to
do the same without rewritting all calculations in source code,
and it will take more time.
So there also will be area versions of Gaussian, Lorentzian, etc,
but later.

I'll also try to write a description, how to add built-in function,
so it will be possible to make own functions with only basic C knowlegde.
And, rather later then sooner, user defined functions will be available.

[Marcin Wojdyr]

... was released yestarday.

From ChangeLog:

* area-based Voigt function (VoigtA)
* GUI, MS Windows only, Session > "Copy to Clipboard" copies plots to
clipboard
* added fityk.desktop file for Linux desktop integration (Niklas Volbers)
* GUI: "directories" tab in settings dialog

The next feature will be (probably) logarithmic y axis.

Cheers,