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

Treatment of "failed" images #42

Open
j6626 opened this issue Apr 25, 2021 · 2 comments
Open

Treatment of "failed" images #42

j6626 opened this issue Apr 25, 2021 · 2 comments

Comments

@j6626
Copy link
Collaborator

j6626 commented Apr 25, 2021

Currently, DiskJockey will set the probability to zero for a model if RADMC3D fails to synthesize an image for some combination of parameters. However, at least some of this time, this happens for a (relatively) reasonable set of model parameters because the temperature blows up to very large values at very small radii, suggesting a ceiling ought to be imposed on the model temperature or a larger inner radius needs to be set so as not to be calculating temperatures at unreasonably small radii.

@iancze
Copy link
Owner

iancze commented Apr 25, 2021

If adjusting the default lnpriors does not provide fine-enough control, an alternative thing to try would be to add a user-defined prior (see also) checking for the temperature blow-ups across the RADMC input files.

The fact that we rely upon RADMC3D (or any radiative transfer suite, really) puts us at the mercy of the errors that that package throws, and effectively truncates the prior bounds to those parameter spaces that do not produce errors. Hopefully the error-producing regions are also unphysical spaces, but in situations like the one you describe, these could have an actual impact on the inferred posterior parameters. I'm not really sure what the solution would be here other than understanding the error space of RADMC3D better and implementing model parameterizations that do a better job of avoiding errors, especially for plausibly physical models in the line-emitting regions.

If you have a suggestion for limiting this via lnpriors, or reparameterizing this in the model definition, pull requests welcome!

@j6626
Copy link
Collaborator Author

j6626 commented Apr 25, 2021

It seems RADMC3D only calculates the partition function up to T=100000, so I think capping the temperature at that point would be ok. Trying to catch this through lnprior seems not to be the ideal route to go, since whether or not the temperature goes out of bounds is dependent on the grid setup (which is not a model parameter in the traditional sense), and because the model values in the regions actually traced by the data are not necessarily unphysical.

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