The forum is locked.
The Ocean Color Forum has transitioned over to the Earthdata Forum (https://forum.earthdata.nasa.gov/). The information existing below will be retained for historical reference. Please sign into the Earthdata Forum for active user support.
All,
I have gathered together set of scenes on which to test the various
IOP algorithms. These scenes were chosen to cover as wide a range of optical
conditions as possible. Where possible, I've grabbed both the SeaWiFS and
MODIS-Aqua scene for the same day.
I've put these scenes on a web site for you viewing pleasure:
http://oceancolor.gsfc.nasa.gov/MEETINGS/OOXIX/IOP/testscenes.html
The data files (including MET, OZONE, OISST and basic l2gen parameter files)
are available via FTP:
ftp://oceans.gsfc.nasa.gov/iop_workshop/
Regards,
Sean
I have gathered together set of scenes on which to test the various
IOP algorithms. These scenes were chosen to cover as wide a range of optical
conditions as possible. Where possible, I've grabbed both the SeaWiFS and
MODIS-Aqua scene for the same day.
I've put these scenes on a web site for you viewing pleasure:
http://oceancolor.gsfc.nasa.gov/MEETINGS/OOXIX/IOP/testscenes.html
The data files (including MET, OZONE, OISST and basic l2gen parameter files)
are available via FTP:
ftp://oceans.gsfc.nasa.gov/iop_workshop/
Regards,
Sean
Sean,
Looks like an excellent subset of data and will really test each of the models well.
Will you be doing the processing at NASA or do you want us to process the scenes on our own systems?
Tim
Looks like an excellent subset of data and will really test each of the models well.
Will you be doing the processing at NASA or do you want us to process the scenes on our own systems?
Tim
Hi Sean,
The regional scenes are fine but what about global scenes and Level-3 stuff ?
Stephane
The regional scenes are fine but what about global scenes and Level-3 stuff ?
Stephane
Stephane,
I plan to:
1) generate monthly L3 binned products (a, bb, aph, adg) for some candidate approaches and parameterizations.
2) generate monthly L3 binned Rrs.
3) generate L3 products (a, bb, aph, adg) from (2) for comparison to (1).
We are working on a mechanism for step 3 (effectively modifying msl12 to read and write L3 bin format) so that we can run the exact same implementation of any candidate algorithm on both L2 and L3 Rrs, and compare monthlies.
I am planning to use 2005 mar jun sep dec. If you want, I can send you the files from 1 and 2 and you can compare our L2->L3 GSM with your L3->L3 GSM.
-- bryan
I plan to:
1) generate monthly L3 binned products (a, bb, aph, adg) for some candidate approaches and parameterizations.
2) generate monthly L3 binned Rrs.
3) generate L3 products (a, bb, aph, adg) from (2) for comparison to (1).
We are working on a mechanism for step 3 (effectively modifying msl12 to read and write L3 bin format) so that we can run the exact same implementation of any candidate algorithm on both L2 and L3 Rrs, and compare monthlies.
I am planning to use 2005 mar jun sep dec. If you want, I can send you the files from 1 and 2 and you can compare our L2->L3 GSM with your L3->L3 GSM.
-- bryan
Tim,
I will be processing these scenes with each of the algorithms,
however I would not discourage you from running your own
tests, in fact I would encourage you to do so.
I will post the results of our processing (images, histograms, etc)
These scenes will also be used for our planned sensitivity analysis
Sean
I will be processing these scenes with each of the algorithms,
however I would not discourage you from running your own
tests, in fact I would encourage you to do so.
I will post the results of our processing (images, histograms, etc)
These scenes will also be used for our planned sensitivity analysis
Sean
All,
The test scenes have been processed, and as a first look at them
I've generated cumulative histograms for bbp, a (total), adg and aph.
You can find these results at:
http://oceancolor.gsfc.nasa.gov/MEETINGS/OOXIX/IOP/testscene_histograms.html
Regards,
Sean
The test scenes have been processed, and as a first look at them
I've generated cumulative histograms for bbp, a (total), adg and aph.
You can find these results at:
http://oceancolor.gsfc.nasa.gov/MEETINGS/OOXIX/IOP/testscene_histograms.html
Regards,
Sean
Hi Sean,
It looks from this first cut of results that the pure water absorption values are not being added to the PML model output (I think that our nomenclature is somewhat confusing). Could you please look through the code you have just to check that is the case? I know Bryan and I were talking about this a while back.
Tim
It looks from this first cut of results that the pure water absorption values are not being added to the PML model output (I think that our nomenclature is somewhat confusing). Could you please look through the code you have just to check that is the case? I know Bryan and I were talking about this a while back.
Tim
Tim,
Your model returns variables called a_pml, bb_pml, adg_pml, aph_pml. I believe we already established that
bb_pml is really bbp. Can you confirm that a_pml is really adg_pml + aph_pml and not a_total? If yes, I will add our aw.
A more fundamental problem I found is that you have a function to initialize the model, wherein you pass arrays of aw and bbw. I call this function to initialize PML to use our preferred values for pure water (for consistency with other models). However, in looking deeper into your code, I don't see that these values for aw and bbw are actually visible to the model. You are using other values, extracted from your LUTs, called a_w and b_w. I don't know yet how much your internal values differ from the our standard values.
-- bryan
Your model returns variables called a_pml, bb_pml, adg_pml, aph_pml. I believe we already established that
bb_pml is really bbp. Can you confirm that a_pml is really adg_pml + aph_pml and not a_total? If yes, I will add our aw.
A more fundamental problem I found is that you have a function to initialize the model, wherein you pass arrays of aw and bbw. I call this function to initialize PML to use our preferred values for pure water (for consistency with other models). However, in looking deeper into your code, I don't see that these values for aw and bbw are actually visible to the model. You are using other values, extracted from your LUTs, called a_w and b_w. I don't know yet how much your internal values differ from the our standard values.
-- bryan
Bryan,
Yup - the a_pml is adg_pml + aph_pml. There is no pure water component added. The internal a_w parts are inherited from before my time working on the code; and the initialisation stuff is something we are working on at the moment (we have a new release which you won't have yet).
I am on vacation now until the beginning of September. Takafumi (tahi@pml.ac.uk) will reply in my absence.
Tim
Yup - the a_pml is adg_pml + aph_pml. There is no pure water component added. The internal a_w parts are inherited from before my time working on the code; and the initialisation stuff is something we are working on at the moment (we have a new release which you won't have yet).
I am on vacation now until the beginning of September. Takafumi (tahi@pml.ac.uk) will reply in my absence.
Tim
Bryan (CC: Tim)
As you already know, aw and bbw values in our code are extracted from LUT. This is because the LUT is generated using these values and we wanted to avoid internal inconsistency indeed.
We have used Pope & Fry's value for aw. Comparing the aw(lambda) values to those posted earlier by you (i.e. aw considering satellite bandwidth, Date: 2008-08-06 17:24) shows 3.2% of maximum differences for SeaWiFS bands between 412-670nm (but mostly < 0.6%) . As for bbw, I found 4.1% of maximum difference between ours and yours (mostly < 2.6%)
Because the difference is now found to be so small, the inconsistency between our and your aw and bbw values would not be crucial at the moment, when you add your aw and bbw values onto our ag+ap retrieved.
More serious question is, however, whether or not we correct bbw values according to temperature & salinity. I will separately post my opinion regarding this.
Cheers,
Taka
As you already know, aw and bbw values in our code are extracted from LUT. This is because the LUT is generated using these values and we wanted to avoid internal inconsistency indeed.
We have used Pope & Fry's value for aw. Comparing the aw(lambda) values to those posted earlier by you (i.e. aw considering satellite bandwidth, Date: 2008-08-06 17:24) shows 3.2% of maximum differences for SeaWiFS bands between 412-670nm (but mostly < 0.6%) . As for bbw, I found 4.1% of maximum difference between ours and yours (mostly < 2.6%)
Because the difference is now found to be so small, the inconsistency between our and your aw and bbw values would not be crucial at the moment, when you add your aw and bbw values onto our ag+ap retrieved.
More serious question is, however, whether or not we correct bbw values according to temperature & salinity. I will separately post my opinion regarding this.
Cheers,
Taka
Bryan,
If we correct a_w and b_w (bb_w) according to temp. & sal. (as discussed in forum), I will need to re-generate a new LUT used in PML code. While Jeremy has already provided a procedure for salinity correction, I still need a procedure for temp. correction for a_w, common to all model developers. Jeremy mentioned that the temp. correction will also be provided soon, so I will re-generate the LUT as soon as it becomes available.
The generation of the LUT involves extensive radiative transfer simulations which alone take some days (with my computer). When I get the correction procedures and finish updating the LUT, I will let you know and send it to you.
Have a lovely weekend
Taka
If we correct a_w and b_w (bb_w) according to temp. & sal. (as discussed in forum), I will need to re-generate a new LUT used in PML code. While Jeremy has already provided a procedure for salinity correction, I still need a procedure for temp. correction for a_w, common to all model developers. Jeremy mentioned that the temp. correction will also be provided soon, so I will re-generate the LUT as soon as it becomes available.
The generation of the LUT involves extensive radiative transfer simulations which alone take some days (with my computer). When I get the correction procedures and finish updating the LUT, I will let you know and send it to you.
Have a lovely weekend
Taka
Bryan,
As I promised earlier, I have updated LUT for PML model, which includes Temp/Salinity correction for aw and bbw provided by Jeremy earlier. The LUT is found at our ftp site: "http://publicftp.pml.ac.uk/".
If you log on to the ftp site as a third party and go into a directory called "tahi", you will find
Salty_Fsw_0_phi90_nconst_7.2_cox_30x24_i386_table.dat
which is the LUT. You need to save the LUT under the directory called "data" within PML model. Then you edit the config file called "pml.cfg" which is stored in the directory called "config";
Within "pml.cfg", just replace an old file name of LUT by the new one above.
The old LUT name is: Fsw_0_phi90_nconst_7.2_cox_30x24_i386_table.dat. You can't miss it, when you open "pml.cfg".
Cheers,
Taka
As I promised earlier, I have updated LUT for PML model, which includes Temp/Salinity correction for aw and bbw provided by Jeremy earlier. The LUT is found at our ftp site: "http://publicftp.pml.ac.uk/".
If you log on to the ftp site as a third party and go into a directory called "tahi", you will find
Salty_Fsw_0_phi90_nconst_7.2_cox_30x24_i386_table.dat
which is the LUT. You need to save the LUT under the directory called "data" within PML model. Then you edit the config file called "pml.cfg" which is stored in the directory called "config";
Within "pml.cfg", just replace an old file name of LUT by the new one above.
The old LUT name is: Fsw_0_phi90_nconst_7.2_cox_30x24_i386_table.dat. You can't miss it, when you open "pml.cfg".
Cheers,
Taka
A suggestion (voiced before by someone?): It is not that informative to compare results at 670 nm, as pretty much it's absorption of pure water. So suggest show retrievals within the blue-green-yellow spectral domain.
Sean: Enjoy your vacation. And all people have a nice weekend, and enjoy some of the Olympic games.
zhongping
Sean: Enjoy your vacation. And all people have a nice weekend, and enjoy some of the Olympic games.
zhongping
Agreed, at least for comparisons of a(total) at 670 nm.
Similarly, adg670 is likely perty durn small.
However, aph670 can be a very interesting - and potentially
useful - parameter. We shouldn't discount it just because
total a is dominated by water.
Sean - who's watching the opening ceremonies as he types... :)
Similarly, adg670 is likely perty durn small.
However, aph670 can be a very interesting - and potentially
useful - parameter. We shouldn't discount it just because
total a is dominated by water.
Sean - who's watching the opening ceremonies as he types... :)
I am not a fan of keeping aph(670) for "global" purpose. A few reasons:
1) As we all know, Rrs(670), unless it is in a bloom, has almost no information of aph(670).
2) Consequently, for nearly all algorithms, aph(670) is derived from aph at other wavelengths (such as 440), one way or the other, not from Rrs(670).
3) For further applications, such as to derive chlorophyll concentration, aph at other wavelengths work the same way as aph(670).
My three cents,
zhongping
1) As we all know, Rrs(670), unless it is in a bloom, has almost no information of aph(670).
2) Consequently, for nearly all algorithms, aph(670) is derived from aph at other wavelengths (such as 440), one way or the other, not from Rrs(670).
3) For further applications, such as to derive chlorophyll concentration, aph at other wavelengths work the same way as aph(670).
My three cents,
zhongping