GenericMappingTools / gmtserver-admin

Cache data and script for managing the GMT data server
GNU Lesser General Public License v3.0
7 stars 3 forks source link

Issues with pluto/mercury 01m dataset #230

Closed seisman closed 9 months ago

seisman commented 10 months ago
gmt grdimage @mercury_relief_01m -png mercury -R0/10/0/10 -Cbatlow
gmt grdimage @pluto_relief_01m -png pluto -R0/10/0/10 -Cbatlow

Mercury: mercury

Pluto: pluto

I'm using GMT 6.4 on Linux.

PaulWessel commented 10 months ago

Confirmed, and think I know why. Just checking that you tried the other resolutions and these two are the only one with the problem?

N00E000.mercury_relief_01m_p.nc: 187200 nodes (5.8%) set to NaN

seisman commented 10 months ago

Just checking that you tried the other resolutions and these two are the only one with the problem?

Yes, others are all good, but I didn't try the full resolution ones.

PaulWessel commented 10 months ago

Those to cases have the odd full resolution (52.0732883317s and 56.25s). Mars also is like that (12.1468873601s) but I suspect my equation for FILTER_WIDTH comes up a bit short for the first two but for Mars we go to 15s. Working on it and will test all.

PaulWessel commented 10 months ago

I have modified the downsample scripts to add a little bit more to the computed filter widths and rebuilding everything (Boy, mars at 12s is slow to filter...). Because we eventually store as 2-byte integers with some internal scale/offset I think even the tiny changes in grids that did not have a problem will cause tiny changes after conversion to integers.

Once finished I will make a PR with the script changes. I think the best solution is to do the full rsync of everthing to candidate once my jobs finish since we have not yet released anything it does not matter that SRTM 2.5.5 products change ±0.5 meter.

PaulWessel commented 10 months ago

Good @seisman notice these flaws. A check for NaNs in the filtered files works to notify us for future planets. Also good to give the Makefile some workout:

make make-planets

is now cranking through the full workflow for the 5 planets, followed by

make make-earth

which will do all the Earth data sets.

Hm, the repeated make make makes me want to change the targets to just planets and earth....

PaulWessel commented 10 months ago

Finished Mars and soon Moon. Boy, takes many many hours to do the solar system!

PaulWessel commented 10 months ago

Took almost 8 hours to run make make-planets (now called make planets). Started on make earth which will take all night. Once all is done we can update the candidate server.

Esteban82 commented 9 months ago

I think this was fixed for those grids and all others.

mercury

pluto

PaulWessel commented 9 months ago

Note: I am having ssh disconnect issues when I try to place some of the bigger data set. It gets a fair way and then disconnects. So the candidate server is not fully updated and I would out trying to run the test plots in remote_datasets and some plots did not work. I tracked that down to missing files on candidate even though the were made in my staging area and "attempted" placed with make place-earth-gebco for instance. Any foolproof way to beat this problem?

anbj commented 9 months ago

Start your ssh session inside a tmux(1) (or screen(1)) session. If the network fails, you can re-attach to the session. But of course, if transferring data from A to B over the network, and the connection drops, you'll have problems issues no matter what.

PaulWessel commented 9 months ago

Seems weekend was very busy between Nittedal and Honolulu, but was successful later in the evening.

anbj commented 9 months ago

Ah, the Nittedal <-> Honolulu rush. No wonder you had problems.