Hi,

I processed SeaWiFS data  of two dates April 20, 2007 and June 21, 2007 in the interactive mode and selected L2 products sena, senz, sola and solz in output. Surprisingly, when I used shiptrack -> track and image data, I am getting the June solar zenith angle greater than the April Solar zenith angle at the same lat-lon.

Lat       Lon           solz from June 21, 2007 data       solz from April 20, 2007 data
27.54    -90.55       23.1917                                   22.0861

In another software I calculated the solar zenith angle on June 21, 2007 for the same lat-lon and I got 4.13. Could you put some light on what I can do to get the right angles?

Thank you very much.
regards,
Dash  

Dash,

There is nothing wrong with the data.
SeaWiFS saw 27.54N, 90.55W at 19:45:16 GMT on 21 June 2007.
The solar zenith angle for that date/time and location is indeed 23
degrees.

Sean

Hi Sean,

Thanks for your reply. The files I am using are "S2007172192431.L1A_MLAC.x.hdf" and "S2007110185538.L1A_MLAC.x.hdf" of June 21 and April 20, 2007 respectively. So, I understand form the file name that the June overpass time is at 19:24:31 GMT and April overpass time is at 18:55:38 GMT. When you said the June overpass time is at 19:45:16 GMT, did you mean the overpass time over that pixel? The pixel in question is located around the center of the scene. I am little confused to think that SeaWiFS would take this long (~20 mins) to scan one scene. Is there a way to know the exact overpass time over a pixel in SeaDAS?   

If it is 19:45:16 GMT, then as the time difference between April and June overpasses is around 50 mins,  a higher solar zenith in June than in April is understandable but if it is 19:24:31 GMT as there is around 30 mins difference, can June solar zenith would still be higher than April solar zenith taking the higher solar elevation angle in June than in April into consideration?

I am really sorry to post so many questions at a time, but I need one more information too. Is there any way I can output relative azimuth angle for that same pixel or does simple subtraction of solar-satellite azimuth would get me the relative azimuth angle SeaDAS used for processing?

Thanks so much for your time! I will look forward to hear from you.
regards,
Dash       

Dash,

The file name is based on the time of the first scan line in the file - but for MLAC we have set
the file name based on the name of the GAC file for that orbit.  The time I reported is the time
SeaWiFS imaged the scan line that contains the lat/lon listed in your previous post.

It takes about 99 minutes for a SeaWiFS orbit, so about 47 minutes to go pole to pole. 

In SeaDAS, the cursor position dialog box will report the date/time lat/lon raw and geophysical value
for the pixel under the cursor.

Yes, relative azimuth is easily calculated from solar and sensor azimuth:
     sensor azimuth - 180. - Solar azimuth

Regards,
Sean

Dear Sean,

Thanks so much for clarifying my doubts. I had batch processed my images, that's why the time for the pixel was not visible in the cursor position dialog box. Now, I reprocessed those using GUI and I see the time as 19:45:16 GMT over that pixel. With this time the other software I was using gave same solar zenith angle. Thank you very much.

About the relative azimuth, for that pixel in June 21, 2007 SeaWiFS data I have got sensor azimuth 260.344 and solar azimuth 265.533. When I am doing  260.344 - 180 - 265.533, I am getting -185.189. Does SeaDAS use absolute value of relative azimuth or it uses negative relative azimuths???

thanks,
Dash 

We use azimuths in the range of +/- 180 degrees
If you don't like azimuths outside +/-180, you could do this:

   if (relaz < -180.) then relaz = relaz + 360.0
   if (relaz > 180.0) then relaz = relaz - 360.0

Sean

Dear Sean,

Thank you very much for your help.

regards,
Dash

Dear Sean,

May I get the citation or the website, which I can cite for this information regarding relative azimuth?

Thanks very much,
Dash

Dash,

There really isn't a reference to cite for this as it is simply
a way to get azimuths in the range of +/-180 degrees.

Sean

Dash,

It all depends upon perspective - relative to the solar plane.
A relative azimuth of zero,  calculated as sensor azimuth - solar azimuth would
suggest the sun is in front of the sensor.   The -180 doesn't change the plane, just
suggests that the sun is behind the sensor.  This is implicit in much of the code
(for example, the glint estimation using Cox-Munk).

Sean

Dash,

The relative azimuth convention is historical. It is generally referred to by folks in the community as the "Gordon convention", and is a common source of confusion, especially when sharing code with other groups.  I'm not sure if it is documented anywhere, except perhaps in Gordon's PhD thesis.  Even the MODIS ATBD that he wrote refers to relative azimuth as sena - sola, but there is no figure to show the vectors.  I believe the convention arises because Gordon originally defined the sun vector in the down direction (sun to surface), so zero relative azimuth implies specular reflection.  We and others generally define both the Sun vector and sensor vector in the upward direction, so to get Gordon's relative azimuth we must subtract 180.  We must follow the Gordon convention because that is how the atmospheric tables are parameterized.  The sign does not matter, because we take the absolute value when doing table look-ups and we use the cosine when computing scattering angles.

Maybe if you search through all the Gordon et al. papers you can find a citation for the convention.  I know I've seen it defined somewhere, but I've had no luck in finding it.  Let me know if you do.

-- bryan

Thank you very much Bryan and Sean. I am doing a sensor inter-comparison work, which is why I wanted to maintain consistency in the input angles. Initially, I was calculating rel_az as just sena-sola for OCM and doing the same for SeaWiFS, so, I was getting very different Rrs than that of SeaDAS processed Rrs. Now, I followed this procedure of rel_az calculation for both SeaWiFS and OCM, and I am getting much better comparison with SeaDAS processed Rrs. However, I have not taken absolute value as per your post Bryan.

First, I did: rel_az= sena- 180.0 -sola
and then I did: if (rel_az < -180.0) then rel_az = rel_az + 360.0
                     if (rel_az > 180.0) then rel_az = rel_az - 360.0

Using these two steps, I got my final rel_az values between +/- 180. When you said you take the absolute value, you meant doing the second step of what I did, right?

Thanks so much for your help.
regards,
Dash

What you describe is what is done within the code.  The absolute value is only taken within the aerosol model table look-up process (and then disgarded), since the tables are in 0-180 relative azimuth, and the sign of relative azimuth does not matter, since scattering is symetric around zero azimuth.  The signed value in -180 to 180 is what we retain within the code,  because it may someday be useful to know.

Hi Bryan,

Thank you very much for your response. I was asking about these angles in the context of calculating Lr. As you said, if this is how it is in the code, then I guess I have done everything right!

Thanks so much for going through my question and replying.
regards,
Dash