Skip to content

MeqParmWishlist

Jump to bottom Edit New page
Gijs Molenaar edited this page Feb 12, 2014 · 3 revisions

Things I'd like to see in MeqParm:

  • A discussion on MeqParmConstraints.

  • MXM: Some answers can be found by carefully reading the MeqParm documentation. I realize the description is very brief though. Anyway, these comments are very useful for further development of the MeqParm + Tables.

  • OMS: I'd like to do iterative solutions as follows: first fit, e.g., a 1st degree polc (with a certain tilesize), then go back and "upgrade" it to a 3rd degree polc, and do another solution, using the existing {c00 c01 c10} coefficients as a starting point. What's the easiest way to do it? If I specify a 3rd-degree polc for init_funklet right now, MeqParm cheerfully overrides that with the 1st-degree polcs it finds in the database, and then proceeds to do another 1st-degree fit.

  • MXM: Use the shape field. This initializes the 'known' coefficients, and all the extra coefficients with 0.

  • OMS: I'd like to store extra information with a funklet. Specifically, the final chi-square value (which will be passed up from the solver), and also an arbitrary "category" string.

  • MXM: OK, I agree that 'goodness of fit' information should be stored. What is 'category'? We should come to a more or less final set of funklet information, but I am sure this will be evolving for some time.

  • OMS: Are the "Save" and "Converged" functions separated right now? I'd like them to be. For example, when fitting complicated phases, it is not uncommon to find the solver "locking" itself into a false local minimum. In this case converged is set to True, and the next tile starts at the same local minimum and is also likely to get stuck there. We're better off starting again from 0 (or whatever initial values) than from a false minimum. In principle, the solver can detect a false minimum by comparing chi-square with some specified threshold; in such a case I'd like it to tell MeqParm to save its solution, but not to use it for the next tile.

  • MXM: Use the use_previous flag. If false the funklet is not initialized from the previous solution. THere is also a flag that tells the parm to save even if not converged.

  • OMS: I'd like to be able to tell MeqParm to init itself with a certain "category" of funklet from the table. Example categories: "real" (for the actual value used in a simulation), "perturbed" (for a pre-generated perturbed value -- also important in simulations), "fitted", etc.

  • MXM: Why dont you make separate tables for that?

  • OMS: My experiences with phase solutions show that sometimes we just don't converge on the right phases (see above). I think this can be addressed if the following was easy to do via the parmdb interface:

  • Run phase solutions with some tilesize

  • Review the fitted funklets and sort them by chi-square

  • Throw out the high-chi-sq funklets, and replace them something else (e.g. the funklet from the next tile -- since we already know that starting from the previous tile didn't help, we may as well try the next tile as a starting point instead)

  • Run the solutions again

  • MXM: I guess this has more to do with a general ParmDB interface, with which it should be possible to fit, inspect, discard, etc...

  • OMS: for applying calibrators: say we run a solve on a calibrator source that is only observed part of the time. We now need to "transfer" these solutions into the time intervals in between. Again, we need some easy way to do this.

  • MXM: Agree.

Add a custom footer
Add a custom sidebar
Clone this wiki locally