The Fractal Nature of Terrestrial Pack Ice

 

Shahin M. Movafagh

 

August 27, 1997

 

 

Abstract.  Ridges and lineaments are the dominating features on the surface of Europa.  Whether they are of tectonic origin or more similar to Terrestrial fractured pack ice holds direct bearing on the geology of Europa.  Fractures and faults in brittle surfaces and shear bands in plastic flows as well as ice roughness often exhibit fractal behavior [Herrmann et al. 1995,Silberschmidt 1994, Kay 1989]. A preliminary study of terrestrial fractured ice packs suggests that the fractured regions may be fractal in nature and exhibit an approximate fractal dimension of 1.06. The categorization of the ridges into fractal and non-fractal will ultimately provide us with a criterion of comparison.

 

1. Introduction

From its onset, fractals have been used to describe geology.  Mandelbrot first noticed a scale invariant behavior while studying data on coastlines gathered by Richardson [Mandelbrot 1967].  While in geology and remote sensing fractals have been considered more a mathematical curiosity than a scientific tool, log graphs of crater size-frequency distributions have been in use for several  decades.  One reason is that as craters get smaller, the frequency increases exponentially.  Craters of similar origin tied to specific impact population fluxes exhibit a linearly sloped line on log-log graphs [Gault 1970].  This is in essence graphing the fractal properties of cratering before the fractal model took form.  Interestingly, as craters saturate a surface an equilibrium state can be reached changing the slope of the size-distribution graph.

A fractal dimension approximation is a generalized log/log relation made applicable to various geometries reflecting the processes at work.  In the context of fractals,  the log ratio is due to self-similar behavior; an imprint of the bombardment process.  The cratered surface dimension can be considered as decreasing from a two dimensional surface into a fractal dimension [Mandelbrot 1977].  In the same manner, a fractal dimension can be regarded as a signature of the process at work, often reflecting the origin of the process, the composition and properties of the materials involved etc.[Falconer 1990].  It, therefore, can lead to greater insight into the nature and origin of geological units in question.

Recent developments in fractal approximations of remote sensing data have introduced fractals as a robust tool for understanding digital remote sensing data [Bruno et al. 1994, Longely and Batty 1989, Hayward et al. 1989, Jaggi et al. 1993, Lam and De Cola 1993].  Basaltic lava flows have been shown to exhibit fractal properties based on both remote sensing data and field measurements. [Bruno et al. 1994]

Why Europa?  The tectonic origin of the ridges on Europa is now under question.  Terrestrial sea ice models have been proposed suggesting a sub-surface ocean on Europa [Coon 1997].  Whether Terrestrial packed ice displays fractal properties comparable to the Europa’s surface has a direct bearing on the current models of Europa.

 

2. Background

A fractal dimension value often results from a non-linear process and it is based on the scale-invariant, self-similar properties of observed geometries.  In one sense it can be visualized as a fractional dimension value for objects that can not be categorized in the traditional geometry of one dimensional lines and two dimensional surfaces.  For example, if a coastline increases in length as we decrease our measurement unit in the field and it shows statistically self-similar behavior (meaning that each portion can be considered a reduced scaled image of the whole) at various scales, in can be approximated as a fractal

The fractal dimension is: D = log(N) / log(r) where N can be the number of units (rods, sticks etc.) used to cover the coastline and r is the self-similarity ratio.

Fractal geometry is a mathematical model and so should be treated as such.  No objects are true fractals in the same manner as nothing is an exact straight line.  Setting aside the hype, it is a powerful tool if used alongside and in the context of other techniques and tools and it is applicable in many areas of geology and planetary science.

Although the smallest of the Galilean satellites, Europa may be subjected to tidal heating similar though less intense to that of Io.  The general low relief of the surface combined with a paucity of craters lends to a younger active surface.  The voyager images of Europa are very limited in coverage and resolution, still various linear units are present in most of the data on Europa.  These “ridges” include double ridges, arctuate features and sinuous formations and may be related to the triple bands. A northwest trend is present in certain ridge features. These lineations have also been explained as tension features attributed to a dehydrating silicate interior causing global expansion.

The surface albedo of Europa is relatively high.  Kuiper first suggested that the reflectivity at one micron to two micron wavelength can be due to the surface being dominated by water ice.  Also,  a spectral dichotomy may be at work on the surface.  Europa’s density suggests that there should be 5% water present.  Theoretically, a ~100 kilometer icy surface layer could account for this ratio.  A 100 kilometer thick ice lithosphere with a possible water asthenosphere and a silicate mantle is one of the current models suggesting the ridges are of tectonic origin. Much remains to be understood about the ridges.  Ridges seem to be composed of straight segments in northern and central regions and cycloidal in the south.  Triple bands, gray bands, and various crisscrossing lineaments related to dark spots have been linked with tectonic deformation from Galileo data [Belton et al., 1996]

More recent (E6) Galileo data has revealed chaotic regions where the surface is shifted about.  This in conjunction with Max Coon’s pack ice models based on Terrestrial sea ice has lead to a theory employing a much thinner icy lithosphere perhaps a few kilometers thick.  This model relies on the presence of liquid water during the formation of the ridges.

Whether Europa has harbored sub-surface liquid water during the formation of the ridges is a question of great interest.  The terrestrial pack ice models need to be examined closely and modified using zero atmosphere and low gravity parameters.  The model relies on ice drifting apart creating a thin frozen layer that forms a ridge when the pack ice later moves back together.

 

3. Method

Several methods were considered for obtaining an empirical dimension value.  The box-counting method has been in use under various guises since the 1930’s [Falconer 1990].  The walk methods used by Bruno et al. was based on algorithms by Hayward et al. and Longley and Batty. A similar method was used.  Instead of using the 'exact walk' and do pixel interpolations loosing fractional pixel values, a delta value was tracked  against actual pixel positions with each step.  This is necessary since a pixel going at an angle may not land into an exact step size.  For a listing of this new 'delta walk' algorithm please refer to appendix A.

This method relies on the software walking along the edges of a graphic image while it compares its distance from the step start point to the given step size.  The software then figures out how many steps were required for a given step size in order to traverse the edge.  The program then gets the similarity ratio based on the number of same size steps present in the straight line between the start and end points.  The user needs only to enter the start and end points, step size in pixels, and the initial direction of the walk.

Java was chosen as the vehicle for the software, making the software readily available for general usage through the internet.  The skeleton code for the software was taken from the image-J source [Image-J 1997].

To prove a feature demonstrates fractal properties requires using data at different resolutions exhibiting the same D value.  To do this, data from the same region of Europa was used from three different data sets (Figure 1).  The software was then used to convert the image to a black and white image.  This was accomplished by using the average pixel value as a treshold for turning pixels on or off (255 or 0).  The image was manipulated as a giant array of bytes and the Java virtual machine took care of reading various image file formats.

Five pixel step sizes were used for all the data gathered.  A problem in the algorithm allowed some of the pixels to be skipped over based on the walk’s angle.  This combined with a limited data set and an abundance of cross-cutting of features made the task challenging.  The software was tested on some test drawings of lines and various objects providing satisfactory results.

4. Do the ridges display fractal properties?

The limited data set holds only encouraging findings (Figure 2). 

The E4GloMap data exhibited nearly line-like values (D ~ 1) for the prominent ridge in the image.  The results for the E6DarkLin had D of approximately 1.3 but one data point was significantly off.  The E6BrtPlain D values ranged from 1.01844 to 1.22351 leaving inconclusive results.  Radar Terrestrial sea ice data was also examined but proper data from Terrestrial pack ice will be examined soon.  Altogether the data currently suggests non-fractal properties.  However, the data set is not large enough in coverage and frequency to provide a statistically sound result. Even if some of the ridges are not fractal it is still a significant finding when in use to compare to fractal objects.

Figure 2.

Data Origin

Step Size (Pixels)

Number of steps

Dimension value D

Comment

E4GloMap

5

5.6

1.00395

Too few steps

E6DarkLin

5

21

1.27246

 

E6DarkLin

5

?

1.27774

 

E6DarkLin

5

41

1.11865

 

E6DarkLin

5

12

1.3575

 

E6BrtPlain

5

17

1.20923

 

E6BrtPlain

5

11

1.01844

 

E6BrtPlain

5

15.2

1.04214

 

E6BrtPlain

5

12

1.04644

 

E6BrtPlain

5

8

1.15059

Too few steps

E6BrtPlain

5

7

1.20046

Too few steps

E6BrtPlain

5

18

1.176939

 

Radar Ice data

5

13

1.22351

 


5. Conclusion

The data is currently inconclusive.  The step sizes may need to be increased, the features better isolated and the software needs minor fixes—some pixels get skipped causing lower D values than actual.  If the same trend holds after the improvements mentioned above then perhaps the chosen feature, a prominent ridge, may not be of fractal nature.  This may imply that it may have arisen from a different process than other features that may demonstrate consistent fractal behavior.

The D value for fractured rocks and ice packs should be compared to various features on Europa.  Other planetary bodies need to be used for comparison.  The spatial distribution of the D values and fractal behavior can lead to a better understanding of global versus local type features reflecting global versus localized processes.  The consistency of the D values between low and high resolutions can help distinguish low resolution data based on the D value (e. g. If triple bands are fractal and always show a certain D at low and high resolution data, then triple bands can be identified from a low resolution data set based on its D value!)  Finally, proper Terrestrial arctic data can help better investigate the nature of the ridges as compared to terrestrial processes.

REFERENCES

Herrmann, Hans, The Deformation of Rocks: Fractals Everywhere, Fractal Geometry and Analysis, World Scientific Publishing, 1996

Silberschmidt, Vadim, Fractal and multifractal characteristics of stochastic brittle fracture, Fractals in the Natural and Applied Sciences, Elsevier Science B.V., 1994

Kaye, Brian, A Random Walk Through Fractal Dimensions, VCH Publishers, 1989

Mandelbrot, Benoit, How Long Is The Coast of Britain?  Statistical Self-Similarity and Fractional Dimensions, Science 156, 1967

Gault, Donald E., Saturation and equilibrium conditions for impact cratering on the Lunar surface: Criteria and implications, Radio Science 273, 1970

Mandelbrot, Benoit, The Fractal Geometry of Nature, W. H. Freeman and Company, 1977

Falconer, Kenneth, Fractal Geometry, John Wiley and Sons, 1990

Bruno, B. C. et al., Quantifying the effect of rheology on lava-flow margin using fractal geometry, Volcanology 56, 1994

Longley, Paul A. and Batty, Michael, Fractal Measurement and Line Generalization, Computers and Geosciences 15, 1989

Hayward, Janette et al., Three Implementations of Fractal Analysis of Particle Outlines, Computers and Geosciences 15, 1989

Jaggi, S. et al., Implementation and operation of three fractal measurement algorithms for analysis of remote sensing data, Computers and Geosciences, 1993

Lam, Nina Siu-Ngan and De Cola, Lee, Fractals in Geography, Prentice Hall, 1993

Coon, Max, Arizona State University Planetary Geology presentation: “Terrestrial Sea Ice and the Europa Connection (?)”, 1997

Belton, M. J. S. et al., Galileo’s First Images of Jupiter and the Galilean Satellites, Science 274, 1996

Image-J, Source code FTP: ftp://codon.nih.gov/pub/image-j/source, 1997

 

Figure 1A. E4GloMap

Figure 1B. E6 DarkLin

Figure 1C. E6BrtPlain

 


Appendix A

 

////////////////////////////////////////////////////////////////////////////////////////////////////////////

//

//  Function:          Walk(dir, stepLength)

//

// Description:       This function performs a walk along

//                             the edges of a graphic object, counting the

//                             number of step sizes required to traverse the edge.

//

// Written by:        Shahin M. Movafagh

//

// Date:                   May 1997

//

// Location:            Arizona State University

////////////////////////////////////////////////////////////////////////////////////////////////////////////

    void walk(double dir, double stepLength) {

        // Find walk direction from start+end pixels

        // Get step length in pixels

       

        int lastPos;

        int curPt,startStepPt;

        int oldPt;

 

        stepCounter=0;

        byte[] pixels2;

        pixels2 = new byte[width * height];

        System.arraycopy(pixels,0,pixels2,0,width*height);

 

        direction = (int)dir;

        stepLengthG = stepLength;

 

        curPt = startStepPt = startPtPixel;

 

        while(curPt!=endPtPixel) {

                oldPt = curPt;

 

                curPt = findNextPoint(curPt);

                if(distance(startStepPt,curPt)>=stepLength)

                {

                                stepCounter+=1.0;

                                byteLine (startStepPt, curPt, (byte)-1, pixels); // pixels for drawing line

                                startStepPt = curPt;

                } // If

        }// while

 

        stepCounter+=distance(startStepPt,curPt) / stepLength;

 

        byteLine (startStepPt, curPt, (byte)128, pixels); // pixels for drawing last segment

 

        r = (float)distance(startPtPixel,endPtPixel) / (float)stepLength;

 

        System.out.println("Results: stepsTaken="+stepCounter+" r="+r+" D="+(Math.log((double)r)/Math.log((double)stepCounter)) );

 

}

 

int findNextPoint(int beginPt) {

                    int tempPt;

                    int curPoint = beginPt;

                    int curCount = 0;

                    int tc;

 

                    tempPt = look(curPoint,direction); // Look in starting dir for white pixel

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    //else { // adjust bad directions

                    tempPt = look(curPoint,direction+1);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    tempPt = look(curPoint,direction+7);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    tempPt = look(curPoint,direction+2);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    tempPt = look(curPoint,direction+6);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    tempPt = look(curPoint,direction+3);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                    tempPt = look(curPoint,direction+5);

                    if ((tempPt!=curPoint)&&((tc=lookEverywhere(tempPt,(byte)0))>curCount)) // we have it

                    {

                        curCount = tc;

                        curPoint = tempPt;

                    }

                  if(curCount==0) {

                            r = (float)distance(startPtPixel,endPtPixel) / (float)stepLengthG;

                                System.out.println("Results: stepsTaken="+stepCounter+" r="+r+" D="+(Math.log((double)r)/Math.log((double)stepCounter)) );

 

                            System.out.println("Direction look failed: "+direction+" curPoint="+curPoint+"("+(curPoint%width)+","+(curPoint / width)+")");

                                // throw exception here

                                throw new IndexOutOfBoundsException("direction failed");

                  }

 

 

                    // Change pixel color to gray

                    pixels[curPoint] = (byte)128;

 

                    return curPoint;

}

 

float distance (int fromPixel, int toPixel) {

        System.out.println("Enter distance");

        int x1 = fromPixel % width;

        int y1 = fromPixel / width;

        int x2 = toPixel % width;

        int y2 = toPixel / width;

        int deltaX = x2 - x1;

        int deltaY = y2 - y1;

        float dist = (float)Math.sqrt((deltaX*deltaX)+(deltaY*deltaY));

        //System.out.println("Returning from dist="+dist);

        return dist;

    }

 

 

int look(int pixel, int dir) {

    // direction (class global) flag values are 1=N, 2=NE ... 8=NW

 

        //System.out.println("Entering look, direction:"+direction);

 

        int loc = pixel;

 

                    dir = dir % 8;

 

                    switch (dir)

                    {

                        case 1:

                            if (pixels[(pixel-width)]==((byte)-1))

                                loc =  (pixel-width);

                                break;

                        case 2:

                            if (pixels[(pixel-width+1)]==((byte)-1))

                                loc =  (pixel-width+1);

                                break;

                        case 3:

                            if (pixels[(pixel+1)]==-1)

                                loc =  (pixel+1);

                                break;

                        case 4:

                            if (pixels[(pixel+width+1)]==((byte)-1))

                                loc =  (pixel+width+1);

                                break;

                        case 5:

                            if (pixels[(pixel+width)]==((byte)-1))

                                loc =  (pixel+width);

                                break;

                        case 6:

                            if (pixels[(pixel+width-1)]==((byte)-1))

                                loc =  (pixel+width-1);

                                break;

                        case 7:

                            if (pixels[(pixel-1)]==-1)

                                loc =  (pixel-1);

                                break;

                        case 0:

                            if (pixels[(pixel-width-1)]==((byte)-1))

                                loc =  (pixel-width-1);

                                break;

                        default:

                            loc =  pixel;

                            break;

                    }

                    return (loc);

}