I decided to look at the full.0.TVz file. It has 1259284 bytes-
48% ls -l *.TVz -rw-r--r-- 1 donghong seismo 1259284 Oct 12 14:38 full.0.TVz -rw-r--r-- 1 donghong seismo 160096 Oct 12 04:15 test011.0.TVz -rw-r--r-- 1 donghong seismo 160096 Sep 23 17:10 test11.0.TVzThe octal dump below displays the 2-byte integers. The two 4-byte integers that E3D begins the file with, the number of traces nx and the number time samples per trace nt, are small enough to be in the low-order byte pairs of the 4-byte integers. nx is at byte indices, in octal, 0000 through 0003, and nt is at indices 0004 through 0007. nx=101 and nt=3116, which should be what you asked for. If E3D made the TVz file correctly, the file would have exactly 101x3116x4 + 8 = 1258872 bytes. Instead, the file has an excess of 412 bytes. E3D seems to write a random number of extra bytes after nx and nt but before the trace data. The attached PCalc 2 program for Mac will convert from decimal to octal and back-
46% od -d full.0.TVz|m 0000000 00000 00101 00000 03116 15771 42468 00000 00000 0000020 00000 00001 00000 00002 00000 00003 00000 00004 0000040 00000 00005 00000 00006 00000 00007 00000 00008 0000060 00000 00009 00000 00010 00000 00011 00000 00012 0000100 00000 00013 00000 00014 00000 00015 00000 00016 0000120 00000 00017 00000 00018 00000 00019 00000 00020 0000140 00000 00021 00000 00022 00000 00023 00000 00024 0000160 00000 00025 00000 00026 00000 00027 00000 00028 0000200 00000 00029 00000 00030 00000 00031 00000 00032 0000220 00000 00033 00000 00034 00000 00035 00000 00036 0000240 00000 00037 00000 00038 00000 00039 00000 00040 0000260 00000 00041 00000 00042 00000 00043 00000 00044 0000300 00000 00045 00000 00046 00000 00047 00000 00048 0000320 00000 00049 00000 00050 00000 00051 00000 00052 0000340 00000 00053 00000 00054 00000 00055 00000 00056 0000360 00000 00057 00000 00058 00000 00059 00000 00060 0000400 00000 00061 00000 00062 00000 00063 00000 00064 0000420 00000 00065 00000 00066 00000 00067 00000 00068 0000440 00000 00069 00000 00070 00000 00071 00000 00072 0000460 00000 00073 00000 00074 00000 00075 00000 00076 0000500 00000 00077 00000 00078 00000 00079 00000 00080 0000520 00000 00081 00000 00082 00000 00083 00000 00084Now using octal dump to translate the bytes into IEEE 4-byte floats, the first 0644 (octal) bytes are not valid 4-byte float data (and show up as <10E-40). So this agrees with the size of the file- 8 header bytes for nx,nt + 412 bytes of garbage (from calculated file size against real size) = 420 bytes (0644 in octal) to skip when reading the file into Viewmat. The extra garbage does usually seem to end with a NaN. Then you can see perfect zero trace-sample values (which is what there should be at the start of each trace, before any waves arrive) and small values-
47% od -f full.0.TVz|m 0000000 1.4153114e-43 4.3664460e-42 7.6000005e-02 0.0000000e+00 0000020 1.4012985e-45 2.8025969e-45 4.2038954e-45 5.6051939e-45 0000040 7.0064923e-45 8.4077908e-45 9.8090893e-45 1.1210388e-44 0000060 1.2611686e-44 1.4012985e-44 1.5414283e-44 1.6815582e-44 0000100 1.8216880e-44 1.9618179e-44 2.1019477e-44 2.2420775e-44 0000120 2.3822074e-44 2.5223372e-44 2.6624671e-44 2.8025969e-44 0000140 2.9427268e-44 3.0828566e-44 3.2229865e-44 3.3631163e-44 0000160 3.5032462e-44 3.6433760e-44 3.7835059e-44 3.9236357e-44 0000200 4.0637655e-44 4.2038954e-44 4.3440252e-44 4.4841551e-44 0000220 4.6242849e-44 4.7644148e-44 4.9045446e-44 5.0446745e-44 0000240 5.1848043e-44 5.3249342e-44 5.4650640e-44 5.6051939e-44 0000260 5.7453237e-44 5.8854536e-44 6.0255834e-44 6.1657132e-44 0000300 6.3058431e-44 6.4459729e-44 6.5861028e-44 6.7262326e-44 0000320 6.8663625e-44 7.0064923e-44 7.1466222e-44 7.2867520e-44 0000340 7.4268819e-44 7.5670117e-44 7.7071416e-44 7.8472714e-44 0000360 7.9874012e-44 8.1275311e-44 8.2676609e-44 8.4077908e-44 0000400 8.5479206e-44 8.6880505e-44 8.8281803e-44 8.9683102e-44 0000420 9.1084400e-44 9.2485699e-44 9.3886997e-44 9.5288296e-44 0000440 9.6689594e-44 9.8090893e-44 9.9492191e-44 1.0089349e-43 0000460 1.0229479e-43 1.0369609e-43 1.0509738e-43 1.0649868e-43 0000500 1.0789998e-43 1.0930128e-43 1.1070258e-43 1.1210388e-43 0000520 1.1350518e-43 1.1490647e-43 1.1630777e-43 1.1770907e-43 0000540 1.1911037e-43 1.2051167e-43 1.2191297e-43 1.2331426e-43 0000560 1.2471556e-43 1.2611686e-43 1.2751816e-43 1.2891946e-43 0000600 1.3032076e-43 1.3172206e-43 1.3312335e-43 1.3452465e-43 0000620 1.3592595e-43 1.3732725e-43 1.3872855e-43 1.4012985e-43 0000640 -NaN 0.0000000e+00 0.0000000e+00 0.0000000e+00 0000660 0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 * 0220320 0.0000000e+00 0.0000000e+00 0.0000000e+00 2.3337893e-38 0220340 0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 *The *'s represent many identical lines of zeros not output.
OK, now to read the file into Viewmat, you have to realize that E3D
writes trace data multiplexed- that is, for each time step written, the
data from that one time are written together for all traces. So the
traces files are in rows of x, not rows of t (which are known as
seismograms). So you read it into Viewmat using:
Binary File Type: Raw Float Bytes to Skip: 420 Elements per Vector: 101 Vectors per Plane: 3116 Vectors per Plane: 1Then you can do a Methods->On Each Plane->demult (de-multiplex) to get the traces into rows of time, and then do the ReMi analysis. I found your time-sampling interval to be 0.076 s, and your trace interval 100 m. A 10-km array is very long, but I think I did see some dispersion in that synthetic in the p-f plot.