Skip to content
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

Modularization of visulization routines #49

Open
BBallnus opened this issue Mar 2, 2017 · 6 comments
Open

Modularization of visulization routines #49

BBallnus opened this issue Mar 2, 2017 · 6 comments
Assignees

Comments

@BBallnus
Copy link
Contributor

BBallnus commented Mar 2, 2017

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.

@paulstapor
Copy link
Collaborator

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.

@dweindl
Copy link
Member

dweindl commented Mar 2, 2017

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.

@JanHasenauer
Copy link
Member

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).

@paulstapor
Copy link
Collaborator

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. ;)

@JanHasenauer
Copy link
Member

Doesn't 'options.mode' provide exactly this property for most functions?

@paulstapor
Copy link
Collaborator

Yes, it basically does. I think one might maybe want to split this up in a finer way than ('visual', 'text', and 'silent')...

@paulstapor paulstapor self-assigned this Jun 7, 2017
@paulstapor paulstapor added this to the CleanUp + some new Feature (v1.0.1) milestone Sep 18, 2017
@paulstapor paulstapor modified the milestones: CleanUp + some new Feature (v1.0.1), Restructure figure generation and plotting routines Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants