Animation 13 (seismic waveforms)

[PaulWessel]

A new movie example with time-series

This animation exercises the new events -Ardpi option implemented earlier. The movie runs for me, as explained below. For this draft there are some limitations and issues:

1. The data file is currently just placed in the same directory, but the plan is to place it in the cache before merging into master.
2. There is very little meta-data plotted, such as a location map, information about the quake, and scaling factor and units fo the y-axes.
3. This is a short time-series (76 seconds) so in real time it is only 76/24 or a bit over 3 seconds long. That makes it a bit jerky given that 1s is a large step in time. We can (a) slow it down by picking another interval (e.g., 0.1s), (b) smooth it by picking a higher number of frames per second (60?), or (c) pick a longer time-series from another earthquake.
4. Since all panels have the same annotation/ticks the -B stuff should go on the subplot begin line. However that fails, probably because of the -Bp and -Bs options, and if so a "feature" in subplot. Because of this I only plot the clock annotation and not a date, but date could probably go in a side bar with the location map.

The script has a commented out movie call: You first run the anim13.sh script, then copy/paste the gmt movie command and run that afterwards. Because of -Z you must run anim13.sh before each movie command.

Here is the anim13.png:

This is the animated GIF that is built:

[seisman]

3. This is a short time-series (76 seconds) so in real time it is only 76/24 or a bit over 3 seconds long.

It's unclear to me what "real time" means. I thought real time means the 76-s time-series will become a 76-s movie.

[PaulWessel]

Yes you are right. THe 76 s data should play in 76 seconds. With 24 frames per second I need to select output times using 1/24s intervals.

[PaulWessel]

Will post the updated git soon. But my experience opens up an issue for us: movie -Tinfo can either take

1. Number of frames (and time is just 0, 1, 2,...)
2. min/max/inc, and we create an equidistant list of times (this can be absolute time with -f0T
3. A file with time and perhaps other columns

In anim13.sh I am creating a single-column list of times with gmt math, and the problem is two-fold:

1. For "real-time" animation here I want 24 frames to equal 1 second, so dt = 0.0416666666667, not the best value to use in a min/max/inc setup.
2. The default FORMAT_CLOCK_OUT is hh:mm:ss so I get 24 identical times with the same second unless I am smart enough to add --FORMAT_CLOCK_OUT=hh:mm:ss.xxxxx (hint: was not).

I can solve this issue by using -Tmin/max/inc but at other times one really may need to build such times from gmt math and then those two issues are problematic. Some solutions:

1. The GMT_wide -Tmin/max/inc machinery could add another modifier (say +i) to indicate that the increment should be inverted (we already have +n to say the increment is really the number of points). That would let me do 2020-10-06T05:55:00/2020-10-06T05:56:15/24+i which would avoid awkward manual divisions and lack of significant decimals.
2. Modules that accept -T (math, regress, filter1d, ...) could check if T is absolute time and unit is seconds, then look at the increment and if < 1 either automatically set a suitable format_clock_out format (I implemented that in the psevents -Ardpi scheme) or at least warn of loss of precision in the output. I think if we can figure it out it would be better to set the right precision.

[PaulWessel]

Updated movie is too big (212 Mb) now that it has lots of frames (1801) - you can run it though and see what we should enhance. Apart from things like adding a map and meta data, we can

1. Decide if the curves should have colors (e.g., get more intense when there are larger amplitudes)
2. Modify that leading blob - maybe too big right now (-M options)
3. Add a fading out of the color some time after arrival (let the red go to darker red)

[PaulWessel]

Updated to use the new 24+i for 1/24 increment and selected red, green, blue colors for the three traces. Takes 12 minutes to render on 24 cores. Suggestions for improvements, please.

[PaulWessel]

Here is the latest MP4: anim13.mp4.zip

[PaulWessel]

Any suggestions to make this better, @seisman or @joa-quim?

[joa-quim]

It would be funny to have a counters in km since the beginning of the P waves till first S's showing the epicentral distance from station.

[PaulWessel]

Made a few more changes - now the still frame looks like this:

Maybe some text legend etc in the blank spaces is good enough?

[PaulWessel]

Added some text in the side-bar. Maybe @seisman could consider a focal mechanism in the available space etc? Think I am reaching my artistic limit on this animation.

[seisman]

Shall we tweet the animation, although it required GMT 6.2.0?

[PaulWessel]

Sorry, I guess if the focal mechanism changed and magnitude then we do need to update the animation. Perhaps a good practice for @meghanrjones to go through that step? let me know.

[maxrjones]

Sorry, I guess if the focal mechanism changed and magnitude then we do need to update the animation. Perhaps a good practice for @meghanrjones to go through that step? let me know.

Yes, I can update it.

[PaulWessel]

Any reason not to merge this now? I assume the YouTube link does not change when you update?

[maxrjones]

The link seems broken in the Vercel preview.

[seisman]

The link seems broken in the Vercel preview.

Need to update doc/rst/source/animations.rst.

[maxrjones]

Fine to merge after committing the last suggestion (link update). I am making the animation now.

[maxrjones]

Actually, it might need a new url:

Replace or delete your video

You can delete any video you uploaded to your YouTube channel. You can’t replace a video since any new video uploads will get a new URL, but you can change the existing video.

[maxrjones]

Video and links are updated, so it should be good to merge after the checks finish. Let me know if I should post on twitter as a '6.2 preview' - otherwise we can share after the release.

[PaulWessel]

Hm, maybe getter to go with the RC1 release since easier for non-dev types to try out a bundle or installer?

[maxrjones]

Hm, maybe getter to go with the RC1 release since easier for non-dev types to try out a bundle or installer?

Sounds good.