Hello,
I am digging out some older coherence generation scripts in order to run them on a CDSE VM where I installed a fresh version 11. The idea is to read directly from the (mounted) /eodata archive, instead of first transfering a zipped set to a local box. Thus, I would like to run gpt as follows:
# Generate subswath coherence for the 3 subswaths of the first pair
/home/eouser/esa-snap/bin/gpt /home/eouser/S1/TOPSAR_Coherence_Single_Swath.xml -Pinfile_master=/eodata/Sentine
l-1/SAR/SLC/2018/06/09/S1A_IW_SLC__1SDV_20180609T044158_20180609T044228_022275_026919_210A.SAFE/manifest.safe -
Pinfile_slave=/eodata/Sentinel-1/SAR/SLC/2018/06/15/S1B_IW_SLC__1SDV_20180615T044117_20180615T044147_011379_014
E5C_7EA0.SAFE/manifest.safe -Psub=1 -Poutfile=/home/eouser/scratch/S1A_S1B_20180609T044158_20180615T044117_coh_
IW1.dim
However, I get:
Caused by: java.io.IOException: eu.esa.sar.io.sentinel1.Sentinel1ProductReader
[input=/eodata/Sentinel-1/SAR/SLC/2018/06/09/S1A_IW_SLC__1SDV_20180609T044158_20180609T044228_022275_026919_210A.SAFE/manifest.safe]:
Product is corrupt or incomplete
(idem, without /manifest.safe)
which is obviously non-sense as I can list the full .SAFE directory.
Does gpt have an issue with reading s3fs mounts?
I could, in principle, create a zip archive on the VM’s attached volume, but that seems rather daft.
Anybody ran into this problem?
G.
PS. I see this as well at start up, but doesn’t seem to stop things. Not nice for a fresh install, though.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.esa.snap.runtime.Engine (file:/home/eouser/esa-snap/snap/modules/ext/org.esa.snap.snap-core/org-esa-snap/snap-runtime.jar) to method java.lang.ClassLoader.initializePath(java.lang.String)
WARNING: Please consider reporting this to the maintainers of org.esa.snap.runtime.Engine
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
UPDATE 24/01/2025:
A workaround is to copy from /eodata to the VM attached volume, which more or less confirms that it links to the inability to read from s3fs mounts. Very awkward! Since ESA does not make RTC or coherence available systematically, the least they could do is to ensure that you can use CDSE cloud infrastructure to do so.