PyEMD
PyEMD copied to clipboard
The first IMF is [0,0,0....] all zero when set "parallel=False" using CEEMDAN or EEMD
I used the CEEDMAN like this
ceemdan = CEEMDAN(parallel=False) ceemdan.trials = 10 max_IMF = 5 eIMFs = ceemdan.ceemdan(ts, max_imf=5)
But get the result as
[[ 0. 0. 0. ... 0. 0., 0. ], [ 5.0205319 5.05441522 -4.62335232 ... 0.39283641 -6.48358469, -1.91464419], [ 3.3244119 3.34833722 -3.15371022 ... 0.73033395 7.22461791, 11.2976024 ], [ 1.61699314 1.6286....]
and when I set 'parallel=False', the result is true, the results are as follows: [[ 4.9391269 4.92000825 -4.62921163 ... 0.48549634 -6.37283759, -1.79111796], [ 3.60359462 3.61213567 -3.38193192 ... 1.11980536 6.91068809, 10.10722885], [ 1.32640539 1.34183321 -0.45469606 ... 14.26556025 17.83044674, 20.64068
I have used the latest code, the problem of "too many files" would be happened when used parallel=True, how can I get the true results when I use 'parallel=False'
@laszukdawid Can you solve it for me, thank you very much~~~
Hi, unfortunately I'm a bit busy now. Most likely I won't look into this until the new year.
On Sun, Dec 22, 2019, at 06:45, muqingCai wrote:
@laszukdawid https://github.com/laszukdawid Can you solve it for me, thank you very much~~~
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/laszukdawid/PyEMD/issues/65?email_source=notifications&email_token=ACXNLK3T2J2DVQUKHPNQDRDQZ35G7A5CNFSM4J6KINF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPJFUI#issuecomment-568234705, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXNLK425GKJFRVLMV6BQK3QZ35G7ANCNFSM4J6KINFQ.
Hi, unfortunately I'm a bit busy now. Most likely I won't look into this until the new year. … Do you think it's a bug or something wrong, my work has been blocked because of that. It's so sorry to bother you~~~
I just read your first comment again and I'm not sure what's the configuration difference between both runs.
If you're getting an IMF consistently with all zeros, then that's a bug. However, it's more likely a bug in returning IMFs rather than with the algorithm. Please notice that your second IMF from the set with zero-IMF is quite similar (up to noise) to the first IMF in the set without zero-IMF. This suggests that you should be fine with simply ignoring the zero-IMF (and reordering the rest).
It'd be interesting to see if it's possible to reproduce the results. Would you mind sending me the data to [email protected]?
Thx so much, it’s very nice of you. I have emailed you and the data is as shown in the attachment. I think that ingoring the first IMF could get the right results but what caused the first imf all zero???
3.5 years later. Unlikely this is relevant now. Sincere apologies. I'm only maintaining this package in free time and don't use it at all.
Seems that related issue had a similar problem and it's mentioned there that it's been resolved. It might be resolved here as well.