Closed ggalloni closed 2 months ago
I think it depends how much we want to tidy up the parameter dependence. I think this sets all the same parameters for all the components? (so e.g. the EE likelihood still depends on the fixed-default T calibration param; but more importantly, also probably by default sampling a_kSZ that it is actually unused)
Btw you can inherit parameters/yaml, so e.g. do not need to duplicate most of the yaml content - can have once in base class and then just define "defaults: polarizations: " etc as needed in derived classes (either in yaml or as inherited class attributes).
Can also use imports in yamls, e.g. see the NPIPE likelihoods in cobaya (params: !defaults ...)
Attention: Patch coverage is 96.47059%
with 3 lines
in your changes missing coverage. Please review.
Project coverage is 85.33%. Comparing base (
3e669e7
) to head (3c58c01
).
Files | Patch % | Lines |
---|---|---|
mflike/mflike.py | 91.66% | 2 Missing :warning: |
mflike/foreground.py | 98.27% | 1 Missing :warning: |
I fixed the calibration part, so, for instance, EE doesn't need calT to be there, not even fixed. I did this after your suggestion just by modifying the yaml
s. However, doing the same for the foreground params is far more complex.
The issue is the initialization step, where Foreground
doesn't know anything about MFLike
, or, at least, I could not make them communicate on that step (after that it can be done). I guess this is what you meant in #3 by "dynamically vary the nuisance parameters", am I right?
The only thing that worked is the workaround I'm pushing after cc27f0f.
Essentially, Foreground and MFLike have all the fg parameters, but each mode-specific likelihood has a supported_params
attribute. Then, I force the unsupported params to be fixed to some default value (I am using the ones from the test, but ideally these would be the best-fits of some run I guess).
I know it is not much different than before, but at least this forcefully avoids unsupported params being sampled...
Do you know a way to make components communicate at the initialization step somehow? Or maybe re-trigger some part of the initialization part after that (assignment of parameters, adding a drop tag to the unsupported ones, something like that)?
See comment here https://github.com/simonsobs/SOLikeT/issues/183
Extending this, my attempt to make params match dynamically: https://github.com/simonsobs/LAT_MFLike/pull/89. It does require specifying "requested_cls" to the foreground model consistently, but should at least raise an error if it is inconsistent. Or can use TTForeground etc. classes.
I merged #89 into this PR since I don't have write permissions on the other side.
Then, I added TT+EE, TT+TE, and TE+EE keeping requested_cls
on the yaml
s.
Looks good to me!
Draft PR for single-mode MFLikes.
This is essentially doing what @xgarrido proposed in #3. Is there something else to do for this?