MultiDimFit: add option to change parameter ranges for grid points.

[riga]

Hi,

this PR adds an additional option to MultiDimFit to control the range of parameters for grid points independently from parameter ranges in the initial fit.

The use case is that I would like to scan a parameter in a range that does not include its expected value, say r from 5 to 10. Currently, the scan range is only configurable by setting --setParameterRanges which also affects the range used in the initial fit, leading to deltaNLL values being computed relative to a point other than r=1 (likely r=5).

With the new option, one could do

--algo grid --setParameterRanges r=-20,20 --setParameterRangesForGrid r=5,10 --gridPoints 6 --alignEdges 1

and

--algo grid --setParameterRanges r=-20,20 --setParameterRangesForGrid r=10,15 --gridPoints 6 --alignEdges 1

and end up with consistent deltaNLL and best fit values.

[adewit]

I don't think I fully understand when the use case would come about - is the idea that you want to stitch multiple such scans together, is it more that you want to have the option to scan additional points in a wider range away from the minimum after you do a first scan, or something else?

In the first two cases, saving the workspace at the best fit, then running the grid scan after loading the snapshot and skipping the initial fit will also give you consistent deltaNLL's wrt the best fit. As a bonus you save repeating the initial fit N times, which can be slow.

[riga]

is the idea that you want to stitch multiple such scans together, is it more that you want to have the option to scan additional points in a wider range away from the minimum after you do a first scan

Exactly that. For instance, if I perform an initial scan with 20 points from -10 to 10 (no snapshot involved so far) and then decide to increase the density at one of the crossings with dnll2 = 1 in a second scan and stitch them together, I need to make the second range somewhat too large just so that it would cover the expected best fit value.

Snapshots are probably the better option (also performance-wise), but wouldn't this require that the initial scan should have also been using the snapshot in the first place to get consistent deltaNLL's?

(I wasn't sure in the beginning if I should open a PR for that, but after seeing that --setParametersForGrid is already there, I thought I go with it ... )

[nucleosynthesis]

I think that the functionality is already there in the `--firstPoint` / `--lastPoint` options though that does require tuning the ranges such that the section being scanned is the desired parameter space.

…

On Fri, Aug 27, 2021 at 5:22 PM Marcel R. ***@***.***> wrote: is the idea that you want to stitch multiple such scans together, is it more that you want to have the option to scan additional points in a wider range away from the minimum after you do a first scan Exactly that. For instance, if I perform an initial scan with 20 points from -10 to 10 (no snapshot involved so far) and then decide to increase the density at one of the crossings with dnll2 = 1 in a second scan and stitch them together, I need to make the second range somewhat too large just so that it would cover the expected best fit value. Snapshots are probably the better option (also performance-wise), but wouldn't this require that the initial scan should have also been using the snapshot in the first place to get consistent deltaNLL's? (I wasn't sure in the beginning if I should open a PR for that, but after seeing that --setParametersForGrid is already there, I thought I go with it ... ) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#686 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMEVW7XE4OQK2EN4CLSYKTT663VXANCNFSM5C5H2HOA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[adewit]

Snapshots are probably the better option (also performance-wise), but wouldn't this require that the initial scan should have also been using the snapshot in the first place to get consistent deltaNLL's?

It's probably better, yes. Assuming that the initial configuration of the initial scan and the fit for the snapshot are identical you would most likely find the same minimum in both cases (you're relying on that with the implementation in this PR too, as you have to redo the initial fit every time. )

[riga]

It's probably better, yes. Assuming that the initial configuration of the initial scan and the fit for the snapshot are identical you would most likely find the same minimum in both cases (you're relying on that with the implementation in this PR too, as you have to redo the initial fit every time. )

Fully agree 👍

Before using snapshots, I usually set up grid scans for these cases like @nucleosynthesis suggested, but the need to update --gridPoints, the offset of either --firstPoint or --lastPoint as well as the initial parameter range to achieve the desired point density made me think that this additional option could be helpful, especially in 2D. E.g. to scan r within [10, 15] with a step size of 0.25, one would need to run

--algo grid --setParameterRanges r=0.75,15 --gridPoints 58 --alignEdges 1 --firstPoint 37 --lastPoint 57

which would simplify to

--algo grid --setParameterRanges r=-20,20 --setParameterRangesForGrid r=10,15 --gridPoints 21 --alignEdges 1

For 2D or higher, finding the correct --firstPoint / --lastPoint offset is actually not trivial. Here is an example.