Cayula-Cornillon Fronts tool errantly shuffles algorithm parameters, causing fronts to not be detected

[jjr8]

While investigating why the Find Cayula-Cornillon Fronts in ArcGIS Raster tool was not detecting fronts in SST images in the South China Sea, I discovered a significant bug in the tool: deep in the C++ code, three of the algorithm parameters were being passed to a function in the wrong order. As a result, the tool was using the wrong values for these three parameters:

The value you provided for:	Was used by the tool for:
Minimum value for criterion function	Minimum global-population cohesion
Minimum single-population cohesion	Minimum value for criterion function
Minimum global-population cohesion	Minimum single-population cohesion

For example, if you executed the tool with the default parameter values, this is what actually happened:

Parameter	Value provided	Value actually used
Minimum value for criterion function	0.76	0.90
Minimum single-population cohesion	0.90	0.92
Minimum global-population cohesion	0.92	0.76

Here is an example image using the default parameter values with the bug in effect. This is the NODC 4km Pathfinder version 5.0 daytime daily image for 3-Jan-2005, south of Mexico, with pixels with quality flag <= 2 masked. Fronts are shown in black.

Note how very few fronts are detected. Here is the same image, same default parameter values, with the bug fixed:

Note how many more fronts are detected.

The principal side effect of the bug is that, by default, the minimum value for the criterion function is 0.9 rather than 0.76. As the tool passes the moving histogram window over the image, this parameter comes into effect after the tool optimally separates the pixels of the window into a "warm" and "cold" population. The criterion function estimates the bimodality of the temperature histogram for the window. The value 0.9 causes the tool to reject many windows that are fairly bimodal. For a window to be classified as containing a front, the temperature histogram must exhibit almost perfect bimodality.

This bug has existed in the tool since it was first released in MGET, in version 0.3, in September 2007. It did not exist in my older front detection tool, which I did not publically release. I introduced the bug when I rewrote the old code for MGET.

I did not detect the bug in the MGET version until now because I almost never run the tool using the default parameter values. I always use a smaller window size, such as 16, with a window stride of 1 and cohesion parameters calibrated to this reduced window size. Here are the typical parameters I use with the NODC Pathfinder data; the parameters not shown are left at the default values:

Parameter	Value
Histogram window size	16
Histogram window stride	1
Minimum single-population cohesion	0.8675
Minimum global-population cohesion	0.8875

With the bug in effect, these parameter values do detect more fronts:

I thought that the reduced window size was responsible for the improvement. But really, the improvement came from reducing the effective minimum value of the criterion function from 0.9 to 0.8675. This caused the tool to relax its requirement for extremely bimodal temperature distributions, allowing more fronts to be detected.

When the bug is not in effect, these parameter values flag a very large number of pixels as fronts, because the proper default minimum value for the criterion function, 0.76, is used instead:

These parameter values are probably not the best choice for the bug-free tool. Many fronts are to thick. This can be improved by reducing the histogram window stride or by running a thinning algorithm on the fronts, such as the ArcGIS Spatial Analyst Thin tool.

This bug will be fixed in MGET 0.7a4. I recommend that anyone using the MGET front detection tools upgrade to 0.7a4 or later as soon as possible. Alternatively, you can work around the bug in earlier versions of MGET by shuffling the parameter values to "undo" the effects of the shuffling that MGET performs internally.

If you used the buggy implementation for your research, please accept my sincere apology for this problem. Your results are not invalid, they are just much more conservative than you probably intended. If you have the opportunity to revise your work I believe the fixed implementation will provide better results. If you have any further questions, please do not hesitate to contact me ( jason.roberts@duke.edu).

[jjr8]

Fixed in [333], released in MGET 0.7a4.