CEEMDAN processing time

Question

CEEMDAN processing time

SChandel-cmd opened this issue 3 years ago · 3 comments

I am using the CEEMDAN method the way it's in the documentation and it's taking a really long time.
Using PyEMD- EMD takes around 2 minutes, EEMD around 17, and CEEMDAN goes on for an hour+ and does not stop.
Could this be due to the density of the signal I'm processing?
I did normalize the array before parsing it
I even had the trials and max_imf set to 1 but even that didn't give me a result.

Answer 1 · 2021-07-27T18:51:28.000Z

Hi @SChandel-cmd,

Apologies for super late reply. Likely you have solved the problem or moved on but in case you still are facing it, here are some hints.

Unfortunately, CEEMDAN is expected to take long time. It's the most computationally expensive algorithm provided by PyEMD. Given that you have mentioned computation time in minutes, and EMD usually takes a few seconds, I'm guessing that you either have a "complicated" signal or a long signal. Because the main complexity arises from finding extrema and computing splines (based on extrema) the more more of them the longer it takes. Normalization changes amplitude but it doesn't change the shape and so it shouldn't affect the performance.

Your approach with testing EMD and EEMD is correct. It's valuable to have a reference. Also, great usage of trials and max_imfs. If anything, these should significantly affect the performance. Additionally changing the spline method from default "cubic" which looks at all extrema at time, to some more local, e.g. "akima", should significantly reduce the computation time. Please see documentation on Speedup tricks; although they're in context of EEMD they should also apply to CEEMDAN.

Lastly, if you are able to share the signal I'd be happy to investigate how to make it more permanent. Python is convenient to write and use but it isn't the most optimal computationally. There are a few things that I was thinking about adding but I never heard a good reason why to invest in that rather than other things.

Answer 2 · 2021-07-28T04:55:37.000Z

Hi Laszukdawid/Pyemd Thanks for responding, I had moved on to using a different temporary solution through MATLAB but it'd work best for me if I was able to implement CEEMDAN using python itself. I did try a lot of your speedup tricks but unfortunately I think the length of the signal was too long. It had around 60k values if I remember correctly. I've attached the types of signals I'll be working on below. Any help would be appreciated. Regards

…

On Wed, Jul 28, 2021 at 12:21 AM Dawid Laszuk ***@***.***> wrote: Hi @SChandel-cmd <https://github.com/SChandel-cmd>, Apologies for super late reply. Likely you have solved the problem or moved on but in case you still are facing it, here are some hints. Unfortunately, CEEMDAN is expected to take long time. It's the most computationally expensive algorithm provided by PyEMD. Given that you have mentioned computation time in minutes, and EMD usually takes a few seconds, I'm guessing that you either have a "complicated" signal or a long signal. Because the main complexity arises from finding extrema and computing splines (based on extrema) the more more of them the longer it takes. Normalization changes amplitude but it doesn't change the shape and so it shouldn't affect the performance. Your approach with testing EMD and EEMD is correct. It's valuable to have a reference. Also, great usage of trials and max_imfs. If anything, these should significantly affect the performance. Additionally changing the spline method from default "cubic" which looks at all extrema at time, to some more local, e.g. "akima", should significantly reduce the computation time. Please see documentation on Speedup tricks <https://pyemd.readthedocs.io/en/latest/speedup_eemd.html>; although they're in context of EEMD they should also apply to CEEMDAN. Lastly, if you are able to share the signal I'd be happy to investigate how to make it more permanent. Python is convenient to write and use but it isn't the most optimal computationally. There are a few things that I was thinking about adding but I never heard a good reason why to invest in that rather than other things. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AONLZP5TLSIEHGKZ6ONVP63TZ353XANCNFSM47YANV7Q> .

Answer 3 · 2021-07-29T04:54:02.000Z

Thanks for the update. Matlab well deserves bad reputation for many reasons but it is indeed a solid software. Tons of good numerical engineers have contributed to its tool-sets over the years and many of its numerical methods are much better than what you find in Python. But I understand that the problem might be to include analisys in a bigger system to which I agree that Python exceeds.

Unfortunately you sent an update through email and your attachments weren't added to the gtihub thread. Could you please upload these signals somewhere and share the link? Or, if you prefer, send me these directly on "pyemd (at) dawid.lasz.uk".