Integrated Sounding System
Summary of the Fix
I've figured out how to get NIMA running on the ISS ship data from CLIMODE. There were two issues. The first was that the ISS antenna angles in the POP radar parameter file were multiples of 45 degrees. NIMA tries to map an azimuth to a general direction like East or North, and it does that by fitting each azimuth into a quadrant of the compass. For examples, 315 to 45 are north. However, where the angles fell on those boundaries, the beams didn't all get unique directions, and NIMA aborts with a complaint about and unknown scan strategy. The workaround for this was to skew the quadrants in the NIMA code so that our azimuths at CLIMODE were given unique directions.
The second issue was that POP writes the current location into new headers. NIMA noticed these header changes and aborted. The fix for that was to change the NIMA code to ignore changes in location.
Note on Compiling NIMA
These are notes about what I had to do to get NIMA to compile on iss2.
I installed the rpm for compat-libf2c-32.i386, to get the g2c library. Then I created a link: /opt/local/nima/lib/libg2c.so -> /usr/lib/libg2c.so.0
There are a few source directories with a Makefile.wp but no Makefile, so those directories needed a link from Makefile.wp (or sometimes Makefile.nima) to Makefile.
Needed to add a link in the /opt/local/nima/include to dsserver/include.
Needed to add /usr/include/netcdf-3 to LOC_INCLUDES in the wp_netcdf module's Makefile.
Sourced needed_env_vars.NIMA in build_libs.csh and build_exes.csh, then just run those in order and hope for the best.
Changed Profiler::profilerEqual() to ignore changes in frequency and position. It also writes a message to stderr about which parameters were different.
Changed Beam::setOrientation() to include some skew so that the 45 degree angles would end up with unique orientations.
Background
We're having a problem with NIMA on the CLIMODE ship spectra. After running through the RASS sequence, wppp finishes with the messages below:
INFO: No candidate atmospheric features.
wppp.iss: DEBUG: NIMA moments calculated for yV22 Acoustic @ 00:03:16
wppp.iss: DEBUG: NIMA moments calculated for yV22 ClearAir @ 00:03:36
INFO: No candidate atmospheric features.
wppp.iss: DEBUG: NIMA moments calculated for yV22 Acoustic @ 00:03:36
wppp.iss: DEBUG: NIMA moments calculated for yV22 ClearAir @ 00:03:56
INFO: No candidate atmospheric features.
wppp.iss: DEBUG: NIMA moments calculated for yV22 Acoustic @ 00:03:56
wppp.iss: WARNING: Profiler: East (+X) offset 45.0 inconsistant with West (
-X) 315.0 Delta: 270
wppp.iss: WARNING: Unknown scan strategy with 3 oblique and 2 vertical beams
wppp.iss: ERROR: Profiler Parameters Changed. Exiting.
wppp -i iss
config file: /iss/nima/etc/wppp.conf
LE output: LOG=D07040A.log<1,900><950,950>
Input Spc File: /iss/nima/etc/spc/D07040A.SPC
I cannot find an explanation for the message about inconsistent beam directions. The POP configuration pages and the profile display all show the correct angles for the beams. If I look at the beam configuration with popexam, the beam angles look correct. So I don't know where NIMA is determining that the angles have the wrong offset. Perhaps it is an artifact of how ShipPOP combines the beams?
That said, what do we expect NIMA to do with the ship spectra? Do we just want them cleaned up, even if we can't then get winds from them because NIMA does not use the navigation data?
I've attached the first part of the SPC data from day 40.
I think on Wednesday, 7 Feb, I moved the current header and data file out of the radar data directory on the PC, in the hopes that POP would start over with a new header that was not corrupted. However, the problem continued. Now I'm thinking I need to find a way to examine the par file and make sure it looks ok and is not somehow corrupted, otherwise maybe there's a way to recreate the par file.
I've been looking into the NIMA source. The warning message about beams not being 180 degrees apart comes from libs/Wp/src/Profiler/Profiler.cc. Then there is a meathod Beam::setOrientation() which tries to assign an ordinal direction to each oblique beam. It does that by finding out what quadrant the beam direction lies in. However, it looks like it might break down when the beam directions fall exactly on the quadrant boundaries, such as 45, 135, 225, and 315, since one beam might actually fall in more than one quadrant, or rather two beams might both be assigned the same ordinal direction. I've tried changing that method so use different boundaries, but I'm still working out how to recompile it.
2007-02-12
Adding one degree to the beam azimuths seems to get around the unknown scan strategy warning. On day 043, NIMA gets past RASS and through the first 15 minutes before exiting with the message about changed parameters:
wppp.iss: DEBUG: NIMA moments calculated for xV21 Vert (+Z) @ 00:13:47
wppp.iss: DEBUG: NIMA moments calculated for yV22 Vert (+Z) @ 00:14:16
wppp.iss: DEBUG: NIMA moments calculated for y+38 West (-X) @ 00:14:44
wppp.iss: DEBUG: NIMA moments calculated for x+25 North (+Y) @ 00:15:12
wppp.iss: DEBUG: NIMA moments calculated for xV21 Vert (+Z) @ 00:15:40
wppp.iss: ERROR: Profiler Parameters Changed. Exiting.
wppp -i iss
config file: /iss/nima/etc/wppp.conf
LE output: LOG=D07043A.log<1,900><950,950>
Input Spc File: /iss/nima/etc/spc/D07043A.SPC
I can't figure out what the parameter change could be that NIMA doesn't like...