Trampled-upon image in an otherwise fine animation sequence

[PaulWessel]

I am remaking the usual fly-over of the mid-ocean ridge with over 2000 frames. Exactly 2 frames do strange stuff. It is always the same 2 frames. I have isolated the movie job down to just make three frames with the middle one going crazy only. Stripped off any labelling etc so it is just a grdimage plot with colors from a global static topo grid (and for this test I ignore the intensity grid). The correct first frame looks like this:

The second bad frame looks like this:

while the third frame is back to normal:

I even added -x1 to ensure each frame was built separately so only one grdimage command was running at the same time. No difference. This data set was the 30s earth_relief version. Lower resolutions do not have the problem. Also, if I run grdcontour instead of grdimage there are no odd offsets. If I run grdimage manually (not via movie) then the 2nd frame is fine.
Summary:

Affects grdimage when run via movie, and is reproducible for the same (2) frame out of 2300 frames

1. Not caused by job interference since one frame has to complete before the next starts (-x1).
2. Adding -M selects grayscale image - get same problem so not likely to be loop code (?)
3. Converting the script and running batch with grdimage -A instead of PostScript and ghostscript yields the same problem; so not a gs issue.
4. Most likely something related to how both movie and batch launches scripts?

Very open to ideas of what to check for and how this can happen! I have checked the intermediate script files and there is nothing that seems odd in any of them (e.g., the aparemeter files).

[anbj]

Mind sharing the code?

[PaulWessel]

This is the grid you need; the 30s topo version

gmt grdcut @earth_relief_30s_p -Rd -Gearth_relief_p.nc

main.sh:

#!/bin/bash
gmt begin
	gmt grdimage -Rd -JG${MOVIE_COL0}/${MOVIE_COL1}/${ALTITUDE}/${MOVIE_COL2}/${TILT}/${MOVIE_COL3}/${WIDTH}/${HEIGHT}/${MOVIE_WIDTH} \
	  -Y0 -X0 ${TOPO}
gmt end

include.sh:

# A set of parameters needed by all frames
TOPO=earth_relief_p.nc
ALTITUDE=1000
TILT=55
WIDTH=36
HEIGHT=34

path.txt:

-103.200977925 2.66238364288 9.3053017473 -2.96903213711
-103.19318137 2.70686806019 9.24442247982 -2.97689213963
-103.185462648 2.75136617533 9.18055669722 -2.98484935208

Create those 3 files and the global 30s grid and run

gmt movie main.sh -Iinclude.sh -CHD -Tpath.txt -NMOR -W/tmp/MOR -Fmp4

and examine the 3 PNG files in /tmp/MOR (can also view the exciting 3 frame MOR.mpg in the top dir.

[anbj]

Thanks.

Getting:

$ gmt grdcut @earth_relief_30s_p.grd -Rd -Gearth_relief_p.nc
grdcut [NOTICE]: Remote data courtesy of GMT data server oceania [http://oceania.generic-mapping-tools.org]

grdcut [NOTICE]: SRTM15 Earth Relief v2.5.5 at 30x30 arc seconds reduced by Gaussian Cartesian filtering (1 km fullwidth) [Tozer et al., 2019].
grdcut [NOTICE]:   -> Download grid file [853M]: earth_relief_30s_p/
grdcut [ERROR]: Libcurl Error: HTTP response code said error
grdcut [ERROR]: Probably means @earth_relief_30s_p.grd does not exist on the remote server
grdcut [ERROR]: Unable to obtain remote file @earth_relief_30s_p.grd

[PaulWessel]

Sorry:

gmt grdcut @earth_relief_30s_p -Rd -Gearth_relief_p.nc

[anbj]

All three frames look good when I run it.

I've had similar problems, and I think gmt clear all 'fixed' it.
I think I made an issue about such a thing some years ago.
Was too fuzzy to debug, so I guess it was closed without figuring out what actually happened.
I suspected stochastic funny stuff during tile download and stitching.
This also would explain why deleting the files, and re-downloading, might fix it.

[PaulWessel]

Clear would only help if we were assembling grids inside the movie loop. Here, we have a final grid that is just used repeatedly so it obviously is not changing between frames. Perhaps this is a macOS process thing.

[PaulWessel]

Maybe you can remote the /tmp/MOR dir, add -Qs to the movie command, and zip up the /tmp/MOR dir with the unexecuted scripts and parameter files?

[anbj]

Ask and thou shall receive.
mor.tar.gz

[anbj]

Clear would only help if we were assembling grids inside the movie loop. Here, we have a final grid that is just used repeatedly so it obviously is not changing between frames. Perhaps this is a macOS process thing.

Hmm, yes.
I do think I remember that my problem was related to when the dataset was not already downloaded before movie script execution. Then several movie-processess would try to fetch tiles at the same time, causing chaos.