Closed seisman closed 1 year 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
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.
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.
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.
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....
Finished Mars and soon Moon. Boy, takes many many hours to do the solar system!
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.
I think this was fixed for those grids and all others.
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?
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.
Seems weekend was very busy between Nittedal and Honolulu, but was successful later in the evening.
Ah, the Nittedal <-> Honolulu rush. No wonder you had problems.
Mercury:
Pluto:
I'm using GMT 6.4 on Linux.