We are regularly cutting and writing hundreds or even thousands of subsets (approx 650x650m) from a single S1-subswath so the overhead this would introduce is immense and a no go for us. Please be in touch with us tomorrow when you are looking into it. Perhaps we can find a temporary fix together that works for us if a decent fix turns out to be difficult!
Best regards,
Sven.
Adding the NodeId to the exception text, as you suggested, is not a problem. That’s done and will be released soon. Maybe this afternoon or later this week. Some other things need to be fixed and clarified before the update.
If you need more control about the process I would suggest to write your own little program and use the SNAP API. You could also write a special operator for your task. You can either use Java or Python.
Ok thanks! Just out of curiosity, did you find out what caused the exception in the NetCDF writer? Is it, as I expect, an attempt to write a file without valid data pixels? If so, it should not be too hard to catch this case in the operator itself right? I will have one of my developers to look at it if you guys are unable to provide additonal support at this time… Perhaps some pointers for us where to look in the source code?
The NetCDF error didn’t happened any more. The Subset operator checks already if there is an intersection or not.
That’s the OperatorException: Subset: No intersection with source product boundary
Sure we can give some support to your developers (we are talking about it already via mail).
As an entry point the developer guide might be of interest for your developers.
True, the netcdf exception is circumvented by the new test in the subsetOp, so an exception is now thrown earlier with indeed a more sensible error msg. However, in practice, this doesn’t change anything for us. Still the processing of our GRAPH-file is interrupted because one subset does not intersect the source product. Do you see any mechanism in which we can make the GPT to ignore this exception (make it a warning) and just skip the write if it doesn’t intersect (or write an empty netcdf that is also fine!)?
I am looking forward to hear about the support options.
Sven.
FINALLY! 
In the latest update I just published, the Subset operator does not throw the exception any more.
Instead no file will be written. Just a warning is shown on the console that there was no intersection.
Great! Thanks alot! We are going to try it right now!
In which branch/where have you commit this update, so we can try?
Thanks.
It is on the master branch and also on the 3.x maintenance branch.
It’s also released to our update center. And SNAP installations can be updated.
Thanks Marco.
I tried to update my installation of the master branch (4.0-alpha-01) using the indications found in https://senbox.atlassian.net/wiki/display/SNAP/Update+SNAP+from+the+command+line, however I receive:
snap --nosplash --nogui --modules --update-all
Updates not found
updates=0
or
snap --nosplash --nogui --modules --update org.esa.snap.snap.gpf
Nothing to update. The pattern [org.esa.snap.snap.gpf] has no match among available updates.
updates=0
Is there any additional step I should do? Thank you.
OK, I tried updating the stable version of snap3.0 instead and I could find your changes. Will try this version now. Thanks
For the 4.0 branch there is no updatecenter yet. Because 4.0 is not released.
If you build the master (4.0) branch your self you have the change already in the source code.
It seems to be working. We don’t get an exception anymore. Actually, we don’t get any feedback - we don’t see the warning in the standard output. Is it sent somewhere else?
No actually is not written somewhere else. You should see a line similar to this one.
WARNING: org.esa.snap.core.gpf.common.SubsetOp: No intersection with source product boundary S2A_OPER_MTD_SAFL1C_PDMC_20160128T093128_R108_V20160126T104630_20160126T104630
Have you build it on your own or do you use the installed and updated application?
While testing, I fear, I have found some major problem. For me it seems that gpt does not use the updated modules only those which are already installed.
I will investigate this further.
I am using the installed and updated version, not my own build.
I actually always received the following message when running gpt:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/s1tbx-snap3.0/snap/modules/ext/org.esa.snap.snap-netcdf/org-slf4j/slf4j-simple.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/s1tbx-snap3.0/bin/…/snap/modules/ext/org.esa.snap.snap-netcdf/org-slf4j/slf4j-simple.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
Perhaps this is preventing me from receiving the warnings?
Don’t think so. If so you should still get the exception as I do.
So maybe it works on linux.
The reason why it is not logged is an other issue I think. I check this later.
The log messages are somehow swallowed by the executables (gpt/gpt.exe) generated by our installer.
If you invoke java in your own script the logs are shown.
Try the following script. Adapt the SNAP_HOME variable to your installation path and provide the gpt parameters as usual at the end. Instead of my graph file “/home/tester/multiGraph.xml”
SNAP_HOME='/home/tester/testing/SUT/snap-sentinel_3'
$SNAP_HOME/jre/bin/java -Dsnap.mainClass=org.esa.snap.core.gpf.main.GPT -Dsnap.home=$SNAP_HOME -Djava.awt.headless=true -Dsnap.log.level=INFO -cp $SNAP_HOME/snap/modules/ext/org.esa.snap.snap-core/org-esa-snap/snap-runtime.jar org.esa.snap.runtime.Launcher -e /home/tester/multiGraph.xml
This is the issue for it: SNAP-461
Regarding the not considered module updates on windows, I’ve found out why it is not working.
Please see this issue: SNAP-462
Hi Marco,
I lost track a bit in your discussion with Joaquim. Did you find (and solve?) in the end something causing us not to see the “No intersection warning”? I am still not seeing any but this could have to do with the fact that we have not updated for several days now…
Sven.
The missing logging was caused by our installer. It will be fixed with the next release.
In the mean time you can add the following line to the gpt.vmoptions file:
-Dinstall4j.noLoggingFix=true
This should ensure that the normal logging takes places.
Best Regards
Marco