[其他]地震处理软件开发 GeoSong [复制链接]

我的一些想法
我是处理员出身，跟研究人员不同，对先进算法没什么研究，因此想要写些东西的时候入手的角度自然不同。所以我想的不是做个波动方程偏移或者类似的模块，而是想做一个处理平台。
这样一个平台，用户可以选择各种模块来实现自己要做的事情，即使这些模块是最常用的功能而不是最先进的东西，比如带通滤波，动校正什么的。它们功能简单，人人都懂得它如何工作的。如果你有博士学历，大概不屑于开发这样的模块的。但是你离不开它们，所以很多人都在SU下面做自己的先进的算法研究。
我的理想是打造一个处理的平台，输入输出，文件格式，常用功能都由这个平台来实现，并且这个平台是交互的，友好的。大家都可以在这个平台上做研究做开发。这是我的理想。

Version1.1 实现了SEG-Y数据的读入和显示。本软件的地震数据采用SEG-Y格式存储和处理。数据读入的开发涉及到了big endian数和little endian数转换，IBM浮点数和IEEE浮点数转换。后面关于SEG-Y格式的介绍里面会提到。显示方面我参考了Focus的显示风格，自己琢磨出来的算法，采用灰度图显示，彩图的话其实换个色标就可以了，不过我一个人做不过来，先有一个显示用着就好，至于画波形图更加麻烦等以后腾出来手再做好了。各位看官看看自然知道显示效果好不好的。

Version1.2 是当前开发的版本，它在之前的基础上添加了作业编辑的功能。这个过程挺麻烦的，我现在所有的作业模块都是采用动态链接库（DLL）的形式提供，这样模块和软件本身各自独立开来，使得任意第三方都可以根据标准开发自己的模块，从而实现任意扩容。在开发出来自己的DLL文件的同时，我们需要告诉软件平台这个库需要的参数的数目和类型，软件会自动产生交互界面用于填写参数并存储成为作业文件。我构思这个东东花了不少时间。

后面我会慢慢完善一些帖子，发一些抓图，等1.2做好了，出一个release的可执行程序。目前的都是debug版本的，运行起来很慢很不爽。


Version1.3 在这个版本里面我希望重写SEGY Input和SEGY Output模块，使之在读取和存储的同时，产生数据的索引文件以实现数据的随机访问。以及产生数据库文件，使得处理员面对的是要处理的一个工区，而不仅仅的单个的数据。有了索引和工区数据库文件以后，处理员就有了更多的信息，用于实现想要达到的处理目的。

上面的计划很美好，我实现起来很艰难，因为一直都是一个人在写。毕竟不是程序员出身，很多东西一边写一边学，花费很多的精力和时间，进度不快还满是bug。到目前v1.2已经快完成，只有IBM浮点转IEEE浮点的不到50行的代码是从网上搜来的之外，其他所有代码都是我自己设计的或者研究了算法然后自己写出来的。
我会把我的代码公开来，希望能够有有志之士加入进来共同完成这个理想。另外如果有人看好它的商业前景，投资进来拉兄弟一把就更好了。我有一个QQ群92072247，QQ号21824257，Email地址xiaoping.soong@gmail.com.

先简单贴三张图，后面会细细道来。

图片:Snap1.jpg

图片:Snap2.jpg

图片:Snap3.jpg

要用到的包括QT， DLL， MPI等。 先简单说说


   从网上搜来的QT的优势：
