Changes to l2bin?

[khyde]

Hello,

I was wondering if there were any changes to the binning codes between SeaDAS 7.5 and 7.5.3? Since updating to 7.5.3, I've noticed a shift in the data when I remap from a L2 binned file created by l2bin (at a 2 km resolution).  Attached are two images, the OLD (left) was created using 7.5.1 and the NEW (right) was created with 7.5.3, both from the same set of input level 2 files.  Notice the shift to the right of the missing grey pixels around Cape Code and Nantucket.  Nothing else has changed on my end, except for updating SeaDAS.  A colleague of mine has also read in my files in ArcGIS and noticed the shift in the data as well so I'm wondering if something with the geolocation changed. 

Thanks,
Kim
attachment 1

attachment 2

[OB.DAACx - SeanBailey]

Kim,

There were changes to the code, but nothing that should cause the effect you describe. 
I just processed a MODIS-Aqua L2 scene over Long Island sound using the binaries distributed with v7.5.1 and the latest version. 
I used l2bin/l3mapgen and the resulting output files were identical. 

So, can you either make your files available so we can see whats up or at least post (as attachments) the output of ncdump -h for the l2bin files?

Sean

[khyde]

Hi Sean,

The files are too large to upload, but I put the ncdump output in a txt file.  Note, I am using my own IDL mapping routines to map the files, but those have not changed in several years.

Also, when I looked at the bin data, it does appear that the bin numbers are different (by 2) in each file. 
Here are the first 10 bin numbers from the OLD file:
64284460    64284461    64284462    64284464    64284465    64300623    64300624    64300625    64300626    64300627    64300628
And the first 10 bin numbers from the NEW files:
64284462    64284463    64284464    64284466    64284467    64300625    64300626    64300627    64300628    64300629    64300630

Thanks for looking into this for me.

Kim
attachment 1

[OB.DAACx - SeanBailey]

Kim,

Try mapping them with l3mapgen.  The newer version uses 64bit bin numbers and lon/lat arrays internally, but will write out 32bit values unlesss 64bit is required, which it is for sub-kilometer resolutions.  This internal higher precision *may* explain the slight difference in the number of bins, as it's possible that data may occasionally fall into a different bin. 

Sean

[khyde]

Hi Sean,

I used l3mapgen to create these two images from the OLD and NEW l2bin files and I'm still seeing a shift in the data if you toggle between them.  You can also see some differences at the left and right edges if you look at them side by side.

projection = lambert
resolution = 1km
north = 42
south = 39.7
east = -69
west = -72

When you said " The newer version uses 64bit bin numbers and lon/lat arrays internally", am I correct in assuming that you are referring to the newer version of l2bin?  If that is what is causing the shift, would that mean the lats and lons I had previously associated for each bin needs to be updated?  I've been using bin2ll to generate the lon/lat values for the bins, but if your internal lon/lat arrays have changed, will that code still generate correct values?  If not, is it possible to get the full array of latitudes and longitudes associated with each bin?  I think if I have that, I can map the new version, but I'm guessing that I may still have some capability issues with my older files (i.e. I would need to know the l2bin version used to create the files in order to match them up correctly or I would need to regenerate all of my L3B2 files and I would prefer not to do that).

Any other thoughts on how I can correct this shift?

Thanks,
Kim

[OB.DAACx - SeanBailey]

Kim,
Since I can't seem to replicate the problem here, we'll need your bin files to investigate.  Any way you can put them somewhere so we can grab them?
Sean

[khyde]

Hi Sean,
Please let me know if you didn't get the link to the files.
Thanks,
Kim

[OB.DAACx - SeanBailey]

Kim,

Just want to put my email response in the forum for posterity :)  ...with a little more explanation included...


We've identified the issue.  The new binner code computes 4 more bins for the globe than were created by the old binner code (at 2km resolution).  This is because the old code truncated the computation of "latbin" to a float.  The IDL code we made available to read the bin files was written for a time when we only had a 32bit version of the binner, so it also truncated the latbin in the same way.

You should be able to "fix" it locally in your IDL code, assuming you're using the bin2ll code we posted on our website.  In that code, remove the casting to a float for this line:                                       
                                                                                         
latbin=float((i + 0.5) * (180.0d0 / nrows) - 90.0)                                       
                                                                                         
instead, make it this:                                                                   
                                                                                         
latbin=((i + 0.5) * (180.0d0 / nrows) - 90.0)                                            
                                                                                         
The new l3mapgen is happy with the new l2bin output for higher resolution bins, as was the old l3mapgen with the old l2bin output.   New l3mapgen with old l2bin output, not so - same is true for old l3mapgen and new l2bin output.

Rather than "fix" the new l2bin code to truncate the latbin calculation to be consistent with the old binner output...which we verified will "fix" the problem, I suggest you try the IDL fix so you can be internally consistent without having to rebin your older data.  Changing the binner to truncate the latbin would limit the binner to a max resolution of about 11m - fine for now, but if we want to bin future high resolution missions it would be problematic :grin:

Sean