Modularization of visulization routines
Currently, the routines are fairly cluttered and non-modularized. E.g. plotParameterUncertainty could be splitted up into modules for '1D', '2D' for optimization, profile and sampling results. This would also reduce redundancies with plotPropertyUncertainty, since it would use the same modules.
Good idea. I'll have to have a closer look, but plot___Uncertainty are fairly important routines with ~800 lines of codes and many long if-else things. Especially, there's a part which can be used for Profiles and Sampling (makes sense to stay there) and another part is currently only used for sampling (could be a file of its own). Splitting this up would make things more readable, since debugging is not easy at the moment. Anyway, since this is a bigger thing, it would be good to do this maybe on a branch of its own.
Yes, that should be split up. The 1D and 2D separation is straightforward.
Further restructuring would be helpful, but I would not consider it a priority right now.
Yes, this can in principle be split up. About the reduction of redundance im however not sure. The field names in the parameters and properties struct are for good reasons very different. To reuse the code, they would have to be reduced in a first step which generates new code which is currently not required. Furthermore, one has to replicate the logic in which case what is plotted (beginning of the file) in the 1D and 2D file. Before splitting it up, I think it would be good to check how much in can really be reduced.
Similar topic: I have a draft for an dim > 2 visualization based on parallel coordinates lying around. This would than also have to go in a separate file (which is obviously possible).
Hmm... generally, one could think of an option for visualization, what should be plotted, like a "plotting verbosity", because for some problems, there's 20 windows popping up, but in some cases, having a detailed visualization of results (like diagnosis of optimization time, like profile paths, like density plots for samples or for progress of optimization, which currently can not be plotted at all, but whichc would be straight forward to include) can be very helpful - and looks cool. ;)
Doesn't 'options.mode' provide exactly this property for most functions?
Yes, it basically does. I think one might maybe want to split this up in a finer way than ('visual', 'text', and 'silent')...