add new different and less brutal whitening options #93
Conversation
…ow by other parts of msnoise as default is still 'brutal'
|
looks really interesting ! thanks ! |
| @@ -56,6 +56,8 @@ class TFilter(HasTraits): | |||
| mwcs_wlen = Float | |||
| mwcs_step = Float | |||
| used = CBool | |||
| whitening_method = Str | |||
| # XXX do we have to add whitening_method to View?? | |||
There was a problem hiding this comment.
no, those views were for the TraitsUI, I think
|
We'll try this PR in a live and fresh test setup now.. |
|
OK, this PR works for us when doing a new MSNoise project from scratch. The new whitening options lack descriptions, maybe @RensHofman can post them here so we can include them. Also names for those whitening methods should be checked, they could be a bit more intuitive/descriptive, I guess. Also, some of these new methods might have some additional parameters that probably should also be in the filter table then.. Also.. @ThomasLecocq, how to handle old MSNoise installations that lack this |
|
@megies that could be an option... but for most users, as msnoise has a ~yearly release, they'd just I have to say, I like the idea of the whiten-param-in-filter for benchmarking... but there are so many params that could/should be benchmarked that I actually thought of a more general solution of tree-based parametrisation of msnoise, that would allow for changing the duration of each window, the overlap, the stakc method, etc. etc. etc. then the dtt parameters and final dvv estimation... all this with proper bookkeeping... |
|
@rantanplan77 could also input on this as we already discussed benchmarking together |
I wouldn't worry to much about sqlite.. I guess you have a big warning sign that it should only be used for testing purposes?
Yeah.. I agree, many parameters from the general config could be moved to what currently is filter settings.. |
We already had the remark of "why is mwcs filter definition in the filter settings", indeed, some want to cross-correlate broadband (could be a bad idea) and then check phase shifts in smaller bands... |
I also think that this is the way to go. We should move as many parameters as possible to the filters and name it scenarios instead of filters. We could also include these options for each scenario:
but this would mean moving the filter-loop outwards. This would therefore lead to longer runtimes. But only then I think it offers true benchmarking of what works best for a specific datasets. There should also be a fallback in case of opening an old database with a new version, that uses the parameters from the config table if the new fields are not in the filter/scenario table. |
|
and btw I like the new whitening options. I think the names are understandable, ideally this would be documented with plots of the spectrum after each option. |
|
I admit this would be useful for testing/research purposes, but I don't think a single "scenarios" table is the way to go. The reason for this is that the processing steps are separated and you could use some preprocessing parameters, then 2 different filters, each with two different whitening schemes, each with 2 different stacking method, each with two different ref start/end dates, each with 2 different mwcs parameters, each with different dt/t time lags and parameters... This tree of possibility requires the benchmarking logic to be quite more complicated than just moving all elements in "scenarios"... |
|
...yeah.. i agree, a processing scenario would probably be better resembled by a "filter chain" (a filter being just about any single processing step.. filters, whitening, etc..) |
|
actually this was the idea used in Christoph's MIIC: ftp://ftp.gfz-potsdam.de/home/st/chris/MIIC_Science_Report_2013/MIIC_Science_report.pdf using |
|
I see, this tree/chain structure seems logical with this many options to choose. What about using such a tree structure to create the scenario table under the hood? This would still make it possible to deactivate some scenarios rather than using all scenarios (some of which maybe don't make sense to calculate). |
Work in progress.. we'll also need to make whitening a config option to select what whitening method to use..