Earthdata Forum

I'm having issues with getanc (both SeaDAS 7.5.3 and 8.1.0 T2021.12). All queries return "*** WARNING: No optimal ___ files found." modis_atteph seems to work fine. Here's an example query (all return the same null result). This exact command worked properly last week (i.e., returned anc files).

> which getanc
/shares/cms_optics/apps/seadas/seadas-8.1/ocssw/bin/getanc
> getanc --disable-download -v -s 2016001002001 -e 2016001002001 --ancdb=/shares/cms_optics/bbb/jpatch/new/junk.db
/shares/cms_optics/bbb/jpatch/new/junk.db
Searching database: /shares/cms_optics/bbb/jpatch/new/junk.db

Input file: None
Sensor : None
Start time: 2016001002001
End time : 2016001002001

OBPG session started
Downloading 2016001002001.anc.server ( 0.00 MBs)
[==================================================]
...Done
*** WARNING: No optimal MET files found.
*** WARNING: No optimal OZONE files found.
*** WARNING: No optimal SST files found.
*** WARNING: No optimal ICE files found.

Created '2016001002001.anc' l2gen parameter text file:



*** WARNING: The following ancillary data types were missing or are not optimal: MET OZONE SST Sea Ice


> modis_atteph --disable-download -v -s 2016001002001 -e 2016001002001 --ancdb=/shares/cms_optics/bbb/jpatch/new/junk.db -m aqua
/shares/cms_optics/bbb/jpatch/new/junk.db
Searching database: /shares/cms_optics/bbb/jpatch/new/junk.db

Input file: None
Sensor : aqua
Start time: 2016001002001
End time : 2016001002001

OBPG session started
Downloading 2016001002001.anc.server ( 0.00 MBs)
[==================================================]
...Done
Found: /shares/cms_optics/apps/seadas/seadas-8.1/ocssw/var/anc/2016/001/PM1ATTNR.P2016001.0000.003
Found: /shares/cms_optics/apps/seadas/seadas-8.1/ocssw/var/anc/2015/365/PM1EPHND.P2015365.1200.003
All required attitude and ephemeris files successfully determined and downloaded.
att1=/shares/cms_optics/apps/seadas/seadas-8.1/ocssw/var/anc/2016/001/PM1ATTNR.P2016001.0000.003
eph1=/shares/cms_optics/apps/seadas/seadas-8.1/ocssw/var/anc/2015/365/PM1EPHND.P2015365.1200.003


- All optimal ancillary data files were determined. -


Note, I get essentially identical returns from SeaDAS7.5.3 (modis_atteph.py works, while getanc.py doesn't).

Hmmm...worked for me:
getanc --disable-download -v -s 2016001002001 -e 2016001002001 --ancdb=junk.db

Running debug binaries...
/awesomepath/coolusername/ocssw/bin
junk.db

Input file: None
Sensor : None
Start time: 2016-01-01T00:20:01
End time : 2016-01-01T00:20:01

OBPG session started
Downloading 2016-01-01T00:20:01.anc.server ( 0.00 MBs)
[==================================================]
...Done
Downloads disabled. The following missing file(s) will not be downloaded:
N201600100_MET_NCEPR2_6h.hdf
N201600106_MET_NCEPR2_6h.hdf
N201600100_O3_AURAOMI_24h.hdf
N201600200_O3_AURAOMI_24h.hdf
N2016001_SST_OIV2AV_24h.nc

Created '2016-01-01T00:20:01.anc' l2gen parameter text file:

icefile=/awesomepath/coolusername/ocssw/var/anc/2016/001/N2016001_SST_OIV2AV_24h.nc
met1=/awesomepath/coolusername/ocssw/var/anc/2016/001/N201600100_MET_NCEPR2_6h.hdf
met2=/awesomepath/coolusername/ocssw/var/anc/2016/001/N201600106_MET_NCEPR2_6h.hdf
met3=/awesomepath/coolusername/ocssw/var/anc/2016/001/N201600106_MET_NCEPR2_6h.hdf
ozone1=/awesomepath/coolusername/ocssw/var/anc/2016/001/N201600100_O3_AURAOMI_24h.hdf
ozone2=/awesomepath/coolusername/ocssw/var/anc/2016/002/N201600200_O3_AURAOMI_24h.hdf
ozone3=/awesomepath/coolusername/ocssw/var/anc/2016/002/N201600200_O3_AURAOMI_24h.hdf
sstfile=/awesomepath/coolusername/ocssw/var/anc/2016/001/N2016001_SST_OIV2AV_24h.nc


- All optimal ancillary data files were determined. -

Now full disclosure, we are having some DB hiccups, so maybe you hit us mid-hiccup?

Sean

Blarg. I'm still getting the errors, both 7.5.3 and 8.1.0 T2021.12. It's been happening since early yesterday at least.

It's happening on several different machines, but all have USF IPs - perhaps we've got a connection issue? But why would modis_atteph work in that instance (under the hood, it's the same as getanc)?

I also notice that you've got
"Running debug binaries..."
in your output, but this is not in mine. Should I be using a different tag? Even if this is the case, it doesn't make sense to me that a call that worked last week is no longer working...

Perhaps I'm missing something else obvious?
-brian

PS, "/awesomepath/coolusername/" is a nice touch...

My output is showing "Running debug binaries" because I've built my code locally with debug on...it's really not important to the process here (one of those "probably should remove that bit" things).

Since you're still having the issue, I'm wondering if it's a "I'm hitting server A, you're hitting server B" situation. I'll have folks look deeper.

Sean

Brian,
Seems that the issue is related to the DB shell game we ran. A stored procedure in the new DB isn't happy. The reason my run worked was that I was using the updated version of getanc which uses a new API that doesn't require the stored procedure that the older API does.

We'll fix the DB issue, but in the meantime you could use the same getanc that I'm using

v8 tags T2022.1 or newer should have it.

Thanks for reporting this - we probably wouldn't have caught it otherwise. Since we can expect every user to update to the latest code, we have to ensure the older code still works...

Sean

Brian,

The DB stored procedure issue has been resolved and getanc behaves as it should once again.

Sean

Awesome! Thanks Sean (et al).
-brian

awesome
very beautiful

tahnks alots boss