1、跨X11, Win32, Mac三个平台并且是二进制原生代码的（比java和.net程序快得多)（源代码级移植)
2、有个十分好使用的工程管理工具qmake((相比较wxWidget, Gtk+等而言，非常地方便开发)
3、在常用的X11, Win32平台既有开源版，又有商业版，供不同的用途使用。又有公司的商业支持，开发正规。有KDE(包括KOffice, KDevelop等)这样典型的的成功运用的项目，使人放心。随着Qt 4.0开源版的发布，KDE向Windows的移植已经确定，由此，KDevelop, KOffice等一大批KDE下面的软件也就能移植过去， 有了KDevelop，KWrite等，Windows下Qt的应用将很快多起来，也更加方便开发，我在期待着KDevelop移植到Windows，以解决Windows下的用QT开发的IDE问题。
4、有方便的嵌入式图形界面开发方面的解决方案

对我自己来说，
1，    我是一个新手程序员，做界面的东西VC+MFC曾经试图学过两次以失败告终，QT容易上手；
2，    QT跨平台，我希望windows下面做东西方便，然后再移植到Linux容易。毕竟QT的基于C++来做的。话说我还一次没尝试把程序拿到Linux下面编译呢；
3，    始终觉得c/c++好，那要想在Linux下面做界面，就选QT喽。

动态链接库
   百度百科
动态链接库英文为DLL，是Dynamic Link Library 的缩写形式，DLL 是一个包含可由多个程序同时使用的代码和数据的库，DLL不是可执行文件。动态链接提供了一种方法，使进程可以调用不属于其可执行代码的函数。函数的可执行代码位于一个 DLL 中，该 DLL 包含一个或多个已被编译、链接并与使用它们的进程分开存储的函数。DLL 还有助于共享数据和资源。多个应用程序可同时访问内存中单个DLL 副本的内容。DLL 是一个包含可由多个程序同时使用的代码和数据的库。
通过使用 DLL，程序可以实现模块化，由相对独立的组件组成。例如，一个计帐程序可以按模块来销售。可以在运行时将各个模块加载到主程序中（如果安装了相应模块）。因为模块是彼此独立的，所以程序的加载速度更快，而且模块只在相应的功能被请求时才加载。
　　此外，可以更为容易地将更新应用于各个模块，而不会影响该程序的其他部分。例如，您可能具有一个工资计算程序，而税率每年都会更改。当这些更改被隔离到 DLL 中以后，您无需重新生成或安装整个程序就可以应用更新。
对我来说，前面提到了，要实现模块和软件独立，就必须要用DLL。 好在QT很体贴地提供了QLibrary，它把依赖于操作系统的动态链接库加载API封装起来了，这样写代码省事多了。

　对MPI的定义是多种多样的，但不外乎下面三个方面，它们限定了MPI的内涵和外延：
　　1、MPI是一个库，而不是一门语言。许多人认为，MPI就是一种并行语言，这是不准确的。但是，按照并行语言的分类，可以把FORTRAN+MPI或C+MPI看作是一种在原来串行语言基础之上扩展后得到的，并行语言MPI库可以被FORTRAN77/C/Fortran90/C++调用，从语法上说，它遵守所有对库函数/过程的调用规则，和一般的函数/过程没有什么区别；
　　2、MPI是一种标准或规范的代表，而不特指某一个对它的具体实现，迄今为止，所有的并行计算机制造商都提供对MPI的支持，可以在网上免费得到MPI在不同并行计算机上的实现，一个正确的MPI程序可以不加修改地在所有的并行机上运行；
3、MPI是一种消息传递编程模型，并成为这种编程模型的代表。事实上，标准MPI虽然很庞大，但是它的最终目的是服务于进程间通信这一目标的；

MPICH是MPI的一个实现，我只会它最基本的用法，现在还只是在windows下面做开发，虽然代码里面都实现了MPI并行，不过我还没用多台机器试过并行。留着以后要做Linux集群版本再去头疼吧，哪来那么多时间啊。

我觉得，一个人或几个人从0开始，做一个很大的处理系统意义不大。由于地震勘探的数据格式有业界的标准，个人的程序或软件一般都是想完成某个想法，所以首先要做的就是先解决数据体的输入和输出（可以包括简单的显示）。一个软件不需要太复杂，只要能很好地完成一个功能，实现了某个想法，就可以了。如果试图做一个很大的很复杂的处理系统，不仅短期内难以实现，而且由于个人或小集体的力量水平所限，实现后它的商业价值可能很小，这就像人们买设备，国外的虽贵但人们仍不买国产。我的建议是不要图大图全，要做小而精干顶用的！

很好。支持一下。

支持原创，呵呵，不过我也有六楼同样的看法，宋哥，你咋看？

引用第6楼yangwqcumt于2011-03-06 12:14发表的  :
我觉得，一个人或几个人从0开始，做一个很大的处理系统意义不大。由于地震勘探的数据格式有业界的标准，个人的程序或软件一般都是想完成某个想法，所以首先要做的就是先解决数据体的输入和输出（可以包括简单的显示）。一个软件不需要太复杂，只要能很好地完成一个功能，实现了某个想法，就可以了。如果试图做一个很大的很复杂的处理系统，不仅短期内难以实现，而且由于个人或小集体的力量水平所限，实现后它的商业价值可能很小，这就像人们买设备，国外的虽贵但人们仍不买国产。我的建议是不要图大图全，要做小而精干顶用的！

谢谢你的建议，我现在面临的正是这个难题。所以目前要做的都是基本的功能，我从处理员的角度出发，必要的功能得做出来。一些其他复杂的附属的东西，都先搁置着。当前的目标是把框架搭起来，并且具有一定实用性。