IOP algorithm test scenes

By tjsm Date 2008-07-25 08:35

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

By stephane Date 2008-07-25 15:41

Hi Sean,

The regional scenes are fine but what about global scenes and Level-3 stuff ?

Stephane

By bryan Date 2008-07-25 18:14

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

By @sean Date 2008-07-25 18:16

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

By @sean Date 2008-08-05 20:38

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

By tjsm Date 2008-08-06 07:30

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

By bryan Date 2008-08-06 14:48

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

By tjsm Date 2008-08-07 06:09

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

By Hirata Date 2008-08-07 09:43

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

By Hirata Date 2008-08-08 12:57

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

By Hirata Date 2008-08-18 13:44

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

By zplee Date 2008-08-08 22:18

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

By @sean Date 2008-08-09 01:00

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... :-)

By zplee Date 2008-08-09 21:21

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