modification on raylib， rf2depth

JouSF-1409 commented 7 months ago

rayplib的优化，提供了命令行选项 rf2depth的一点优化，使用namedtuple改善了Station类的使用 depmodel.py 中的ccp_model太繁琐，未来会拆分重写。

几个失败的尝试： a. 使用namedtuple存储RF2depth 的结果 d. classmethod depth_model.ccp_xxx，设计得太过繁琐，未来考虑拆分

几个未来的变化想法： b. finalist.dat 格式的改进。 c. 批量生成剖面，

a. namedtuple，相比于使用dict.add有速度和规范上的优势，但经过numpy.save后会拆解为tuple，只保留变量顺序。改动太大，跳过先。

b. finalist.dat细化：

使用更多的list文件，而不是使用单一名称的配置文件。数据处理过程中，我们可能需要更多的文件用于记录数据处理情况。比如说，我们根据不同等级的信噪比约束，生成了几个不同的list，pick1.dat, .pick2.dat, ...pickn.dat。或者一些数据可以用于h-k，但不能用于分析410-660，同样可以生成pick_hk.lst, pick_410.lst。这样也便于我们回溯不同阶段的操作。
如果我们能生成不同的 list文件，一些变量也可以搁置比如phase， comp。很明显的是，我们并不会把S波接收函数与P波，或者pP波同时做rf2depth，LQT or RTZ 也不会对rf2depth的流程带来本质上的影响。
作为第二点的补充，我们是不是可以将第一列的时间改为文件名，（在需要切向分量的情况下，某一列为对应的文件名）这样不需要写很多繁琐且不完善的检查。我们也可以用一些简单的脚本工具(saclst)去生成这些文件。
命令行也可以做一定的改变，指定phase/ listname（路径为 station_name / listname）

c. 批量生成剖面的细化

cfg文件对于批量操作有些笨重
目前写了一个py+sh的脚本，还是有些麻烦
过程中发现不同depth_axis的npy文件不能混用，比如说一个range(0,250,2)的npy不能与range(0,200,1)的cfg文件搭配使用，即使我们在npy文件中保存了每个trace的depth_axis，是否可以做一定的改善？

JouSF-1409 commented 7 months ago

我还想了解这个Test怎么在我的仓库里进行部署，这样我可以在pr之前先做一些测试。因为删掉了一些改动，所以check出了一些简单的问题，commit很多，抱歉。

codecov[bot] commented 7 months ago

Codecov Report

Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (7dc0a87) 45.58% compared to head (9aa94a0) 45.67%.

Files	Patch %	Lines
seispy/rf2depth_makedata.py	70.21%	14 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## dev #80 +/- ## ========================================== + Coverage 45.58% 45.67% +0.08% ========================================== Files 40 40 Lines 5997 6016 +19 ========================================== + Hits 2734 2748 +14 - Misses 3263 3268 +5 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

xumi1993 commented 7 months ago

非常感谢，rayplib里的功能，哪些是经过测试的，你可以在test中添加新的测试脚本，先在你的repo中测试生成射线参数有关的功能。

对于今后的修改，我的建议是在当前版本基础上不要修改任何与输入/输出格式有关的部分，对于很多early career用户可能是灾难性的。所有跟格式有关的问题，可以统一记录下来，今后在下一个大版本（2.0.0）中再更新。这些更新还需要大量的测试和详细的说明文档，是一个很大的工程。
finalist.dat的改进，我不是很能理解，首先，例如不同信噪比的结果，目前只能放在不同的文件夹中，如果希望将这些数据放在一个文件夹中，可能会让一些用户产生混淆，容易产生误操作，我们必须考虑所有用户的体验。多个数据表中很多column的内容是重复的，如果真的要把所有的数据放在一个文件夹中，这也不是一个最优的选择。在未来的版本中，如果需要将所有数据放在一个文件夹中，一种做法是，将sac格式文件替换成h5格式，finallist用一个关系型数据库代替，如SqLite。
对于批量计算，可以通过新增一个命令实现，就不需要写sh脚本。后期我考虑用toml格式或者yml格式替换cfg文件格式，它们相比之下更加先进灵活。

JouSF-1409 commented 7 months ago

Q1， Logger 的替代 A1：是一种通用性的考虑。使用Logger能忽视setuplog的具体实现，而更关注于我们想输出到日志系统的内容。如果未来可能会对其进行改动（比如输出更多信息，绑定不一样的输出），那么只需要考虑传递给他一个Logger 类型的对象，而不是从头开始看setuplog相关的内容。 Q2，大写的问题 A2，我意识到类里面很多变量实际上更多起到状态的表示，比如说这里的RAYTRACING3D。我希望他和一般的变量能更有区分。所以这样简单的改一下，是写C的一种习惯。

xumi1993 commented 7 months ago

A1：是一种通用性的考虑。使用Logger能忽视setuplog的具体实现，而更关注于我们想输出到日志系统的内容。如果未来可能会对其进行改动（比如输出更多信息，绑定不一样的输出），那么只需要考虑传递给他一个Logger 类型的对象，而不是从头开始看setuplog相关的内容。

我还是不能理解为什么这样做，比如为什么忽视setuplog的具体实现，为什么要在RF2depth这个类中考虑通用性？

Q2，大写的问题 A2，我意识到类里面很多变量实际上更多起到状态的表示，比如说这里的RAYTRACING3D。我希望他和一般的变量能更有区分。所以这样简单的改一下，是写C的一种习惯。

在python语言规范中全大写变量名通常表示全局变量或常量，这不符合python规范。

JouSF-1409 commented 7 months ago

我们并不需要一个大的更改，可以创建一个新的接口，seispy接口的几个层次还是比较明显的。

我觉得您对于finalist和cfg问题的描述也很到位。有几点我认为可以补充， xml文件并不是一个高可读的语言，对于不熟悉html的用户而言，冗余的信息太多。相比之下我认为json可能要更合适一些。关于这种不同list的问题，我希望我做的每一步都能有配置文件和足够多的注释辅助回溯，并且这些文件能在文本编辑器下一目了然。这样能显著减小错误操作的几率。（打个比方，在 snr2.cfg中，指定在文件夹下找t2.dat，并且注释写明，这些文件是信噪比大于2.0的）这样会不会比较简单，并且不需要涉及sql

JouSF-1409 commented 7 months ago

大写的改动只是暂时的，我还没思考好怎么去处理类里面的这么多变量。里面命名相似的变量有点多。
通用性考虑是全局的。目前我还只写到RF2depth这里。首先是，我希望能在处理流程中只传递Logger而不是setuplog。这样在比较深部的函数如果想接受一个日志管理器，可以直接接受Logger，而不需要考虑 setuplog是否创建了这个名称的Logger。同时，如果一个函数用在了不同的处理流程中，也可以很方便地更换他输出信息的Logger。

xumi1993 commented 7 months ago

我们并不需要一个大的更改，可以创建一个新的接口，seispy接口的几个层次还是比较明显的。

我觉得您对于finalist和cfg问题的描述也很到位。有几点我认为可以补充， xml文件并不是一个高可读的语言，对于不熟悉html的用户而言，冗余的信息太多。相比之下我认为json可能要更合适一些。

toml和yml都不是xml语言，且比json简单很多，你可以详细了解一下。cfg目前有一个致命问题，就是不能定义数组。我有考虑过用toml格式代替，因为她的格式和cfg几乎一样，没有什么学习成本。

xumi1993 commented 7 months ago

大写的改动只是暂时的，我还没思考好怎么去处理类里面的这么多变量。里面命名相似的变量有点多。

通用性考虑是全局的。目前我还只写到RF2depth这里。首先是，我希望能在处理流程中只传递Logger而不是setuplog。这样在比较深部的函数如果想接受一个日志管理器，可以直接接受Logger，而不需要考虑 setuplog是否创建了这个名称的Logger。同时，如果一个函数用在了不同的处理流程中，也可以很方便地更换他输出信息的Logger。

