-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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! |
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. |
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.
The text was updated successfully, but these errors were encountered: