Conversation
|
A consequence of the masked result is that code which uses the result no longer works, as expected. For example, autolens uses the following code to get the y coordinate of every subhalo: This now gives an error because certain The code raising the error is this: There is a similar issue where the result is None but when code which calls the Could we make it so that every masked sensitivity grid cell is given a
|
|
Done |
|
The |
|
So I think the issue is a I think as long as the |
|
Added. I guess the two options are we carry on mocking the same interface or we could consider if there's an elegant way to account for masking in downstream functions? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1061 +/- ##
==========================================
+ Coverage 80.60% 80.81% +0.21%
==========================================
Files 199 199
Lines 15305 15358 +53
==========================================
+ Hits 12336 12411 +75
+ Misses 2969 2947 -22
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
I did initially try to incorporate the mask downstream, but couldn't find an elegant solution and felt like it kept sending me back up to the original sensitivity mapping results. The problem was that these calculations often use the shape and structure of the sensitivity grid, which was not available in the |
|
The values coming from However, they come from the Just because we apply a mask and skip the fit, the perturb Basically, to produce 2D images of the sensitivity result for autolens, I need to know the x and y coordinates of where the sensitivity mapping of a dark matter subhalo took place (including cells which were bypassed via a mask). I don't think there is a general way I can do this (e.g. independent of how the sensitivity grid was set up) without calling: |
|
I could, for example, extract this information from some of the internal sensitivty mapping arrays, but if the parameter ordering were swapped by the user this calculation would no longer work correctly, so it needs to work on the model path. |
|
Could you not simply check whether a result is a MaskedJobResult and skip setting the associated values in that case? |
|
It looks as though these perturbed values are being respected for masked results def test_physical_centres_lists(masked_result, masked_sensitivity):
assert masked_result.perturbed_physical_centres_list_from("perturb.centre") == [
0.25,
0.25,
0.25,
0.25,
0.75,
0.75,
0.75,
0.75,
]When prior limits were updated for perturbed models this was not updating the underlying message for Uniform and LogGaussian priors causing the mean to be the same for every perturb model inspite of the priors differing. Was this the cause of the issue? |
|
The perturbed_physical_centres_list_from now takes values directly from the sensitivity map result. No need to specify 'perturb'. e.g. masked_result.perturbed_physical_centres_list_from("centre") |
Resolves #1058