ENSO Proxy Validation

This is a straightforward validation of the ENSO model presented at last December's AGU.

What I did was use the modern instrumental record of ENSO — the NINO34 data set — as a training interval, and then tested across the historical coral proxy record — the UEP data set.

The correlation coefficient in the out-of-band region of 1650 to 1880 is excellent, considering that only two RHS lunar periods (draconic and anomalistic month) are used for forcing. As a matter of fact, trying to get any kind of agreement with the UEP using an arbitrary set of sine waves is problematic as the time-series appears nearly chaotic and thus requires may Fourier components to fit. With the ENSO model in place, the alignment with the data is automatic. It predicts the strong El Nino in 1877-1878 and then nearly everything before that.

This is an expanded view of the proxy agreement. Now the ENSO proxy is in red with squares showing the yearly readings. It would be nice to get sub-year resolution but that will never happen with yearly-growth-ring data.

8 thoughts on “ENSO Proxy Validation

  1. Do you have any hope/insight into whether this can be incorporated into the current generation of GCMs -- or is their structure such that this is unlikely?

    I would think the ability would be a major step forward

    • That would be an excellent idea. I am trying to find examples of GCMs that will output ocean tidal sea level height. This would be perfect as a first step because one can calibrate the output against the measurements precisely. The next step is to apply that section of GCM code to the thermocline height instead of the sea level height.

      Unfortunately there isn't any community GCM code that I am aware of that has any hooks for lunar forcing, or for external Newtonian forcing for that matter. Ideally, there should be a callback function somewhere for the external gravitational forcing that would be called for every time step.

      But I can't imagine that any coder would have added that callback in the source as it wouldn't have been a requirement. For that matter, I have yet to see any reference to any lunar parameterization in any code.

  2. Pingback: ENSO and Noise | context/Earth

  3. Pingback: The Lunar Geophysical Connection | context/Earth

  4. Pingback: Scaling El Nino | context/Earth

  5. Pingback: Strictly Biennial Cycles in ENSO | context/Earth

  6. Pingback: Annual and Biennial Modulations | context/Earth

Leave a Reply