Fix implementation of stellar mass and parallax about orbitize HOT 12 CLOSED

Ok, let's go with option 2 then! I'm thinking I'm just going to combine the PTMCMC and EnsembleMCMC samplers together into a single MCMC sampler for simplicity (I think they differ by like 3 lines of code).

from orbitize.

Let's close this when its implemented in MCMC.

from orbitize.

Realized I haven't done this yet in MCMC. It's actually not great to sample a fixed parameter in MCMC. Should I have code in the MCMC sampler to skip sampling these parameters, or should we handle fixed mass/parallax in the system class.

from orbitize.

I should have documented our plan for this immediately after our telecon, but I forgot! Oh well. I think the plan is (correct me if I'm wrong):

• merge the latest changes from master into the fix-mass-and-parallax branch.
• add a helper method in system.py that takes in the full list of parameters (floats & Prior objects) returns a list of just Prior objects.

Are you good to finish that up @semaphoreP?

from orbitize.

I don't know whether it's best to handle this in the system.py class or in the sampler.py class. But I can think about it, and go with which I think is better.

from orbitize.

Ok, sounds good! Right, I forgot that we had discussed where to put this helper function.

from orbitize.

Ok seems like there's two ways to go:

1. sampler.compute_model(params_arr) accepts either a full params_arr or a params_arr with len == number of non-fixed parameters (and it will fill in the rest of the fixed parameters), and a helper function to return a list of priors to sample. This has the benefit that a user can use sampler.compute_model() passing in only the variables they are fitting for, and don't have to worry about also passing in the variables that are fixed. It also abstracts away thinking about what parameters are missing so that only the system class bookkeeps it. The only con is that this will complexify system.py and make MCMC/OFTI inconsistent: MCMC results will only return sampled parameters whereas OFTI will return all parameters (unless we also change OFTI).

2. Handle fixed parameters in an sampler.PTMCMC which has the benefit that the changes will be localized and have to handle less general cases. The major con is that for MCMC users, the MCMC chains will be missing the fixed variables, so we need to do something (e.g., add them into the chains?) in order for the output to be easily passable back into system.compute_model() for doing things like plotting the orbits or analyzing them in other ways.

Thoughts?

from orbitize.

Would both options result in the MCMC output chain only containing sampled parameters, or did I miss something?

from orbitize.

In the second option, we could manually inject the fixed parameter as extra parameters in the chains after sampling is finished, but we would sample without them

from orbitize.

I think I like option two better, because this does seem like an MCMC-specific issue. We could have an MCMC base class that has two helper methods for adding and removing fixed variables from arrays.

from orbitize.

I also think Option 2 is better. If we're only talking about fixing system mass and parallax, then the Results.py plotting functions already has ways to use the fixed values in computing orbits. So for this case, all the downsides already have code to account for them, I think. Also, I don't think having Mtot or parallax missing from the chain when they are fixed is a bad thing at all---we wouldn't want to include fixed parameters in the corner plot, for example.

However, once it is implemented, it might be a good idea for me to clean up the plotting routines to use the helper functions. If we build more analysis routines then we can use the helper functions instead of trying to read from the System class.

In the future, if you want to allow the "main" orbital parameters to be fixed, then this could be more tricky. However, I don't really see a utility in fixing only "a" for instance. Even if there was somehow an independent measurement of a parameter that we were very certain about, we would likely just implement it as a very restrictive prior anyways.

from orbitize.

Addressed in PR #69.

from orbitize.