Traceback (most recent call last): File "<string>", line 72, in <module> File "<string>", line 671, in makeLocalADDEEntry org.python.proxies.__main__$AddeJythonInvalidDatasetError$33 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at org.python.core.PyObject.proxyInit(PyObject.java:200) at org.python.core.Deriveds.dispatch__init__(Deriveds.java:24) at org.python.core.PyBaseExceptionDerived.dispatch__init__(PyBaseExceptionDerived.java:1085) at org.python.core.PyType.type___call__(PyType.java:1713) at org.python.core.PyType.__call__(PyType.java:1696) at org.python.core.PyObject.__call__(PyObject.java:461) at org.python.core.PyObject.__call__(PyObject.java:465) at org.python.pycode._pyx14.makeLocalADDEEntry$67(<string>:683) at org.python.pycode._pyx14.call_function(<string>) at org.python.core.PyTableCode.call(PyTableCode.java:167) at org.python.core.PyBaseCode.call(PyBaseCode.java:307) at org.python.core.PyFunction.function___call__(PyFunction.java:471) at org.python.core.PyFunction.__call__(PyFunction.java:466) at org.python.pycode._pyx61.f$0(<string>:261) at org.python.pycode._pyx61.call_function(<string>) at org.python.core.PyTableCode.call(PyTableCode.java:167) at org.python.core.PyCode.call(PyCode.java:18) at org.python.core.Py.runCode(Py.java:1386) at org.python.core.Py.exec(Py.java:1430) at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:267) at ucar.unidata.idv.ui.ImageGenerator.processScriptFile(ImageGenerator.java:924) at ucar.unidata.idv.ui.ImageGenerator.processScriptFile(ImageGenerator.java:895) at ucar.unidata.idv.ui.ImageGenerator.processScriptFiles(ImageGenerator.java:874) at ucar.unidata.idv.ArgsManager$1.run(ArgsManager.java:407) at ucar.unidata.idv.ArgsManager.runInitRunnables(ArgsManager.java:454) at ucar.unidata.idv.ArgsManager.access$000(ArgsManager.java:73) at ucar.unidata.idv.ArgsManager$3.run(ArgsManager.java:433) at ucar.unidata.util.Misc$3.run(Misc.java:1243)
__main__.AddeJythonInvalidDatasetError: Check for valid dataset/descriptor. (error code: 0) Killing Xvnc process ID 158521 Finished
I believe your command should work as-is if you change your dataset= to use all capital letters (e.g. dataset='SANDWICH'). When creating a local dataset through the GUI using the local ADDE Data Manager, it forces the user to use only capital letters. I'll check if an inquiry for this exists, and if not I'll create one. A case like this could either error, telling the user to use capital letters. Or, it could create the local dataset and change the dataset to all capital letters, while printing out a message letting the user know what happened.
Local servers for ABI data are available on OS X and Linux, not on Windows.
While local servers are available on OS X and Linux, as of the 10/16/2017 nightly, the local servers are from McIDAS-X 2016.1. With this, one caveat is that for each time of data included in the dataset, you must have band 1 and any other band. For example, if you are interested in band 5, you need to have bands 1 and 5 for each timestep included in the directory. If you are only interested in band 1, then you must have band 1 and any other band (e.g. band 8) included in the directory. Updating local servers in McV is on our list of inquiries to include in McV 1.7, but I can't make any promises on when this will be done. I'll make a note to update you once local servers are updated. Once the servers are updated, this restriction of needing band 1 will no longer be an issue.
Please let me know if you have any questions/comments - Bob
Thanks Bob, that was the issue. Second question: Do you know if there is a way to access the DQF parameters that would align with the ADDE formatted requests? These parameters do not seem to be applied to the AREA information but are important in many cases.
Via ADDE there is no way to get at the DQF parameters. This would require a change to the ADDE servers, so I wrote up McIDAS-X Inquiry 16463 for evaluation.
You can access these DQF fields if you load the data in as a gridded data source, either through the General>Files/Directories chooser through the GUI or loadGrid() through scripting.
As a gridded data source, the DQF parameters won't match exactly with the locations in the AREA file, as far as I know. Is this correct?
I think this might put us back to the question of being able to revert back to the fixed grid format from a file loaded as an AREA. I am not sure if we ever resolved this question?
It looks like you are correct that there is a shift in the data when comparing the two methods of loading the data. I displayed FD band 11 radiance through local ADDE and from the General>Files/Directories chooser. Specifically, with this band, there's a 1 pixel shift in both the x and the y when comparing the displays (both with the Image Display display type).
Currently, there is no way to use the new fixed grid utility with ADDE. This is part of Inquiry 2526.
