Random start points option for profiled POIs #713

kmohrman · 2021-12-14T15:26:22Z

This PR adds an option --pointsRandProf to MultiDimFit.

The purpose of this option is to try to avoid finding and getting stuck in the wrong minima, as discussed in these slides.
If the option takes as input the number of random starting points to try for the profiled POIs in the n==1 case of the doGrid() function. If the option can be disabled by either not specifying the option, or by specifying 0 for the number of points.
This technical details of this approach are probably not implemented in an optimal way, so I'd be very happy to improve the implementation based on any suggestions and corrections that the combine experts would have.

Thank you!

amarini · 2021-12-14T15:37:47Z

I start running some test. The automatic ones run w/o this option on, but I think it is still a useful thing to assess.

hcombbot · 2021-12-14T16:16:24Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/3355626

adewit

Thanks for the PR - a few comments to start with. I'm sure others also have comments (e.g. I think there was a suggestion to move this algorithm to a separate class that is simply called in MultiDimFit, rather than it being embedded in MDF as it is now).

adewit · 2022-01-10T14:16:39Z

src/MultiDimFit.cc

        unsigned int points = pointsPerPoi.size() == 0 ? points_ : pointsPerPoi[0];

+        // Set seed for random points
+        srand(1);


Not sure right now if this could have other knock-on effects, but perhaps it would be better to do this only if pointsRandProf > 1 just to be safe

adewit · 2022-01-10T14:25:29Z

src/MultiDimFit.cc

@@ -665,42 +680,148 @@ void MultiDimFit::doGrid(RooWorkspace *w, RooAbsReal &nll)
          }

            //if (verbose > 1) std::cout << "Point " << i << "/" << points << " " << poiVars_[0]->GetName() << " = " << x << std::endl;
-             std::cout << "Point " << i << "/" << points << " " << poiVars_[0]->GetName() << " = " << x << std::endl;
+            std::cout << "Point " << i << "/" << points << " " << poiVars_[0]->GetName() << " = " << x << std::endl;
+            *params = snap;


From here to L788 or so I think this should also be wrapped in an if (pointsRandProf > 1) statement, to avoid this being invoked when the option is not explicitly called.

Here I think it would also good to print a warning / log message to state that this option is active (hopefully avoids people playing with random options and being surprised the fit is taking much longer than before)

There is a certain caveat to this suggestion. In our current implementation, the default behavior (i.e. just using the default starting point) is incorporated within the random starting point code block. If one wants to retrieve this behavior, one can either choose to set pointsRandProf to 0 or just entirely omit the option while running combine MultiDimFit. The reason why we chose to have the implementation set up this way is to avoid a lot of code repetition. In order to make sure that the users do not get confused about this, we have added some comment blocks in MultiDimFit method stating what I just explained above. Also, there are some printout code blocks that tell the user when pointsRandProf is set to a non-zero value (and also when the option is omitted). Let us know what you think about this approach.

adewit · 2022-01-10T14:31:17Z

src/MultiDimFit.cc

+            std::vector<float> nll_at_alt_start_pts;
+
+            // Get vector of points to try
+            float prof_start_pt_range_max = 20.0; // Is this what we want?


For a generic version of this algorithm, I think you'd want to potentially have a different range for each of the POIs, maybe the range can be read from the ws for each POI? (or the range set by --setParameterRanges)

adewit · 2022-01-10T14:32:42Z

src/MultiDimFit.cc

