Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scautopick stop working after ~3 hours #58

Closed
luca-s opened this issue Mar 17, 2023 · 6 comments
Closed

scautopick stop working after ~3 hours #58

luca-s opened this issue Mar 17, 2023 · 6 comments

Comments

@luca-s
Copy link
Contributor

luca-s commented Mar 17, 2023

Dear developers,

this issue is something that I am going to debug myself, but I would like to double check first with you in case you have an idea already of what the problem could be.

The bug happens all the time: I start scautopick and after ~3 hours it stops producing picks. The process is still alive though. The interesting thing is that I am using data at 200.000hz. Do you know if there are internal counters that might reach the limits too soon with this high frequency data?

thanks
Luca

@jsaul
Copy link
Contributor

jsaul commented Mar 17, 2023

Hi Luca,
good catch! 200k * 3600 * 3 is very close to 2**31 so you are probably on the right track that some counter is the culprit.

find ~/seiscomp/include/seiscomp -name "*.h"|xargs grep sampleCount

Take your pick. :) Maybe

https://github.com/SeisComP/common/blob/master/libs/seiscomp/math/filter/stalta.cpp#L90
https://github.com/SeisComP/common/blob/master/libs/seiscomp/math/filter/stalta.cpp#L97

as a start... The developer on duty certainly did not have such large _sampleCount on his radar, let alone the possibility that it may become negative... I am pretty sure that changing the type of _sampleCount to int64_t will already fix the issue. Would you mind trying that out?

Thanks for the hint!
Joachim

@gempa-jabe
Copy link
Contributor

I would just skip increasing the samplecount once it is not needed anymore, after it is >= numLta. If a lta time window for 1Mhz data of 30 minutes should be supported then we can use int64 anyway. Changing the count possibly breaks binary compatibility.

@luca-s
Copy link
Contributor Author

luca-s commented Mar 18, 2023

Thank you, I had the feeling that you knew something already :) I will test it and report back.

@luca-s
Copy link
Contributor Author

luca-s commented Mar 19, 2023

I confirm that is the bug

@gempa-jabe
Copy link
Contributor

I have fixed it hopefully, please give it another try. The fix is in common repo.

@luca-s
Copy link
Contributor Author

luca-s commented Mar 22, 2023

Thank you!

@luca-s luca-s closed this as completed Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants