• View
• Edit
• History
• Print

MulabV2DoubleFit

< Synopsis of 1.05 on day one | Index | Linear Relations >

These are plans for implementing simultaneous fits of data from all detectors in typical experimental geometries.

Scheme of double fit

The scheme is that there are always two groups, defined as Forward - Backward and Up - Down. Detector groups are identified as F, B, U, D, respectively, and the two groups as FB and UD. The simultaneous fit is dubbed double and the independent fits are single.

For example at PSI, in GPS, GPD, Dolly and LTF one has (F,B)=(1,2) - with a discrepancy between GPS and LTF, and (U,D)=(3,4). At ISIS EMU has only F=1:32 and B=33:64, in which case U,D are empty; MUSR can be grouped either as EMU, in longitudinal mode, or as F= , B= , U=, D= (check!)

Notice that at PSI, with Spin Rotator ON, one can have:

1. a weak transverse field, yielding equivalent precessions in FB and UD, phase-shifted by 90 degrees, like in transverse mode at ISIS.
2. a dominant external longitudinal field, yielding a precession in UD and a longitudinal fraction in FB, which are probably best analysed as single fits.
3. a dominant internal field in a polycrystal sample, yielding an a verage polarization with equivalent precessing and longitudinal components in both groups.

Top

Ways to implement

• redesign of the mufit_gui window;
• two group sections (F, B, with AlphaFB and U, D with AlphaUD) where the two Alpha factors are the ratios of the average counts per bin in B over F, D over U, respectively;
• a switch between single group and double group mode (MU_MODEL.SINGLE, integer treated as logical: value=0 means DOUBLE FIT; value=1 means FB group; value=2 means UD group);
• two parameters, treated before and outside the normal Component-Parameter convention of mulab, a fixed ratio UD/FB for the asymmetries in the two groupings and a phase shift DePhi;
• these two parameters can only be fitted or fixed (e.g. DePhi can be fixed to zero, in case 3, or varied around 90 degrees in case 1;
• the usual parameters defining a model by components are duplicated on the parameter panel of the Fit menu gui and numbered in odd-even pairs (3,4) (5,6) ...;
• this can be accomplished either by duplicating the model (a damumu model becomes a dadamumumumu model), or by changing the structure of MU_MODEL when MU_SINGLE is false)
• the even instance is the usual parameter, which has a value, and a flag (~, !, = for variable, fixed, expressed by a linear relation); the odd instance has the flag only, either ~ or =; typical use would be
  • =p(1)*p(3), to anchor the amplitude to the odd value parameter (p(3), in this example), multiplied by the fitted common ratio UD/FB;
  • =p(5)+p(2), to anchor the phase to that of the FB component, given by the odd value parameter (p(5), in this example), shifted by the fitted common phase DePhi;
  • alternatively, =p(5), to share the same value of the FB component.

Top

Indexing parameters

Mulab needs:

• a parameter number to be displayed in the Fit Menu, p in mufit_gui, with the odd/even rules described above; this index can number also the tags of the first two parameters (UD/FB and DePhi in double fit mode) as m=Nmenumenu+2*(p-1)+1 for value and m=Nmenumenu+2*p for flag
• a separate parameter count for double fit mode, pp in mufit_gui, which numbers in groups of five the tags of the fit parameter windows (menutags.tag(m), m=Nmenumenu+4+4*(pp-1)+1,...,Nmenumenu+4+4*pp, for value, flag, flagbis, plot
• this layout of the Fit Parameter Menu can be reflected in the MU_FIT structure, where too even and odd parameters can be replicas, respectively for the FB and the UD groups
• the information must be accommodated inside the usual MU_MODEL.COMPONENT(comp).PARAMETER(par) scheme, where, in double fit mode, comp may be
  • either odd (FB main component), with usual fields
    • NAME
    • VALUE
    • FLAG
    • SHARE (internal)
    • PLOT
  • or even (UD replica), with fields
    • NAME
    • VALUE never relevant
    • FLAG, this is the only relevant field of the replica, since it contains the defining relation
    • SHARE (internal, will always be zero)
    • PLOT will always be 5 (displayed as 0 in the Menu, meaning do not plot)

Top

mufit strategy

The user input is distributed by mufit_gui in the Menu_CallBack, which

• finds the correspondence between index of parameter, n, and the (component, parameter) pair, (comp, par) by means of [name comp par]=mucomp(n)
• stores directly the value typed in the value edit window of the Fit Parameter Menu into MU_MODEL.COMPONENT(comp).PARAMETER(par).VALUE
• reads the string typed in the ~ ! = edit window, which can be e.g.

 ~ 
 ! 
 =p(1)
 =3*p(4)+0.25

• the last string is an example of a relation that assigns to a parameter, say p(9), the result of a calcuation, where p(4) represents another parameter; the target index, n=9, and the source index, n=4, are those that appear in the Fit Parameter Menu of the graphic window.
• this string is passed to muextractflag(string,n) where the syntax is checked with muparse, the symbol ~ ! = is stored in MU_MODEL.COMPONENT(comp).PARAMETER(par).FLAG, the rest of the string (for =) is temporarily stored in MU_MODEL.COMPONENT(comp).PARAMETER(par).LINREL
• just before launching fminuit, mufit transforms the string stored in LINREL, recalculating the indices n of the parameters. In a first cycle a new index m is recalculated for each fitted or fixed parameter (~ !) omitting the count of parameters defined by a relation. The new index is stored in an array, shareglobal(n)=m, and shareglobal(n)=0 indicates a relation. In a second cycle the source index is replaced inside the relations by the new index m and this modified version is stored in MU_MODEL.COMPONENT(comp).PARAMETER(par).MENU2MINUIT.
• the function called by minuit, mufcn, transforms the input parameter vector, p=[p(1) p(2) ... p(end)], into the whole list of parameters required by MU_MODEL, thanks to the modified relations of MENU2MINUIT

Top

Component calculation

The basic idea is to create a blank-separated string that reallocates the minuit parameters.

Each reallocation substring is first generated by mufit, just before launching fminuit and it is stored in MU_MODEL.COMPONENT(c).PARAMETER(p).MENU2MINUIT: for each parameter of the Fit Parameter Menu list (the graphic window) the substring is either, say,

 p(3)

or

 p(3)*0.333

where the index (3, in the example) refers to the fminuit internal parameter list.

This number is recalculated just before storage of the MENU2MINUIT substring in two cycles. The first cycle progressively increments the internal fminuit parameter index @n@ for variable and fixed parameters ('~,!') and stores directly their 'p(n)' substring. The second cycles readdresses the linear relations (and shared parameters, which are treated just as linear relations from Ver. 2.0).

Before invoking fminuit, mufit Ver. 2.0 precalculates the string that obtains the parameters of each component (da, ba, mu, etc.) from the internal minuit parameters. A readdressing command string of the type

 [p(8) p(9) p(5) p(10) p(11)] 

is assembled at this stage and stored in MU_MODEL.COMPONENT(k).COMMAND, whereas MU_MODEL.COMPONENT(k).INDEX stores the component position in the MU_COMPONENT list. Double fits do the same for the UD group storing the additional field COMMANDUD.

Inside fminuit, at each iteration, mufcn receives the internal parameter values in array par as well as the full data array. It produces the component parameters by the sequence

 p=par;
 p=eval(MU_MODEL.COMPONENT(k).COMMAND);

for each component. The contribution to the model function is calculated in the appropriate routine, invoked by the string MU_COMPONENT.DEFINITION(MU_MODEL.COMPONENT(k).INDEX), which contains (e.g. for mu

 muprecession(p,data)
The UD group is treated similarly.

Top

< Synopsis of 1.05 on day one | Index | Linear Relations >