masw problems with Geopsy releases above 3.0

[luigiV]

Hi Marc,
I have some active seismic datasets that Geopsy 3.4.2 is unable to process because in the message window it tells me, for all 24 tracks, "No source found for signal% i" (see figure).
The same thing also happens with the file in txt format, while version 2.10 has no problem processing both the sg2 and the txt file.
Previously it had never happened and therefore I must assume that it is an error of the data logger in exporting the files from its proprietary format. The significant thing is that this "bug" is dramatic only for Geopsy versions above 3.0.
What do you think?
Thank you
Luigi

[admin]

Hi Luigi,

Check that the Event table contains a source that corresponds to your signal (compatible location and shot time inside the recording range of your signals). Normally for SEG2 format, a source is automatically added to the table so that things are transparent for the user. If no source information is available in the header or if another format is used, you must manually edit this table (next to Groups and Files).

The strange '%i' in the message is fixed for the next release (if not for 3.4.*, it fixed for 3.5.0).

Best regards,

Marc

[luigiV]

Thank Marc.
Actually the Active FK results window indicates active sources 0.
There is no event in the Events list.
Unfortunately there is no instruction on how to use this list and the meaning of some columns and therefore I cannot modify the file.

Is it possible that the gpy created by the txt also gives the same problem as the sg2?

By reopening a previously correctly processed sg2 data file, the coordinates of the 24 stations appear in the message window which would place the shot position at the center of the array and no later than 24. Have I interpreted it correctly or do those coordinates have another meaning? (see image)
I emphasize that version 2.10 correctly processes unrecognized files from versions higher than 3.0.
Could there be a bug in the program?

Thanks

[luigiV]

Addendum
Now the files that gave errors due to lack of source, show the presence of a source in the FK active result window, but over the time series the green area that defines the maximum and minimum offset does not appear and the calculated FK is a blue area. In the message window it says that: not enough time windows available to have 1 non-overlapping block.
Is there a way to intervene on the data file to be able to process it correctly?

Thanks

Luigi

[admin]

Hi Luigi,

It is unclear looking at the JPG. Are you asking for a time window of 0.69 s? If so, can you try to decrease this number? Do you recover the green window?
If not, send me the signal file because I cannot figure out what con could be the cause of the problem. I guess that the minimum and the maximum distances are correct given the position of receivers, and the position of the source at 0, 0, 0.

Best regards,

Marc

[luigiV]

Hi Marc,
your suggestion to use a time window of less than 0.69s resulted in the green area indicating the minimum and maximum offset considered and providing a credible FK spectrum. If I consider a delay time of 0.0s the green area excludes a time portion at the beginning of the recording.
When processing the same file with version 2.10, indications appear in the message window:
Unknown tag at line 771 for context Group: id, but the toolbox indicates that the initial time is -0.02s and the green window includes the entire length of the time series.
So in 3.4.2 I inserted a delay of 0.01s and reduced the total time by an equal amount to get the total coverage of the time window.
By processing the same file with the same min and max offset and frequency parameters, I get a result that seems inconsistent with the two releases.
I am sending you the gpy and sg2 of one of these "problematic" files (perhaps because the shot is in correspondence with the geophone and therefore with offset 0m?) and I would like it if I could verify the consistency of the result with the version higher than 3 and one less than 3.
Finally, as I had already asked you before, why do the distances from the shot point appear different, in the message windows, from the real ones contained in the table ?
Thank you
Kind regards

[admin]

Finally, as I had already asked you before, why do the distances from the shot point appear different, in the message windows, from the real ones contained in the table ?

The coordinates in the message window are the relative coordinates of the array with a reference origin at the centre of the array. These are the working coordinates for array processing to avoid overflow for instance when using UTM coordinates. Does it answer your question?

There might be some minor differences between old and new releases due to several core modifications (e.g. the way frequency samples are distributed). I did a comparison a year ago and found no significant differences. I processed your data, the dispersion curve looks fine but I did not check it with a release before 3.4.2. Can you post the dispersion found with 2.10?

The delay must be -0.1 to start a the beginning of the records.

Best regards,

Marc

[luigiV]

The coordinates question is now clear. Thanks

