Hi, I’m running a simple script, the just the demo done at LPS (“openEO demo 02 - NDVI Bonn”).
And for some reason this gets queued. I tried two days ago the same happened and it failed.
Here’s the reference:
ref: r-b0ed64fe3ee0459d9344615752ed637b
What could I do about this?
Many thanks in advance!
The reference (r-b0ed64fe...) you gave is just a request id (starts with r-), which is not as informative as a real job id.
Anyway, I could track the request id in the openeo platform aggregator logs and found that the actual job id is eodc-jb-85f996ce-46ba-4b3b-ae0c-9aea8ac32db2.
So this is a job running on EODC, which I can’t dig further into. @lukas.weidenholzer or @sean.hoyal can you provide further assistance?
Quick update - there were two issues with this job:
a faulty deployment, which caused the dask cluster initialisation to fail - this has been fixed as of this morning!
a data access issue for the specific query you were trying to run - for some reason our processing backend cannot find the requested data in opendatacube. I’m currently looking into this, and will report back on my findings by EOB today.
Thanks for reporting this and apologies for the inconvenience!!
Hi again - I’ve concluded my investigation with the following outcome:
There is a problem that prevents results from the ndvi process from being saved. A fix is underway, but won’t be deployed until tomorrow.
The specific spatial extent over Rome you’ve queried does not contain any data. This is definitely unexpected and something we need to look into; the boa_sentinel_2 collection should definitely contain data there, but it’s possible that it hasn’t been indexed into opendatacube correctly. Since I’m not familiar with how the indexing step works, I’ll have to pass this on to @sean.hoyal to look into after he returns from holiday on 03.01.2023!
Are you particularly interested in this spatial extent? In case this was just a random extent for testing, I was able to get your process graph to run through (assuming the fix I’ll deploy tomorrow!) using the same extent just shifted north a bit (although I haven’t inspected the results).
I will also add this case to the unittests for ndvi so this doesn’t happen again!
Hope this helps!
Lukas.
UPDATE: 2022-12-21
Hi once again - just wanted to let you know that I’ve just deployed the fix to the ndvi process. I was able to get your process graph to run through on the following spatial extent:
As mentioned, we’ll investigate this lack of data as soon as the relevant folks are back from holidays.
If there’s any further issues with this, please let me know!
Lukas.
I have double checked the file system and the open data cube is correct, there is no data for the given spatial extent of job eodc-jb-85f996ce-46ba-4b3b-ae0c-9aea8ac32db2. It’s annoying that currently we are unable to return the logs of no data back to the user.
We are working on providing an aggregated logging solution in order to return these errors to the user. It would provide the relevant feedback for issues like this!
I used the spatial extent that you suggested (check code below). And I get the error (ref: r-0859e2c6fdcc4dc19c71cb3aa003c964).
Perhaps I’m not placing it correctly? Should it be a dictionary?
Hi Sara - the syntax of the load_collection call looks right to me. Unfortunately I wasn’t able to find this job in our backend from the provided reference, so I’d need more information to be able to help.
Could you please post the exact error message that was returned? Also, from the screenshot it’s not obvious at which point in the notebook the error occurs - if it occured after .create_job, then please also share the job id using job.job_id. Thanks!
Dear @sara.f.aparicio,
which account (e-mail address) are you using to run the code? It seems that you do not have any valid role assigned to this account.
You can send the address also to me privatly.