Displacement and Amplitude (DAS) score

[nicholasloveday]

Relevant papers are
https://journals.ametsoc.org/view/journals/wefo/24/5/2009waf2222247_1.xml
and
https://journals.ametsoc.org/view/journals/mwre/135/9/mwr3457.1.xml

[nikeethr]

Initial research

One of the earlier papers - laplacian: https://ieeexplore.ieee.org/document/1095851

This is generally in the category of filter banks: https://en.wikipedia.org/wiki/Filter_bank

Normally down/up sampling filters have a pre-filter specifically to prevent aliasing - as their goal is to preserve information rather than infer information, on the other hand kernel methods are often heuristically chosen and are more fuzzy in their feature finding. The advantage however, is that they are easier to derive and implement.

There are two parts to this score

• The pyramid filter-bank computation
• The score itself

Any bottlenecks would likely stem from the former. A implementation (TODO: reference) in python exists that currently computes both using scipy. It works, but is potentially outdated and needs review.

---

Brief note on performance

There are benefits to using more updated tools; spatial data especially is consistently gaining in quality both in terms of resolution and acquisition frequency due to advances in hardware and telecommunications, and designing systems to keep up with this is prudent.

Dependencies that can scale to these requirements are worth considering, especially if they are languages that will stand the test of time, rather than packages that are more likely to be ephemeral; as even pandas etc. is superseded in performance by the likes of apache datafusion and polars (incidentally both written in rust).

Having said that, we need to consider the ability of maintainers to maintain the code, so something like numba might be a more reasonable choice in the near-term.

---

Proposed tasks:

Pyramid

• Go through original paper - i.e. laplacian to get an idea of how the pyramid decomposition works. Though the general concepts can be applied to other kernels (gaussian, binomial etc.)
• Integrate the existing algorithm in scores (subject to licenses etc.) and profile/write tests
• As the pyramid algorithm is relatively generic, it is plausible to implement it in a low level language like rust/zig. Even if it is not integrated in scores - it will serve as a good test bench/benchmark baseline. (This will not be added to the actual implementation).
• Only if needed re-implement in numba or similar

DAS

• once a good baseline for the pyramid algorithm is established - read through the DAS papers to gauge.
• as before create tests and scenarios based on the existing implementation.
• since DAS itself is a decision maker, rather than the actual feature decomposer itself - it doesn't really need to be optimized to a great extent.
• having said that, it is worth updating the underlying pyramid API to accept tuning parameters if needed.

The above is just a rough guideline for myself - it may change down the track.