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

SAC在处理长数据时会遇到浮点数误差问题 #314

Open
seisman opened this issue Apr 12, 2023 · 0 comments
Open

SAC在处理长数据时会遇到浮点数误差问题 #314

seisman opened this issue Apr 12, 2023 · 0 comments

Comments

@seisman
Copy link
Owner

seisman commented Apr 12, 2023

Question:

我想请教个关于sac的问题:按seisman网页sac说明,改参考时刻为发震时刻的时候,有没有人发现kztime最后的nzmsec值不对,不是理论上减去o之后的值,与o的毫秒不相等。

Answer:

这个问题本质上是由于数据太长再加上浮点数误差导致的。你的数据的长度基本上都是一天。以 LN.XYN.00.BHZ 这个数据为例,原始数据里 b=0, e=87600.75,kztime=15:40:01.690。假如设置发震时刻为 2018 01 25 01 15 58 295(我这里msec用295,更容易说明问题),理论上算出来的 o 值应该等于 34556.605,而如果你使用 lh o 查看,就会发现头段里的 o 值是 3.455661e+04,即算出来的 o 值是不准确的。产生这样问题的原因是,SAC 中所有头段都是用浮点数保存的,而浮点数的有效位数只有 7 位,所以 34556.605 会被"近似"为 34556.61 或 34556.60
你需要一次性读入三分量,然后使用 synchronize 同步三分量的参考时间,然后再执行 ch o gmt 和 ch allt 命令
还有一点需要注意的是,即便是按照我上面的说法,同时处理三分量数据,也会出现一个小问题,比如你设置了 msec=295,你会发现在执行完 ch o gmt 和 ch allt 之后,kztime 里的 msec 可能是 296 或者 294。本质原因还是浮点数误差导致的msec最后一位存在误差,但至少三分量里的时间是一致的

需要写进手册里。

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

1 participant