Consider passing RFTrace to deconv* function rather than raw numpy array

[medlin01GA]

In function rf.deconvolve.deconvolve(), when the response data is gathered for passing on to the underlying deconvolution function (e.g. deconvt or deconvf), it is put into a list of numpy.array, as at line 113: rsp_data = [tr.data for tr in rsp]

In my use case of a custom deconvolution function this works fine, however there are output metadata of the deconvolution process that ideally I would like to store with the traces. If the deconvolution function were passed RFTrace objects rather than numpy.arrays then I could add the metadata to the RFTrace.stats container.

[trichter]

I see, it is not possible to return anything other than the deconvolved data, at the moment. I thought about other possibilities, e.g. appending other returned values of the deconv functions to the Stream object, but that would be rather unusual and also would not help, if you have metadata to store with the traces. Since the possibility of using a custom deconv function was only recently added upon your request, I think it is no problem to change how the deconv functions are called now. I'll have a look.

[trichter]

Hmm, well OK, custom deconvolution functions were introduced in version 0.5.0, which was published 2 years ago.

Edit: Now I got it, it just started to work recently ;)

[medlin01GA]

Maybe I could achieve what I want by adding extra arguments that get collected in kwargs when I call rf(). Then in my custom deconv function I can extract those from kwargs and add my custom metadata into there.

---

From: Tom Eulenfeld notifications@github.com Sent: Thursday, 26 September 2019 6:08 PM To: trichter/rf rf@noreply.github.com Cc: Medlin Andrew Andrew.Medlin@ga.gov.au; Author author@noreply.github.com Subject: Re: [trichter/rf] Consider passing RFTrace to deconv* function rather than raw numpy array (#17)

Hmm, well OK, custom deconvolution functions were introduced in version 0.5.0, which was published 2 years ago.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/trichter/rf/issues/17?email_source=notifications&email_token=AK3ZLR7CBBVD26TUBS4QYP3QLRUYJA5CNFSM4I2VZTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7UWXHI#issuecomment-535391133, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AK3ZLR5YELWW4JHY3WGEK4DQLRUYJANCNFSM4I2VZTJA.

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.

[trichter]

I changed the behaviour in deconvolve for the dev version. A RFStream is now passed to the custom deconv function and it assumes a Stream is returned. Thus, you now can use the RFTrace.stats object to store metadata.

Maybe I could achieve what I want by adding extra arguments that get collected in kwargs when I call rf(). Then in my custom deconv function I can extract those from kwargs and add my custom metadata into there.

This is also a good idea. Just make sure that you use a mutable object, like dict or list. You don't need to extract from kwargs, just specify it directly.

def custom_deconv(..., info={}):
    ...
    info['key'] = value
    ...

info = {}
stream.rf(..., deconvolve='func', func=custom_deconv, info=info)
print(info)

[trichter]

@medlin01GA Are these latest commits working for you?

[medlin01GA]

I have reviewed the code changes and added one comment. I haven't used the changes myself yet as I'm using release 0.8.0 and have not updated to dev, however they look like just what I was looking for in my custom deconvolution function.

[trichter]

Thanks for the feedback.