Skip to content
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

cobaya-cosmo-generator doesn't produce a valid yaml file for sampling. #164

Open
appetrosyan opened this issue Apr 13, 2021 · 2 comments
Open

Comments

@appetrosyan
Copy link
Collaborator

The cobaya-cosmo-generator does not warn the user and doesn't check the file for inconsistencies. Namely it still allows the user to output, even though no likelihood is specified or selected. Polychord suffers the most, because no default settings are provided as an example, and the end user might not know how to adjust the parameters, or what parameter choices are valid or not. I believe that @lukashergt 's experience may prove valuable here, in designing a set of sane defaults other than

sampler: 
  polychord: {}
@lukashergt
Copy link
Contributor

Hi Aleksandr,

the details of the defaults are all listed in Cobaya's readthedocs. I think the defaults are all sensible.

Are you suggesting to copy them over into the cosmo generator? All of them or just a subset?
I think all of them would be too much, but I agree that for a first time user it might be helpful to have the two major tuning parameters nlive=25d and num_repeats=2d listed explicitly.

Cheers,
Lukas

@appetrosyan
Copy link
Collaborator Author

appetrosyan commented Apr 13, 2021

@lukashergt

I think the defaults are all sensible.

that is true. Cobaya-Cosmo-generator should at least want the end user if their config is not sensible, (e.g. because they haven’t chosen a likelihood). Some general sanity checks would be useful, and help guide new users.

All of them or just a subset?

the crucial subset. I think there should be a combo box that has “low/medium/high” for the number of live points, and the number of repeats sensible for the run. I defer to your judgement which if any should be included. With the #115 merged, some accommodations for PolyChord’s new features will be needed anyway, and an explicit use_supernest clause should be there at a minimum.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants