The Evolution of Models - 3

Complex Systems

Architects of prospective sea level rise (SLR) software have to face 'mystery' or better said, complex system behavior, from time to time.

Complex becomes 'mysterious' when the complexity is "on steroids" to the point it moves out of cognitive range.

Simulating the complexity exactly requires an understanding of the unknown, which is a dichotomy, so the solution chosen sometimes is to guess or to ignore.

For example, earlier IPCC reports from time to time in the past did not see polar ice cap melt as calculable, so that realm was excluded from the picture.

Thus, projections of models were consistently underestimating the real scenario, because the polar ice caps were destined to eventually become the main player in SLR.

The polar caps are now given a place at the table, because they are the prime source of future SLR.

Knowing that does not, in and of itself, remove all of the mystery, because SLR is a phenomenon of a complex system.

There are linear, non-linear, exponential and non-exponential factors, even in well known dynamics, such as an 'acceleration' (The Question Is: How Much Acceleration Is Involved In Sea Level Rise?) or a 'surge' (Will This Float Your Boat - 5, What Do You Mean - World Civilization? - 2).

There are various types and causes of both acceleration and surges.

Either one or both sometimes can be confused with "feedback loops."

That said, it is also true that sometimes surges and/or accelerations are in fact due to feedback loops, but at other times they are mistaken for separate natural surges and natural accelerations in a complex non-feedback dynamic:

"We may be witnessing the start of the long-awaited jump in global temperatures. There is “a vast and growing body of research,” as Climate Central explained in February. “Humanity is about to experience a historically unprecedented spike in temperatures.” - Think Progress

---

"Humanity is about to experience a historically unprecedented spike in temperatures.

That’s the ominous conclusion of a vast and growing body of research that links sweeping Pacific Ocean cycles with rates of warming at the planet’s surface — warming rates that could affect how communities and nations respond to threats posed by climate change." - Climate Central

And of course as I said above, on top of acceleration and surge, there are separate individual feedback loops:

"Now, scientists believe they’ve untangled the relationship. In a paper published Monday in Nature Climate Change, researchers from the University of Exeter claim to have found direct evidence that as global temperatures rise, so does the atmospheric concentration of greenhouse gases, creating a positive feedback that in turn warms the Earth even more — basically, global warming creates more global warming.

“We discovered that not only does thickening the blanket of heat-trapping gases around our planet cause it to get warmer, but also, crucially, when it gets warmer this increases thickens the blanket of heat-trapping gases,” Tim Lenton, the paper’s author, told ThinkProgress, “so we have a process called a ‘positive feedback’ that amplifies changes in the Earth’s temperature.”

(Study: Direct Evidence That Global Warming Causes More Global Warming). The designer or architect of software that has these issues within its context can try to build that logic into the code itself, or can choose to have these scenarios and dynamics described by data.

Data which the software analyzes, derives values, then injects the derived results into the computations and calculations.

IMO, the latter is the preferred method, because, as the situation becomes more clear and the data becomes better, the simulations will be more accurate without any change to the program logic (x + y - z logic can be used in thousands of scenarios without changing the code, but instead changing the data values for x,y, and z).

So, I have built surge, delay, and acceleration logic into both the data entry exercises and calculation logic.

Processing that data, then using it in concert with the less-mysterious and more certain computations, becomes routine and more error free, in terms of logic, in the long run.

One can put expected surge, delay, and acceleration values into the database and it will be processed accordingly.

Or it can be left out, if a user chooses.

My practice is to develop multiple data scenarios, save them, modify them if needed when research clarifies this or that issue, but always have them available for use.

Constantly rewriting the code is not preferred when compared to merely adjusting the data.

So, the software I wrote to project future SLR has classes with data members for standard melting, acceleration of melting, temporary surges of melting, delays in melting,  and various other data values to describe the zones of melt (size, year melt begins, maximum melt, etc.).

Data values which the user enters, modifies, and processes at will.

The user is in the drivers seat to the extent that the data determines the results.

The purpose which the architect or designer fulfils, then, is to first grasp the principles involved in the solution ("abstractions" in object oriented language jargon), then create "classes" (concepts of operations) which become "objects" (converting abstractions into "concrete" operations) when "instantiated" at "runtime."

This article from BBC (Greenland ice sheet losses double) gives some idea of what a developer of such software faces.

This article from NOAA (Arctic Report Card) gives some idea about how breaking ice sheets into zones still requires more than that alone.

That is, more than just a "melt beginning year," acceleration of melt, delay of melt, temporary surges in melt rate, and the like.

Comprehensive consideration of the phenomenon requires a concept of a dynamic rate-of-melt, which changes in that zone, as well as in the other zones.

For example, did you notice that in the Arctic Report Card piece that the ice loss, as measured by the GRACE satellite (measures mass) dropped to no mass loss (Fig. 3.3 in that post).

Using the same formula that derived 14.87%, L = [ (f / s)^{(1 / y)} ] - 1 , where y = 5 years(see Will This Float Your Boat - 5), the 14.87% drops to 12.25% when y = 6 years instead of y = 5 years.

That is a drop in acceleration of 17.6% in one year (assuming Cryosat-2 comes up with the same result).

Meanwhile, Antarctica volume loss @ Totten Glacier accelerated (which shows the importance of trend, mean, and averages in long range projections).

The previous post in this series is here.