1

FITTING DOUGLAS LEONARD

2

GDFIT: A program (by me) for Ge fitting for NAA

Black: Data from a Canberra O-RING on 100% Ge at Y2L.

Red: Unconverged initial fit setup for a detector in Alabama. No tweaking of initial parameters.

3

ONE COMMAND AND A FEW SECONDS FINDS ENERGY CALIBRATION…

… Even with completely wrong amplitudes and backgrounds. • Only need to scan one

parameter. • Nonlinearity can be

washed over for initial scan by using fat peaks. (not necessary here)

• No need to let MINUIT go crazy.

A second scan will get peak amplitudes and ROI backgrounds pretty close

THEN MINUIT locks it all down.

Still requires intelligent user to look for over-parameterization etc when things don’t work, (but auto scripts can flag bad fits)

4

A FEW OF THE BASIC FEATURES:

Activities are parameterized, not peaks (peak ratios are fixed)

Peak energies are fixed (but can float for unknown peaks), energy calibration floats.

-Non-linear calibration terms are handled with appropriate axis view output.

-Non-linear bin area corrections not presently included. Easy to include, but a tiny effect.

Global energy and peak width calibrations (optionally override per peak).

peak widths are presently sqrt (a +bE)

One fit definition can fit many spectra (ROI’s are by energy, not channel).

Peaks amplitudes are linked to activity parameter by branching ratios and efficiency

(Gowoon’s efficiency sim, doesn’t include coincidence corrections, but it could)

Interactive display/shell gives somewhat user friendly handle on things and accepts MINUIT commands directly as well.

Chi-squared reported per ROI to find problems (there’s even an ROI slideshow mode).

Fit is log-likelihood or optionally chi squared.

5

LOW BACKGROUND USE CASE: (Ge O-RING EXAMPLE)

1) After minimizing.. Calibration stored as individual peak position constraints.

2) Background spectrum fit

-Uses calibration constraint terms from o-ring fit.

-Peaks are fit with individual rates, not activities.

(we don’t know efficiencies for background peaks)

-Output all bg peak rates and uncertainties to a file.

3) Refit O-ring data

-Read in background rates. (For low activity sample, also read calibration constraints)

-The new fit sums each background rate with rate derived from the floating activity.

-Background peak rates float individually, but are constrained by bg data.

This fit is scriptable (std in) and is used for batch fitting hundreds of NAA spectra, with often 40 ish peaks on a batch cluster to get decay series for each (which are then fit to exponentials).

Most fits converged with good chi-squared without intervention.

6

O-RING W/ BACKGROUNDS

7

IT GIVES RESULTS OF COURSE…CANBERRA O-RING: BACKGROUND ACCOUNTED FOR IN FITParent mBq212Pb 0.42+/-0.04208Tl .028+/-0.09 *,**

226Ra 4.5+/-0.4214Bi 1.61+/-0.06214Pb 2.18+/-0.0640K 1.5+/-0.2

* Efficiency doesn’t account for strong coincidences, 212Pb is more reliable. **208Tl has ~30% branching ratio. Activity shown is for 208Tl, not 232Th equivalent.

8

CU-A: BACKGROUND ACCOUNTED FOR IN FIT, ENERGY CALIBRATION CONSTRAINED BY O-RING RESULTS.Parent mBq212Pb -0.018+/-0.012208Tl -.0014+/-0.005 226Ra -0.06+/-0.13214Bi -0.021+/-0.012214Pb -0.039+/-0.01740K 0.05+/-0.07

9

MORE DEMO THAN ANALYSIS:I’ve just been trying to get the code and my computing environment running again and see if I am too old to do real work ( Bugs can only be found at 2 am).

This code is Fortran 77 (I don’t love that), and has no capability to do MC fitting.

But we can write something similar in C++.

The philosophy of the code was to setup a framework, allow minuit commands through, and then add routines and macros for added functionality as needed for productivity.

Ex: energy scanning routine, ascii file reader, etc..

Much more could still be easily added, but it could be better to rewrite and think bigger.

Doing this stuff right isn’t trivial. There are several gotchas. Ex: ROI’s specified in energy. E calibration changes during fit. Must avoid ROI

shift during minimization (worst case, ROI’s shove off edge to drop chi-squared)!

10

THINGS MISSING-> IDEAS FOR A NEW TOOL MC fitting

Multiple PDF contributions. (Ex: SeungYoon Oh’s KIMS-NaI background fit)Resolution convolution in fit loop, and handling of non-linear energy-calibration binning problem

(solvable).Accidental coincidence spectral calculation inside fit loop!!?? (for AMoRe)

Generalized data types: Really original use of this code was designed especially for this, for modelling cross section data. This version has it minus the “generalized” part (calibration and bg constraints)Basically, allow N data types where each data type has its own chisquare/likelihood fit function

using different combinations of parameters. (Ex: bg data “fit” to bg rate parameters, spectra fit to those plus activities plus…).

This naturally allows to transition between completely different fit types or just simultaneous fitting of related data types (single-site, multi-site, constraint data, etc).

Danger of over-abstractifying More work, less results. Need flexible framework, but concrete tools.Start flexible (hard part), build tools as needed.

Pull peaks/activities from Table of Isotopes. (presently setup by hand initially).

11

STATUS

At present GDFIT can give quick useful results for Ge counting without modification and possibly less work than by-hand root fitting. It has been proven to work in multiple contexts.

Having the right tool on hand can drastically speed up repetitive work. (NAA example).Many analyses are highly duplicative yet people start from scratch.A good toolbox allows incremental improvements in capability.

For future, maybe GDFIT has some useful elements to consider, but not all.

12

RELIGION Fortran should go of course.

OO is fine with me, with care of speed inside loops.

People want their ROOTness. That’s fine. Fits are MINUIT.Root is mostly data structures and I/O. (let’s compile, no CINT)Root fitting (TFIT) can limit fits of structured data (individual arrays, no roofit goodness).

But TTREES can do anything array[][3] and fwrite can(speed?), fine, and we can still use MINUIT.

It’s easy enough to add root input and output modules (I did even for geant3!!) and root plotting modules. (Maybe OO helps flexibility)

Personally I hate root as a plotter (terrible interaction), but we can even have multiple plotting modules.

And we can even use TFIT. It actually CAN simplify MINUIT handling even for complex fits. You CAN (I have) map any discrete data into one array, with an array map accessed by the fitting function

through an external namespace multiple data types.If we outgrow it, fine. We have to add some coding.