PmagPy Server plotting overlays instead of clearing between plots

[rminnett]

This seems to be happening fairly frequently now (e.g. https://earthref.org/MagIC/19580). I'm not sure if it's a plot server issue or a PmagPy issue, but I can help investigate if necessary.

[Swanson-Hysell]

I think that there are issues both with make_magic_plots.py and the server going on here.

On the make_magic_plots.py side, I ran it locally on this contribution and I get this issue in a plot named Galapagos_POLE_map_t.png which looks to be one of the problematic plots:

However, the purple text is on the server side — not made in make_magic_plots.py so the extra globe being laid on top is likely a server issue.

[njarboe]

@Swanson-Hysell I forgot to tell you that when using make_magic_plots.py to make plots for the website on the server, one needs to set: isServer = True in PmagPy/pmag_env/set_env.py

Then the purple labels are added to the plots. I get the double plots running with the isServer = True so the problem should be in make_magic_plots.py Here the file name is LO/_Galapagos_TY/_POLE_map_t.png in the server filename format.

[Swanson-Hysell]

Good to know. It looks like it must be failing to generate new figures for each different location result. Fixing this will fit with our goal of making plots for each pole.

Can you explain the LO/_Galapagos_TY/_POLE_map_t.png naming scheme to me?

[rminnett]

@njarboe, I committed a fix to pmagpy (https://github.com/PmagPy/PmagPy/issues/667) yesterday. Perhaps you can pull the change on pmagpy-server and start rerunning plots from the most recent contribution going backwards in time to see if it cleans up the plots in the search interface?

[rminnett]

Good to know. It looks like it must be failing to generate new figures for each different location result. Fixing this will fit with our goal of making plots for each pole.

Can you explain the LO/_Galapagos_TY/_POLE_map_t.png naming scheme to me?

@Swanson-Hysell the naming convention starts with identifying which record in the contribution the plot belongs to (contribution level, a specific site or specimen, etc) and ends with the type of plot being made. The plots get put in a folder named with the contribution ID in an S3 bucket, but since site names are only unique within a location, for example, we can't just specify a site and need LO:_[location-name]SI:[site-name]... You'll see some examples of this naming convention applied in several places (e.g. https://github.com/PmagPy/PmagPy/blob/355f34e758681facb8764192c1d4ebf1eb8cbd85/programs/zeq_magic2.py#L708).

In a subsequent pass of implementing the plotting, Lori added support for creating images.txt files that adhere to the MagIC data model and would allow pmagpy to produce plots of any file name associated with a row in the contribution along with additional metadata. In the new version of the FIESTA platform (sometime next year, I suspect), I'll change the way that contributions are built and stored in S3 and add support for these files to be processed after contribution publication, which will speed up the plots view in the search interface since it won't have to traverse an S3 bucket looking for plots dynamically.

[njarboe]

@rminnett I have rerun the plots for Shcherbakova et al. (2008) - https://earthref.org/MagIC/19622 and Engbers et al. (2022) https://earthref.org/MagIC/19609. The correct plots are being made and pushed up to S3 but the overlapping thumbnail issue remains for the display on the contribution summary page for Shcherbakova et al. (2008) and both the thumbnails and plots for Engbers et al. (2022). The thumbnails look fine if you look at them directly on S3 or if you open the image in a new tab. I think there might be a caching issue. The Engbers contribution plot also is still showing overlapping plots even though the S3 image does not (see below).

Engbers (2022) - 19609 thumbnail as seen on S3:

Engbers 19609 thumbnail on current contribution summary

Engbers (2022) - plot as seen on S3:

Engbers (2022) - plot as seen on MagIC website:

[rminnett]

@njarboe the plots look better - let me know if you see any new ones that don't look correct. It does look like a cache issue from S3, so I'll see if I can invalidate the cache:

[njarboe]

@rminnett The new plots do look better. Forgot to mention that. :)