+                if (verbose > 1) std::cout << "\n\tStart pt idx: " << start_pt_idx << std::endl;
+                for (unsigned int var_idx=0; var_idx<specifiedVars_.size(); var_idx++){
+                    if (verbose > 1) std::cout << "\t\tThe var name: " << specifiedVars_[var_idx]->GetName() << std::endl;
+                    if (strcmp(specifiedVars_[var_idx]->GetName(),"r")==0) {


Should this be skipped in general?

This block of skipping "r" has been removed. We agreed that there is no need to skip this in general.

adewit · 2022-01-10T14:33:49Z

src/MultiDimFit.cc

-		for(unsigned int j=0; j<specifiedFuncNames_.size(); j++){
-			specifiedFuncVals_[j]=specifiedFunc_[j]->getVal();
-		}
+                for(unsigned int j=0; j<specifiedNuis_.size(); j++){


Restore original spacing?

adewit · 2022-01-10T14:33:58Z

src/MultiDimFit.cc

-		for(unsigned int j=0; j<specifiedCatNames_.size(); j++){
-			specifiedCatVals_[j]=specifiedCat_[j]->getIndex();
-		}
+                for(unsigned int j=0; j<specifiedNuis_.size(); j++){


Restore original spacing?

adewit · 2022-01-10T14:35:51Z

src/MultiDimFit.cc

+                    Combine::commitPoint(true, /*quantile=*/0);
+                    continue;
+                }
+                ok = fastScan_ || (hasMaxDeltaNLLForProf_ && (nll.getVal() - nll0) > maxDeltaNLLForProf_) || utils::countFloating(*params)==0 ?


Just from looking at this I think this instance of ok is not used at all as L803 is always invoked afterwards, thus no need to set it here?

ajgilbert · 2022-01-11T08:46:06Z

As mentioned above, if it's not too difficult, it could be better to put this code into a new class in a separate .cc file, which could then be called by MultiDimFit when the extra command line option is added. MultiDimFit is already due a clean up in the near future, and I think this would make things easier to maintain.

kmohrman · 2022-01-18T21:38:49Z

Thank you @adewit and @ajgilbert for the reviews. We're working on addressing the comments, and will get back to you as soon as possible. However, we're a bit swamped with work on other areas of our analysis right now, so it might take us a few weeks. But if this timeframe would present an issue for eventually moving forward with merging this PR (e.g. if other large changes to this section of the code are expected soon), please let us know and we attempt to get it done more quickly. Thanks!

ajgilbert · 2022-01-19T09:55:54Z

Hi @kmohrman, no problem from our side I think - we're usually pretty slow getting our own developments in. Will let you know if/when a big refactor of MultiDimFit is imminent.

Update standalone to 8.2.0

kmohrman · 2022-07-05T04:04:46Z

Hi, thanks again for the reviews of this PR. Sorry for our long silence, things have been very busy with other parts of our analysis. We're now pushing through the final stages, and have run into a few things we wanted to add to this PR in order to make this random starting point method work better for our analysis.

Anyway, just wanted to give a heads up that we'll be pushing a few changes to this branch, and wanted to say sorry in advance for the noise!

…d start points

hcombbot · 2022-07-05T04:40:22Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/4184308

hcombbot · 2022-07-05T05:39:26Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/4184421

hcombbot · 2022-07-06T03:39:31Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/4189204

hcombbot · 2022-07-06T20:48:48Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/4193434

hcombbot · 2022-07-08T19:43:55Z

Pull Request Test.
Summary
========
Running options:
* MODE : cmssw
* COMBINE_TAG : 102x
* COMBINE_REPO : cms-analysis
* COMBINE_MERGE : kmohrman/rand-start-pts-v2
* GITHUB_PR : 713

Ratio to reference values:
--------
| comb_2019_hbb_boosted_standalone | comb_2019_hgg | comb_2019_hmm | comb_2019_htt | comb_2019_hww | comb_2019_tth_hbb | comb_2019_tth_hgg | comb_2019_tth_multilepton | comb_2019_vh_htt | comb_2019_vhbb | comb_2019_vhbb2017 |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 | 1.00 |

You can find more detail at https://gitlab.cern.ch/cms-hcg/performances/ci/-/pipelines/4203623

Include default for "noData" option (avoid complaint when running with --t2w)

abasnet97 · 2023-06-10T07:58:37Z

Hi @ajgilbert, my apologies for a delayed response to this. At this point, I have resolved the merge conflicts that arose after we switched the target branch to main. Fortunately, it was not as tedious as I had expected it to be. I was also wondering if you have had a chance to review the random starting point class implementation and/or if you have any comments on that?

Hi @abasnet97, sorry for the delay. The first issue is that since you started the developments, we have switched to a new default branch of combine (main) and there a quite a few updates since you branched off. I changed the target branch for this PR, and now there are some conflicts - can you check these? In the meantime I will try and understand the proposed changes

abasnet97 · 2023-07-28T13:47:29Z

Hi @ajgilbert, sorry for the noise. I was wondering what the status of the review is. Let me know if you have had a chance to work on this and if you have any comments.

nucleosynthesis · 2023-07-28T14:17:30Z

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

abasnet97 · 2023-07-28T14:26:34Z

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

@nucleosynthesis, looks like I am using CMSSW_10_2_13.

abasnet97 · 2023-08-15T14:12:30Z

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

Hi @nucleosynthesis , I wanted to follow-up to see if there has been any development on this front. Were there some issues with cmssw release mismatch?

nucleosynthesis · 2023-11-03T14:10:41Z

Hi Again,

apologies for the delay in responding. @abasnet97 - can you try to compile under CMSSW_11_3_4 and see if there is a way to fix the errors? Let us know if you get stuck

All the best,
Nick

…code cleaning

abasnet97 · 2024-01-08T01:49:11Z

Hi Again,

apologies for the delay in responding. @abasnet97 - can you try to compile under CMSSW_11_3_4 and see if there is a way to fix the errors? Let us know if you get stuck

All the best, Nick

Hi @nucleosynthesis, after fixing some errors, I can now compile the repo using CMSSW_11_3_4. I have also merged all recent changes from main to this branch.

abasnet97 · 2024-01-16T17:12:55Z

Just adding @anigamova and @kcormi here to keep CAT-stats in the loop.

nucleosynthesis · 2024-01-16T17:45:23Z

I think this looks ok, but I'd really like to test it. @abasnet97 - can you provide an example command that will work with one of our tutorial datacards?

For example, if you try the following,

cd data/tutorials/CAT23001
text2workspace.py multi-signal-datacard.txt -P HiggsAnalysis.CombinedLimit.PhysicsModel:floatingXSHiggs --PO modes=ggH,qqH -o  multi-signal-datacard.root --mass 125
combine multi-signal-datacard.root --pointsRandProf=20  --parameters r_ggH -v 9 -M MultiDimFit --floatOtherPOI=1

When I try the above, I don't see the multiple fits being performed that I would have expected - can you try and see if there's edits to the command line that would make it work?

Nick

abasnet97 · 2024-01-16T18:33:14Z

Hi Nick, your combine command looks fine for testing, but just wanted to add that I have been explicitly passing --algo grid option. The random start point functionality is used only inside the grid scan portion. With the workspace generated from your t2w command, I am seeing a few warning messages that I had not noticed with a different workspace I was using for testing and debugging. Let me know what you see.

nucleosynthesis · 2024-01-16T19:11:42Z

Hi @abasnet97 ,

Right of course, I missed that the grid algo is needed since this is only intended for scans (though I wonder why this wouldn't also be useful for the global fit part to make sure the correct global minimum is found)

Anyway I'll try with the --grid added,

Thanks
Nick

kmohrman · 2024-01-16T19:32:45Z

Hi @abasnet97 ,

Right of course, I missed that the grid algo is needed since this is only intended for scans (though I wonder why this wouldn't also be useful for the global fit part to make sure the correct global minimum is found)

Anyway I'll try with the --grid added,

Thanks Nick

Hi Nick,
I might be missing something, but I think that random starting points for the global fit part can be effectively achieved via the already existing --setParameters option. Thanks! - Kelci

nucleosynthesis · 2024-01-22T14:11:33Z

Ok, adding the --algo grid option seems to work. I noticed (again using the tutorial card) that there are many cases where the parameter values go to regions where the pdfs no longer make sense. I tried setting the range of the parameters to stop this, but it seems the random starting values don't respect these ranges - is that intended, did you check that setting the range of the parameters is respected by the random value setting?

abasnet97 · 2024-01-22T15:35:27Z

Hi @nucleosynthesis, a quick question. When you say:

I tried setting the range of the parameters to stop this, but it seems the random starting values don't respect these ranges

What command line option are you talking about?

nucleosynthesis · 2024-01-22T15:37:20Z

Here is the command I tried, where I was seeing the errors

combine multi-signal-datacard.root --parameters r_ggH -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandPro=2

(note, as per my earlier comment, you can create this workspace via

cd data/tutorials/CAT23001

text2workspace.py multi-signal-datacard.txt -P HiggsAnalysis.CombinedLimit.PhysicsModel:floatingXSHiggs --PO modes=ggH,qqH -o  multi-signal-datacard.root --mass 125

)

abasnet97 · 2024-01-22T15:39:24Z

Here is the command I tried, where I was seeing the errors

combine multi-signal-datacard.root --parameters r_ggH -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandPro=2

(note, as per my earlier comment, you can create this workspace via
cd data/tutorials/CAT23001

text2workspace.py multi-signal-datacard.txt -P HiggsAnalysis.CombinedLimit.PhysicsModel:floatingXSHiggs --PO modes=ggH,qqH -o  multi-signal-datacard.root --mass 125
)

Ok let me try this quick.

abasnet97 · 2024-01-22T17:26:09Z

Hi @nucleosynthesis, so I tested your command. And yes, I did see those warnings.
However, I want to mention that there also exists a command line option called --randPointsRanges, which allows one to set the range from which the random start points are chosen for the profiled parameters. By default, this is set to -20,20. So when I tried something like:

combine multi-signal-datacard.root --parameters r_ggH -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandProf=2 --randPointsRanges r_ggH=-1,1:r_qqH=-1,1

I saw significantly less number of warnings. Now, what range to pick for these random start points are of course specific to each parameters, so my dummy values might not have been the best range.

nucleosynthesis · 2024-01-23T14:34:53Z

Thanks for checking - I think its not great to have a separate option to set these ranges, nor to use -20,20 as the default (what if the POI was a mass variable for example).

Given most physics model define sensible default ranges, I would remove the --randPointsRanges and simply use the existing ranges on each parameter (this can be obtained using the RooRealVar::getMin() and RooRealVar::getMax() methods. That way, if the user specifies a new range with --setParameterRanges, the ranges will be taken from that - I think this behaviour would be much better.

kmohrman · 2024-01-23T15:05:52Z

Thanks for checking - I think its not great to have a separate option to set these ranges, nor to use -20,20 as the default (what if the POI was a mass variable for example).

Given most physics model define sensible default ranges, I would remove the --randPointsRanges and simply use the existing ranges on each parameter (this can be obtained using the RooRealVar::getMin() and RooRealVar::getMax() methods. That way, if the user specifies a new range with --setParameterRanges, the ranges will be taken from that - I think this behaviour would be much better.

Hi @nucleosynthesis, thank you for the comments. I agree that your suggestion would be a possibility. However, in some cases (e.g. TOP-22-006, which was the use case this PR was developed for), we believe it is useful to have a separate option for specifying the ranges from which to draw the random points. I think the following reasons contribute to the usefulness of the --randPointsRanges option:

It can be very computationally expensive to create the work space (up to ~7hr for the case of TOP-22-006) so it makes sense to define in the model very large ranges for the parameters. E.g. for TOP-22-006 we defined something like -200 to 200 for all 26 POIs (which is much larger than needed for all POIs). This is because ranges in the model that turn out to be too large are not detrimental, whereas ranges that are too small may result in needing to remake the workspace. Thus the ranges we define in the model are generally much larger than the ranges we would like the random starting points to be drawn from.
Since the ranges for the POIs in these EFT fits are not known ahead of time (and it is not convenient or efficient to remake the workspace every time one would like to adjust the ranges explored for starting points for the profiled POIs), it is very useful to have the flexibility to be able to set the ranges of the profiled POIs at the time of the fit.
Another use case for the dedicated --randPointsRanges is the ability to explore a certain subset of ranges of starting points. E.g. if one happens to know something about how the topology of the space (e.g. from a higher dimensional scan) and one wishes to explore a scenario around a particular minima, it may be useful to be able to restrict the range of the random starting points for that POI (or subset of PIOs) to a particular range one has in mind.

For these reasons, we would prefer to keep the --randPointsRanges option in place, though we would of course be very interested to hear your thoughts on the above comments as well.

Thanks!

nucleosynthesis · 2024-01-23T15:13:38Z

The point is that the ranges for the parameters are already modifiable in the command line using --setParameterRanges. I don't see an argument for having another option that clashes with this one and is only used specifically to set the allowed ranges for the random initialisation since either

the parameter is set to some value within the range (which then will cause an issue if the range is larger than the one currently set for the parameter) or
the parameter range is adjusted by the --randPointsRanges which overrides the range set by the user,

either of the above will just cause confusion and moreover will spoil setting the ranges used in the fit for the parameter. Unless there is a specific reason to have a different range for the random starting point vs that allowed in the fit, I really think we need to avoid introducing this extra option.

At the very least, if the user doesn't specify --randPointsRanges, the parameter ranges that already exist (and are set by --setParameterRanges should be used to avoid this issue that I was seeing in the tutorial cards.

Finally, if we really need this extra option, can we change it to something like --setParameterRandomInitialValueRages or something to make it clearer what is being done?

kmohrman · 2024-01-24T03:45:20Z

After thinking about and discussing your points, we agree that a clash between --setParameterRanges and --randPointsRanges is undesirable and could cause confusion to the users. So we agree that the behavior should aim to avoid such clashes. However, we still feel that having a --randPointsRanges option is useful in cases where the user would like to explore certain subsets of ranges for starting point values. E.g. a user may wish to explore what happens when starting points are chosen to be near some local minima, but the user might not want to restrict the POI to stay within that small range (i.e. the user may wish to allow the POI to float to a different minima if it is able to, even if that minima is outside of the range specified in --randPointsRanges).

To this end, we would propose the following:

We would like to keep the --randPointsRanges option
But we would set up the behavior such that --randPointsRanges would never override the max and min values already in place for the POI (which are set by either --setParameterRanges and/or specified in the physics model)
We can add a comment to the help string for --randPointsRanges that would mention that this range should be equal to or smaller than the max and min values already in place for the POIs (and that if a random starting point larger/smaller than these max/min is requested, it will not be respected)

We are wondering if you would have thoughts on this proposal?

nucleosynthesis · 2024-01-24T11:24:43Z

This sounds ok to me, but please consider changing the name of the option to something more informative than --randPointsRanges (i.e like something I suggested previously).

kmohrman · 2024-01-24T13:42:38Z

That name (--setParameterRandomInitialValueRages) sounds fine to us. Thank you for all of the feedback on this option and its functionality. We will proceed with making the changes discussed above.

…nges

abasnet97 · 2024-01-24T20:14:34Z

Hi @nucleosynthesis, I have implemented the changes that @kmohrman described in this comment. And like you suggested, I have also edited the name of the CLI option to be a bit less confusing.

Remove unecessary COUT and add logger command

kmohrman added 3 commits December 14, 2021 10:11

Add ability to try rand start pts for prof POIs

45fc551

Option for specifying number of random start points

3326195

If using pointsRandProf_, turn on saveInactivePOI_

cf60fa4

amarini added the safe to test label Dec 14, 2021

adewit reviewed Jan 10, 2022

View reviewed changes

nucleosynthesis added 5 commits May 31, 2022 16:22

Update nonstandard.md

4c10a7c

Update nonstandard.md

018fe0e

Update commonstatsmethods.md

eff8006

Update index.md

032dc17

Update standalone to 8.2.0

Update commonstatsmethods.md

6ed9c9a

Do not save nll if fit fails, also add ability to pass ranges for ran…

8feba2d

…d start points

Add option for skipping default start point

2f19e02

Save each point if best nll so far to avoid rerunning fit at end

e1f2b66

Pass rand seed for rand start points

3177041

Small cleanups

2c1e05b

nucleosynthesis added 4 commits July 21, 2022 17:53

Update systematicsAnalyzer.py

4657a55

Include default for "noData" option (avoid complaint when running with --t2w)

Include ATLAS ref for Impacts

a22bb47

Update commonstatsmethods.md

a17df94

Update commonstatsmethods.md

42c3c82

fixed merge conflicts

98c9983

abasnet97 added 2 commits January 2, 2024 16:49

Making changes to be able to compile with CMSSW_11_X plus some other …

0e06eb3

…code cleaning

resolved merge conflicts after merging changes from main

1932f09

edited behavior of random starting point range to not override POI ra…

2561169

…nges

Update MultiDimFit.cc

25db367

Remove unecessary COUT and add logger command

nucleosynthesis merged commit 887f56d into cms-analysis:main Jan 25, 2024
2 of 6 checks passed

Random start points option for profiled POIs #713

Random start points option for profiled POIs #713

Conversation

kmohrman commented Dec 14, 2021

amarini commented Dec 14, 2021

hcombbot commented Dec 14, 2021

adewit left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ajgilbert commented Jan 11, 2022

kmohrman commented Jan 18, 2022

ajgilbert commented Jan 19, 2022

kmohrman commented Jul 5, 2022

hcombbot commented Jul 5, 2022

hcombbot commented Jul 5, 2022

hcombbot commented Jul 6, 2022

hcombbot commented Jul 6, 2022

hcombbot commented Jul 8, 2022

abasnet97 commented Jun 10, 2023

abasnet97 commented Jul 28, 2023

nucleosynthesis commented Jul 28, 2023

abasnet97 commented Jul 28, 2023

abasnet97 commented Aug 15, 2023

nucleosynthesis commented Nov 3, 2023

abasnet97 commented Jan 8, 2024

abasnet97 commented Jan 16, 2024

nucleosynthesis commented Jan 16, 2024

abasnet97 commented Jan 16, 2024

nucleosynthesis commented Jan 16, 2024

kmohrman commented Jan 16, 2024

nucleosynthesis commented Jan 22, 2024

abasnet97 commented Jan 22, 2024

nucleosynthesis commented Jan 22, 2024 • edited

abasnet97 commented Jan 22, 2024

abasnet97 commented Jan 22, 2024

nucleosynthesis commented Jan 23, 2024

kmohrman commented Jan 23, 2024

nucleosynthesis commented Jan 23, 2024 • edited

kmohrman commented Jan 24, 2024

nucleosynthesis commented Jan 24, 2024

kmohrman commented Jan 24, 2024

abasnet97 commented Jan 24, 2024 • edited

nucleosynthesis commented Jan 22, 2024 •

edited

nucleosynthesis commented Jan 23, 2024 •

edited

abasnet97 commented Jan 24, 2024 •

edited