Earthdata Forum

Hi - I've been struggling with trying to port the SeaDAS version of QAAv6 (qaa.c) to R.  It should be a simple thing to do, but I can't get my code to reproduce the same values of a_488_qaa and b_488_qaa that come from SeaDAS (v7.5) when given the same input Rrs spectrum.  The details of the differences may be the subject of a subsequent query, but for now I have question that is more fundamental to SeaDAS.  In an earlier query (https://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?pid=39162) I learned that the values of band-averaged pure water absorption (aw) and back-scattering (bbw) could be found in ${SEADAS_HOME}/ocssw/share/modis/aqua/msl12_sensor_info.dat.  I used these values in my code.  Looking at the output hdf files, however, I find that the values apparently used by SeaDAS are (1) different from those in the msl12_sensor_info.dat file and (2) changed in 2019.  I should note that I produced the L2 files from L1 data using l2gen.  I suppose I could understand a change in the band-pass coefficients from year-to-year but why isn't this reflected in the sensor_info.dat file?  Below I use the aw data as an example (the same holds for the bbw values).

Excerpt from msl12_sensor_info.dat:

#
# Band-averaged water absorption
#
aw(1) = 2.030E-02
aw(2) = 1.110E-02
aw(3) = 1.034E-02
aw(4) = 1.676E-02
aw(5) = 4.494E-02
aw(6) = 5.491E-02
aw(7) = 5.839E-02
aw(8) = 3.458E-01
aw(9) = 4.923E-01
aw(10) = 5.116E-01
aw(11) = 2.800E+00

Excerpt a pre-2019 L2 file (same values from 2002-2018):

data:

aw = 0.004883362 , 0.006377468 , 0.01022767 , 0.01374114 , 0.0429368 ,
    0.05057243 , 0.05771586 , 0.3185345 , 0.4249509 , 0.4522105 , 2.829075 ,
    4.345139 , 4.637105 , 116.1812 , 642.3748 , 2557.636  ;

Excerpt from 2019 L2 file

data:

aw = 0.004640989 , 0.007098098 , 0.01049904 , 0.01457921 , 0.04393521 ,
    0.05337547 , 0.05964877 , 0.3266578 , 0.4339156 , 0.4609708 , 2.84832 ,
    4.421082 , 4.748336 , 115.1705 , 635.6376 , 2512.733  ;

Thanks, Barry

Barry,

The change in aw for SeaDAS-produced L2 data is because there was a bug of sorts in the code that read the water_spectra.dat file.
This issue was one of assuming - and you know what that means...  The code assumed the file would either contain data or header with specific delineation (leading "/" or "!").
The file was hand edited and the editor added a blank line at the top of the file and two header lines that did not have the expected delineation.
The result was a three element shift in the data array.   Once this error was identified, we corrected the file, but also modified the code to read a netCDF version of the data
so this problem would never happen again :grin:  We released that with SeaDAS, however, the implementation in production will wait until the next reprocessing so as to not introduce a bias in the products (even though it's at bit wrong right now).  If you look at a L2 file we produced, the aw data will be consistent through the mission.

That explains the shift in values you see.  As for why the values in the "sensor_band_parameters/aw" data set differ, well, that's because the values in the msl12_sensor.dat file are fully convolved with the spectral response function of the sensor, while the values in sensor_band_parameters/aw are nominal 11nm square bandpass values that correspond to the 11nm bandpass Rrs data in the L2 files.

Sean

Good morning, Sean.  Thanks for the explanation.   As I noted, this came up as part of my attempt to port qaa.c to R so I can use it in some external applications.  If I understand correctly, I should be using the aw and bbw values that show up in the output L2 netcdf file to be consistent with what SeaDAS is doing internally (rather than those in the msl12_sensor.dat file).   That makes sense to me.  I'm afraid this won't solve my problem of not being able to match the SeaDAS produced a_488_qaa and b_488_qaa, but it might (should) reduce the magnitude of the errors in the range of values where my calculations are fairly close to those from SeaDAS. 

As always, I really appreciate the quick reply.

Best, Barry