I attach on the f-k spectrum relative to the offset 8-40m of 3.4.2 the dispersion curves relative to a previous processing with offset 2-20m too.
The dashed curves refer to processing with 2.10.
It is interesting to note that with a small offset the curves matching very well, while by expanding the offset the differences are more macroscopic.
It is equally interesting to verify how the dispersion curves tend to have significantly higher phase phase velocities by increasing the offset.
Is it possible that the fundamental mode, in this site, is defined by the small offset, while with the greater offset a higher mode is intercepted (osculation)? In fact it is certain that the bedrock is found at depths greater than 40m and a DH test up to 20m finds speeds of about 300m / s.
What is your opinion?

Thanks

[admin]

Hi Luigi,

Did you try to play with the spectral normalization in 2.10?
I did a detailed comparison between 2.5 and 3.1 some time ago (see attached pdf).
I'm currently doing the comparison between 3.1, 3.4 and future 3.5.

[luigiV]

I send you the processed data of Masw04.seg2 with the following parameters (the same used for 2.5 release attached to your pdf).
Under 2.10.0,
- min dist 0 m, max dist 50 m
- no taper
normalization (spectrum power)
- from 0 s to 1 s
- bandwidth 0.0
- raw beam power
- velocity sampling from 100 to 1000 with 500 samples (linear)
- frequency sampling from 10 to 50 with 100 samples (log)

The comparison jpg file sent yesterday is referring to a different data set (masw01). The calculated fk spectrum is different from the one of masw04 as you can se from the image.

Do you think you can agree with my interpretation on the comparison and meaning of the different dispersion curves for different offsets related to the Masw01 file I sent you yesterday?

A last question:
how should the coordinates of the geophones be set when the shot is central, or inside the array? I tried with coordinate 0,0 for the shot and positive increasing coordinates towards geophone 1 and negative towards geophone 24, but in this way it gives an antithetical spectrum. I don't know how to do it differently.

Thanks

[admin]

I attach on the f-k spectrum relative to the offset 8-40m of 3.4.2 the dispersion curves relative to a previous processing with offset 2-20m too.
The dashed curves refer to processing with 2.10.
It is interesting to note that with a small offset the curves matching very well, while by expanding the offset the differences are more macroscopic.
It is equally interesting to verify how the dispersion curves tend to have significantly higher phase phase velocities by increasing the offset.

I realize that I did not pay sufficient attention to your post. Now, I got it. This question is twofold. It is interesting that for small offsets the difference is almost null between the old release and a new one. The difference is larger for larger offsets. Did you use the distance normalization in 2.10? With the new release this is automatic and there is no option. As far as I remember there was a bug in old release when computing distance normalization. As you can read in my pdf there are many small differences between the old and the new releases which prevent any fast comparison. I'm not so surprised that at low frequency the two processes diverge.

The other part of the question not connected to bugs or other release features, the increasing of velocity when you increase the offset. Longer wavelengths require more distance to source before developing a full Rayleigh interference. For instance, at 15 Hz, the velocity is approximately 360 m/s, hence a wave length of 24 m. When processing sensors from 2 to 20 m, all sensors are located at less than a wavelength. Near-field effects are highly suspected. For 8-40 m, the situation is better. Below 15 Hz, I would better trust the highest curve.

[admin]

how should the coordinates of the geophones be set when the shot is central, or inside the array? I tried with coordinate 0,0 for the shot and positive increasing coordinates towards geophone 1 and negative towards geophone 24, but in this way it gives an antithetical spectrum. I don't know how to do it differently.

You receiver coordinates start from 2 to 46 m. If you want to process a record with the source in the middle of the line, set the source coordinate at 24 m. The relative coordinates are only internal. When you locate a source or a receiver always use your own coordinate system (local or UTM). Normally, the tool handles the two directions of propagation automatically. Remember that it makes an extremely short line which should provide information only at high frequencies.

[luigiV]

The difference is larger for larger offsets. Did you use the distance normalization in 2.10? With the new release this is automatic and there is no option

Yes, I used.

Your explanation for the spectral result differences for small and large offsets is now clear.

Now I just need you to clarify (question asked in a previous post of mine):
"how should the coordinates of the geophones be set when the shot is central, or inside the array? I tried with coordinate 0,0 for the shot and positive increasing coordinates towards geophone 1 and negative towards geophone 24, but in this way it gives an antithetical spectrum. I don't know how to do it differently. "
I apologize for this insistence, but, unfortunately, there is no technical documentation that can help me without disturbing you.
Thank you