首先作为python module必须保证pythonic语言规范，你可以用特定的前缀来表示这些变量。因为很多用户都在使用devbranch因此我希望在每个PR中尽量不要出现这些修改，避免让用户产生疑惑。 setuplog这里是我看错了，这里没有问题。

JouSF-1409 commented 7 months ago

非常感谢，rayplib里的功能，哪些是经过测试的，你可以在test中添加新的测试脚本，先在你的repo中测试生成射线参数有关的功能。

关于raylib的内容，我有一些不太清楚的地方。即seispy里rayp 的单位。现行的单位里，有s/km, s/rad, s/deg。几个数字量级都不一样，窃以为要在教程页或者注释里着重说明。

obspy.taup和matlab taup输出的似乎都是s/rad，这里我转换到了s/deg，与教程网站里给出文件的数量级达到一致。但是在程序内部，似乎会将s/deg的rayp 转换为s/rad的结果进行计算？如是，则可以在生成rayplib的过程中节省一大步。并且在后续的计算中保持单位的一致，更专注于程序本身。

我还没细看过test?.py 。里面有很多不给出参数的调用，我感觉很奇怪就没细看。程序还是要一个数值上的检验比较靠谱些，这也是我选择doctest 的原因之一。此外，我也想了解相关的测试写在哪里，以及怎么部署一个类似的测试到我自己的代码库里。

JouSF-1409 commented 7 months ago

首先作为python module必须保证pythonic语言规范，你可以用特定的前缀来表示这些变量。

非常赞同您对规范的支持，我对python 规范还只有一个比较模糊的概念。为写出更优质的代码努力！

想了解您对其他改动的态度。比如namedtuple的使用和 Station类的修改

yaml文件我用过，是我看错了。之前配置过一个用xml配置参数的测地学软件，印象太过深刻。用数组配置确实是一个解决迭代的好方案。

xumi1993 commented 7 months ago

关于raylib的内容，我有一些不太清楚的地方。即seispy里rayp 的单位。现行的单位里，有s/km, s/rad, s/deg。几个数字量级都不一样，窃以为要在教程页或者注释里着重说明。

obspy.taup和matlab taup输出的似乎都是s/rad，这里我转换到了s/deg，与教程网站里给出文件的数量级达到一致。但是在程序内部，似乎会将s/deg的rayp 转换为s/rad的结果进行计算？如是，则可以在生成rayplib的过程中节省一大步。并且在后续的计算中保持单位的一致，更专注于程序本身。

我个人的习惯是用s/km并且在rfani和moveoutcorrect等函数中用的也是s/km，由于计算tps使用的rad，所以都转换成了s/rad。另外“教程网站里给出文件的数量级达到一致是指什么？“ 对于软件来说可能保存成s/rad用起来更方便

我还没细看过test?.py 。里面有很多不给出参数的调用，我感觉很奇怪就没细看。程序还是要一个数值上的检验比较靠谱些，这也是我选择doctest 的原因之一。此外，我也想了解相关的测试写在哪里，以及怎么部署一个类似的测试到我自己的代码库里。

这也是个历史遗留问题，对于函数适合用doctest，但对于一个完整的计算流程，很难定义一个数值上的比较。

JouSF-1409 commented 7 months ago

我个人的习惯是用s/km并且在rfani和moveoutcorrect等函数中用的也是s/km，由于计算tps使用的rad，所以都转换成了s/rad。另外“教程网站里给出文件的数量级达到一致是指什么？“ 对于软件来说可能保存成s/rad用起来更方便

是seispy主页上下载的预先计算的rayplib。

关于rayplib.py 未来可能有一个功能，即导入自定义速度模型。我还没考虑好怎么写接口，tvel 和DepModel使用的文本格式还是有一些区别。目前的计划是导入一个速度模型，转换到tvel格式的文件，再由obspy.taup进行计算。

xumi1993 / seispy

modification on raylib， rf2depth #80

Codecov Report