-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft single-mode MFLikes #88
Conversation
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 ...) |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## restructure #88 +/- ##
===============================================
+ Coverage 83.93% 85.33% +1.40%
===============================================
Files 3 3
Lines 417 457 +40
===============================================
+ Hits 350 390 +40
Misses 67 67
|
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 The issue is the initialization step, where The only thing that worked is the workaround I'm pushing after cc27f0f. 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 simonsobs/SOLikeT#183 |
Extending this, my attempt to make params match dynamically: #89. |
I merged #89 into this PR since I don't have write permissions on the other side. |
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?