Error Executing Derived Parameter on Several Products

[live4right]

Hi Michael,

Since I am using the Unidata AWIPS II I figured this would be the place to put this issue. When loading products such as Computed Cape and others they act as if they are loading then they give the following error "Multiple frames: com.raytheon.uf.common.inventory.exception.DataCubeException: com.raytheon.uf.common.inventory.exception.DataCubeException: Error executing Derived Parameter."

Do you know why they do this or if there is a way to fix them so they don't do that anymore? Thanks

--Carl

[jaredwsmith]

Here's the fix on macOS:

• Make sure that jspawnhelper is executable (see #95)
• Add your system Python to the list of interpreters in CAVE Preferences->PyDev->Interpreters->Python Interpreter
• At a terminal, run: pip install -I jep==3.4.1 (any other version of jep seems to crash CAVE)
• Find the site-packages directory that corresponds to your Python installation (mine is in /usr/local/lib/python2.7/site-packages/, so I'll refer to that path going forward)
• Run this at a terminal: sudo cp /usr/local/lib/python2.7/site-packages/jep/libjep.jnilib /Library/Java/Extensions -- you will need to provide your password
• Start CAVE
• Pick any previously non-working product (GFS 20km 250mb height verified nicely and quickly for me)

Will verify a Windows-specific fix later tonight. Stay tuned, @live4right...

[live4right]

For me, the 250mb heights always loaded, a good test would be say the 250mb isobaric wind field as barbs, that product has never loaded for me on the Unidata AWIPS platforms. But thanks for looking into this issue... :) --Carl

[jaredwsmith]

Was diving into this some more on Windows tonight (Windows 10 Anniversary Edition) and noticed a few things...

• I was thrown into debug mode, so any meaningful logging was all but squelched
• Despite installing Miniconda, numpy and jep, still could not get wind barbs
• AlertViz was not throwing any red banners when products failed to load

Have a feeling this will be better sorted out by Build 16. Initial release on a platform seems to be rough around the edges...

[ipatrol]

Well doing basically the same thing (trying to get wind data from a model) causes an outright crash on Linux as of the current version in the repositories (16.2.2-3).

Attached are several logs, and some summarized gdb output:

hs_err_pid9858.txt hs_err_pid6211.txt hs_err_pid5251.txt hs_err_pid13569.txt hs_err_pid12719.txt cave_20170208_logs.txt cave_20170208_logs.2.txt gdb-pid13567.txt

[mjames-upc]

@ipatrol I'm seeing /usr/lib64/python2.7/site-packages/jep/jep.so in the stacktrace in hs_err_pid12719.txt

CAVE is finding jep in /usr/lib64/python2.7 before /awips2/python/lib/python2.7 because the /usr/lib64 version is defined in LD_LIBRARY_PATH already.

LD_LIBRARY_PATH=/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64-debug//lib:/usr/lib64/python2.7/:/usr/lib64/python2.7/site-packages/jep:/awips2/psql/lib:/awips2/postgresql/lib:/awips2/qpid/lib:/awips2/notification/lib64:/awips2/tools/lib:/awips2/python/lib:

/etc/profile.d/awips2.sh is set up to overwrite and define LD_LIBRARY_PATH on login, so if you're adding /usr/lib64 python to PATH and LD_LIBRARY_PATH they should be appended rather than prepended.

You can also control this for specific user accounts on both CAVE and EDEX machines, such as how root's environment is left unchanged in awips2.sh

[ipatrol]

@mjames-upc I did that intentionally as a debugging attempt, but it happened even with the typical environment. I will note that on Linux the software appears to function normally after a (very exhausting) system downgrade back to CentOS 6.8, so something that changed between 6.8 and 7 appears to be at fault, whatever it is.