search

gcowan / RapidSim

Phase space generation of b hadron decays
MIT License
18 stars 29 forks source link

Handling properties which should not be smeared or should always be smeared #15

Closed particleist closed 7 years ago

particleist commented 7 years ago

AFAICT at the moment, RapidSim assumes that each property saved in the HistWriter should have both a true and smeared value. This is true for kinematics but not in general. For example

-- For impact parameters you want to also save the sigma of the IP, to be able to form significances. But this sigma has no "smeared" meaning.

-- If we eventually want to add PID information, this would be a purely "smeared" quantity with no "true" component.

It seems to me that it would be good to generalize the HistWriter to be able to deal with these things. I suspect this might also mean generalizing the syntax of the configuration files. Thoughts?

gcowan commented 7 years ago

This was my first thought after I tried the new code and saw that there was a TRUE version of sigmaIP. I'm sure we can generalise to deal with these cases (but I won't be able to do anything before next week).

dcraik commented 7 years ago

This should be a fairly simple fix. We already pass separate RapidParam objects for the true and smeared quantities to RapidHistWriter and, for parameters defined using the param keyword, the user can choose to only have one or the other.

The issue is with loading the default parameters, which are defined using the paramsStable, paramsDecaying, paramsTwoBody and paramsThreeBody keywords. For convenience, I set this to automatically set up both true and smeared values.

The offending code is in RapidConfig::setupDefaultParams

I think the simplest solution is to add a couple of methods to RapidParam canBeSmeared and canBeTrue that would return a bool based on the value of ParamType and check those in setupDefaultParams. Then we can define this once for each type of parameter and the user doesn't have to do anything extra.

particleist commented 7 years ago

Makes sense to me

gcowan commented 7 years ago

I believe I have dealt with this issue using the suggestion from @dcraik. Please see 7b6ccc3a64ccb2ee3f6409f802007e5fab2f7ee7. I have merged the impactparameters branch with master. While I will close this issue, #16 still remains to be completed.