Kyle Conroy

This will require some (more) thought: `b['fit_parameters'].expand_value()` (which is available to the user, but also is used internally to determine what parameters to pass to the optimizer) matches all visible...

note that this is still a bug, but is probably not a common scenario. To reproduce: ``` import phoebe b=phoebe.default_binary() b.flip_constraint('mass@primary', solve_for='period') # setting the hierarchy still does work at...

@amiszuda's suggestion of changing the mesh resolution (through the `ntriangles` parameter on the star with the spot) should help... but I also don't think the mesh needs to be regenerated...

I can't seem to reproduce this, at least not in a general case. My only guess is that maybe all the samples in the first iteration are outside the priors...

I also just updated the [emcee tutorial](http://phoebe-project.org/docs/2.3/tutorials/emcee) to show a case of using priors that does work on my end. In case this might be something with emcee versioning, can...

I haven't seen this before, so my guess would be that your MPI version/setup is more restrictive in which tags are valid than others. If you can somehow track that...

1.) In phoebe2 there are exposure/integration times per-dataset (see qualifier='exptime', context='dataset'). 2.) There are switches in the compute options per-dataset (feel free to do the same for the legacy compute...

@bpablo - see commit https://github.com/phoebe-project/phoebe2/commit/92db431389907628e9d74f75f60481cb0716e1ce for a fix to the visibility of fti_oversample As for RV datasets - I believe we (Andrej and I) talked about this and decided to...

I'm deferring exposure times via legacy wrapper for a future release. We'll consider this closed for 2.0 and revisit the rest later.

currently required from graham eclipse, which will not be reproduced in libphoebe, but we should keep around for now since its the only eclipse algorithm that can robustly handle WD-style...