|
close
Warning:
Can't synchronize with repository "(default)" ("(default)" is not readable or not a Git repository.). Look in the Trac log for more information.
- Timestamp:
-
Jun 13, 2017, 3:47:33 PM (8 years ago)
- Author:
-
Patrick Stowell
- Comment:
-
--
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v3
|
v4
|
|
237 | 237 | sample NAME_OF_SAMPLE INPUT_TYPE:FILE_INPUT |
238 | 238 | }}} |
| 239 | - **NAME_OF_SAMPLE** : Name of the sample we found using nuissamples |
| 240 | - **INPUT_TYPE** : Type of the input file we are using (e.g. GENIE) |
| 241 | - **FILE_INPUT** : Path to the input MC event we want to use for this sample. |
| 242 | - **OPTION** : (Optional Argument) Option that can be used to change sample behaviour at runtime. By default this is left as DEFAULT. |
| 243 | - **NORM_VALUE** : (Optional Argument) Start value of normalisation parameter used to change the MC normalisation for this sample. By default this is left at 1.0. |
| 244 | |
| 245 | For further examples on how to include these structures in card files please see [wiki:CardFileExamples Card File Examples]. |
239 | 246 | |
240 | 247 | So if our GENIE file is called 'MiniBooNE_FHC_numu_2.5M.root', our card file will be : |
… |
… |
|
250 | 257 | |
251 | 258 | === Reweighting GENIE Comparisons === |
252 | | The comparisons application also allows different GENIE reweight parameters to be provided in our card file. |
| 259 | The minimiser application allows different GENIE reweight parameters to be provided in our card file and floated freely until the likelihood is maximised. |
253 | 260 | |
254 | 261 | The format for fixed dial values is: |
… |
… |
|
258 | 265 | or for free dial variations |
259 | 266 | {{{ |
260 | | genie_parameter NAME VALUE LOW HIGH STEP STATE |
| 267 | genie_parameter NAME VALUE LOW HIGH STEP STATE |
261 | 268 | }}} |
262 | 269 | |
… |
… |
|
271 | 278 | |
272 | 279 | |
273 | | In our example we shall generate another set of comparisons this time with two parameters shifted. |
| 280 | In our example we want to tune the following parameters |
274 | 281 | - Charged Current Quasielastic Axial Mass : Axial mass parameter used in the quasielastic form factor |
275 | 282 | - Charged Current Quasielastic Normalisation : Total normalisation of CCQE events. |
… |
… |
|
286 | 293 | switch(syst) { |
287 | 294 | case ( kXSecTwkDial_MaNCEL ) : return "MaNCEL"; break; |
288 | | |
| 295 | case ( kXSecTwkDial_EtaNCEL ) : return "EtaNCEL"; break; |
| 296 | case ( kXSecTwkDial_NormCCQE ) : return "NormCCQE"; break; |
| 297 | case ( kXSecTwkDial_NormCCQEenu ) : return "NormCCQEenu"; break; |
| 298 | case ( kXSecTwkDial_MaCCQE ) : return "MaCCQE"; break; |
| 299 | case ( kXSecTwkDial_MaCCQEshape ) : return "MaCCQEshape"; break; |
| 300 | case ( kXSecTwkDial_ZNormCCQE ) : return "ZNormCCQE"; break; |
289 | 301 | ... |
290 | | |
291 | | case ( kXSecTwkDial_NormCCRES ) : return "NormCCRES"; break; |
292 | | case ( kXSecTwkDial_MaCCRESshape ) : return "MaCCRESshape"; break; |
293 | | case ( kXSecTwkDial_MvCCRESshape ) : return "MvCCRESshape"; break; |
294 | | case ( kXSecTwkDial_MaCCRES ) : return "MaCCRES"; break; |
295 | | case ( kXSecTwkDial_MvCCRES ) : return "MvCCRES"; break; |
296 | 302 | }}} |
297 | 303 | |
298 | 304 | We can see the dials we are interested in this list, specified by the strings: 'MaCCQE' and 'NormCCQE' respectively. |
299 | 305 | |
300 | | Now we want to change these dials to +1 for MaCCES and -1 sigma for NormCCRES. Therefore we add the following lines to our card file: |
301 | | |
302 | | {{{ |
303 | | genie_parameter MaCCRES +1.0 FIX |
304 | | genie_parameter NormCCRES -1.0 FIX |
305 | | }}} |
306 | | |
307 | | so that it now looks like the following |
| 306 | Now we want to change include these dials in our card file. To start with we will try tuning a single parameter, keeping NormCCQE fixed at +0.1 sigma instead. Although we are keeping it fixed, we define the limits on NormCCQE anyway, in case we want to vary it later. |
| 307 | {{{ |
| 308 | genie_parameter MaCCQE 0.0 -3.0 3.0 1.0 FREE |
| 309 | genie_parameter NormCCQE 0.1 -3.0 3.0 1.0 FIX |
| 310 | }}} |
| 311 | |
| 312 | So now our card file looks like the following: |
308 | 313 | |
309 | 314 | **genie_tutorial.card** |
310 | 315 | {{{ |
311 | | genie_parameter MaCCRES +1.0 FIX |
312 | | genie_parameter NormCCRES -1.0 FIX |
313 | | |
314 | | sample MiniBooNE_CC1pip_XSec_1DTpi_nu GENIE: gntp.2063030.ghep.root |
315 | | sample MiniBooNE_CC1pip_XSec_1DTu_nu GENIE: gntp.2063030.ghep.root |
316 | | }}} |
317 | | |
318 | | |
319 | | |
320 | | |
321 | | |
322 | | |
323 | | |
324 | | |
325 | | |
326 | | |
327 | | |
328 | | |
329 | | |
330 | | |
331 | | |
332 | | |
333 | | |
334 | | |
335 | | |
336 | | |
337 | | |
338 | | |
339 | | |
340 | | |
341 | | === Setting up our reweight dials === |
342 | | |
343 | | Now that we have our samples, the next thing we want to do is choose some dials to vary. If we look inside |
344 | | |
345 | | |
346 | | ==== Defining Free dials ==== |
347 | | |
348 | | ==== Checking dial response ==== |
349 | | |
350 | | ==== Specifying fixed dials ==== |
| 316 | genie_parameter MaCCQE 0.0 -3.0 3.0 1.0 FREE |
| 317 | genie_parameter NormCCQE 0.1 -3.0 3.0 1.0 FIX |
| 318 | |
| 319 | sample MiniBooNE_CCQE_XSec_1DQ2_nu GENIE:MiniBooNE_FHC_numu_2.5M.root |
| 320 | sample MiniBooNE_CCQE_XSec_1DQ2_antinu GENIE:MiniBooNE_FHC_numu_2.5M.root |
| 321 | }}} |
| 322 | |
351 | 323 | |
352 | 324 | === Running the minimiser (Migrad) === |
| 325 | Now that we have a prepared card file from the previous section, we can now run the minimiser. |
| 326 | |
| 327 | Lets start it running, we will use a smaller number of events for this example so we can get some idea of the behaviour. We do this by passing the '-n' option at the command line. |
| 328 | |
| 329 | **WARNING** this is only so you can quickly see the results of minuit and check that the minimiser and your card file is working correctly. For serious fitting you should never use the '-n' flag. |
| 330 | |
| 331 | {{{ |
| 332 | $ nuiscomp -c genie_tutorial.card -o genie_minuit_maccqe-free_normccqe-fixed.root -n 50000 |
| 333 | }}} |
| 334 | |
| 335 | Now that we have left that running in the background, lets quickly discuss how Migrad works and some options you have to make NUISANCE run a bit quicker. |
353 | 336 | |
354 | 337 | ==== How Migrad works ==== |
355 | 338 | |
| 339 | Migrad is the default minimisation routine that nuismin uses. It attempts to find a best fit parameter set that maximises a likelihood (minimises a chi-squared value). When we run nuismin, the NUISANCE routines classes tells Migrad that the parameters we have defined as FREE should be treated as registered as free variables and the samples we have listed should be used to form a likelihood. |
| 340 | |
| 341 | Then when Migrad is run, it will step around the parameter space provided to it, calculate a likelihood given the parameters at the new step, and use a gradient descent algorithm to work its way to a best fit parameter set. Each of these 'steps' is referred to as an iteration, and usually a large number of iterations are required so that Migrad can find a reliable minimum. |
| 342 | |
| 343 | |
| 344 | To calculate the likelihood at each step NUISANCE has to recalculate all of the MC predictions for the given parameter set at the step, before using them to calculate a data-MC likelihood. Since we have to loop over the event sample at each iteration, this can take a while to actually converge, hence why for this example we have restricted the number of events. |
| 345 | |
| 346 | Eventually when Migrad does think it has found a best fit point, it will step around the minimum checking that it is a good valid minimum, and assuming Gaussian statistics, calculate errors and correlations on each of the parameters. |
| 347 | |
| 348 | One issue that a user should be aware of is that Migrad can sometimes fall into local minima, which is especially more likely if the likelihood surface is non-linear. This can result in bias fit results, and it is advisable that extra closure tests are performed by start the minimiser from different starting values (changing the NOMINAL value in the parameter card file definition) and checking that the fit results are stable. |
| 349 | |
| 350 | |
356 | 351 | ==== Signal Reconfigures ==== |
357 | 352 | |
| 353 | The fact the Migrad has to iterate many times can be very time consuming. |
| 354 | With large event samples it is not uncommon for tunings with multiple parameters to take days since to calculate a likelihood for a given iteration NUISANCE has to recalculate **all** the MC predictions for the updated parameter set before comparing the data to MC. This involves reading every single event in our samples at each iteration, recalculating event weights using our reweight engines, filling each of the histograms with the updated weight, and then finally calculating a likelihood for all samples included. The two most time consuming pieces of this iteration are the reading and event weight calculation stages, and as such a lot of event handling functionality has been added to the core classes of NUISANCE to minimise iteration time. This is referred to as the 'EventManager'. |
| 355 | |
| 356 | The EventManager's job is to keep a global list of all possible inputs and what samples they are assigned to, making sure that no event is read from disk twice or event weight is calculated twice during a single iteration. When the EventManager is switched on 'config EventManager 1' which it should be by default, during a single event loop, first the EventManager will read an event and calculate a weight before distributing that event information to only the relevant samples saving a significant amount of time compared to performing an event loop for each sample individually. |
| 357 | |
| 358 | To increase the speed of the EventManager even further a 'SignalReconfigures=1' option has been added which is not enabled by default, but that makes sure that only events that have been flagged as signal by the sample classes actually get read from disk and weights calculated. This mode is available but has not been extensively tested with all samples yet, so **use it with caution**. |
| 359 | |
358 | 360 | ==== Saving Nominal Prediction ==== |
| 361 | A configuration option is alose provided that forces NUISANCE to run an additional reconfigure step when starting nuismin that will save the starting MC predictions into a seperate folder in the output file called 'nominal/', so that pre-fit vs post-fit comparisons |
| 362 | can be made. |
| 363 | |
| 364 | This can be turned on by using the configuration option |
| 365 | {{{ |
| 366 | config savenominal 1 |
| 367 | }}} |
359 | 368 | |
360 | 369 | === Analysing the output === |
|