A E I DG A C F V B T T .NET E

powemryologistΤεχνίτη Νοημοσύνη και Ρομποτική

23 Οκτ 2013 (πριν από 3 χρόνια και 8 μήνες)

86 εμφανίσεις

A
N

E
XPLORATION

I
NTO

D
ESKTOP
G
ARP

A
PPLICATION

C
ONVERSION

F
ROM

V
ISUAL

B
ASIC

T
O

T
HE

.NET
E
NVIRONMENT


By


N
ARAYANAN

R
AGHAVAN


B.E., Annamalai University, India, 2003



A REPORT

submitted in partial fulfillment of the

requirements for the degree



MASTER OF SC
IENCE

Department of Computing and Information Sciences

College of Engineering


KANSAS STATE UNIVERSITY

Manhattan, Kansas

2005


Approved By:



Major Professor

Daniel Andresen
, Ph.D.


ABSTRACT


This report describes the
process
involved in
converting Deskto
pGarp standalone
Windows
application from Visual Basic to
Visual Basic.NET and C#.NET web
application
,

and the problems faced during conversion
.

The report

talks
about the
c
urrent
design and working o
f DesktopGarp as a standalone W
indows
application
,

the
drawbacks
of
DesktopGarp as a

standalone application and the need to convert it into a client
-
server
application.
The converted

DesktopGarp

web application

emulates a thin client interface
providing the same functionality as the existing
DesktopGarp
Windo
ws application.
This
report then goes into the specifics of
the DLL and COM components that the application
uses and problems with unmanaged code in the .NET environment
.

Conclusions are
drawn based on the implementation
experiences

and
the
programming l
anguage
constraints.

Finally
,

the report

talks about
specific

future possibilities

and short term
goals.





To my parents,

Hema and Raghavan,

a
nd

my

brother Vasudevan
.


i

TABLE OF CONTENTS

LIST OF FIGURES

................................
................................
................................
................................
....................

III

ACKNOWLEDGEMENTS

................................
................................
................................
................................
......

IV

CHAPTER 1

INTRODUCTION

................................
................................
................................
.........................

1

1.1

O
VERVIEW
................................
................................
................................
................................
....................

1

1.2

D
ECISION
S
UPPORT
T
OOLS

................................
................................
................................
........................

1

1.3

N
EED FOR A
T
HIN
C
LIENT
I
NTERFACE

................................
................................
................................
.....

2

CHAPTER 2

GENETIC ALGORITHMS

................................
................................
................................
........

3

2.1

I
NTRODUCTION

................................
................................
................................
................................
............

3

2.2

G
ENETIC
A
LGORITHM FOR
R
ULE
-
SET
P
RODUCTION

................................
................................
..............

3

2.3

R
ULE
T
YPES

................................
................................
................................
................................
.................

4

2.3.1

Atomic Rules

................................
................................
................................
................................
..........

4

2.3.2

BIOCLIM Rules

................................
................................
................................
................................
.....

4

2.3.3

Range Rules
................................
................................
................................
................................
............

5

2.3.4

Logit Rules
................................
................................
................................
................................
..............

6

CHAPTER 3

DESKTOPGARP
................................
................................
................................
...........................

7

3.1

O
VERVIEW
................................
................................
................................
................................
....................

7

3.1.1

Species Data Points

................................
................................
................................
..............................

8

3.1.2

Optimization Parameters

................................
................................
................................
...................
10

3.1.3

Environmental Layers

................................
................................
................................
........................
11

3.1.4

Output Parameters
................................
................................
................................
..............................
12

3.1.5

Projection Layers

................................
................................
................................
................................
13

CHAPTER 4

THIN CLIENT IMPLEMEN
TATION
................................
................................
..................
15

4.1

W
ORKING OF
D
ESKTOP
G
ARP

................................
................................
................................
..................

15

ii

4.1.1

frmMain.frm

................................
................................
................................
................................
.........
15

4.1.2

DataPoints.cls
................................
................................
................................
................................
......
15

4.1.3

DataPoint.cls

................................
................................
................................
................................
.......
17

4.1.4

Datasets.cls

................................
................................
................................
................................
..........
17

4.1.5

GarpExperiment.cls

................................
................................
................................
............................
18

4.2

I
SSUES WITH
C
ONVERSI
ON
................................
................................
................................
.......................

22

4.2.1

C
ONVERSION TO
C#

................................
................................
................................
................................
..

25

4.3

I
SSUES WITH
DLL

F
ILES
................................
................................
................................
...........................

25

4.3.1

Introduction
................................
................................
................................
................................
..........
25

4.3.2

Advantages of Early Binding
................................
................................
................................
.............
26

4.3.3

Advantages of Late Binding

................................
................................
................................
..............
27

4.4

V
I SUAL
B
ASIC VERSUS
.NET

E
NVIRONMENT

................................
................................
.......................

27

CHAPTER 5

CONCLUSIONS AND FUTU
RE WORK

................................
................................
............
30

5.1

C
ONCLUSIONS

................................
................................
................................
................................
............

30

5.2

F
UTURE
W
ORK

................................
................................
................................
................................
..........

30

REFERENCES
................................
................................
................................
................................
.............................
32

iii

LIST OF FIGURES


F
IGURE
1:

D
ESKTOP
G
ARP
A
RCHITECTURE
................................
................................
...........

6

F
IGURE
2:

D
ESKTOP
G
ARP
I
NTERFACE
................................
................................
..................

8

F
IGURE
3:

D
ESKTOP
G
ARP
S
PECIES
D
ATA
P
OINTS
P
ANEL
................................
.....................

9

F
IGURE
4:

D
ESKTOP
G
ARP
O
PTIMIZATION
P
ARAMETERS
P
ANEL

................................
........

10

F
IGURE
5:

D
ESKTOP
G
ARP
E
NVIRONMENTAL
L
AYERS
P
ANEL

................................
............

12

F
IGURE
6:

D
ESKTOP
G
ARP
O
UTPUT
P
ANEL

................................
................................
.........

13

F
IGURE
7:

D
ESKTOP
G
ARP
P
ROJECTION
L
AYERS
P
ANEL

................................
.....................

13

F
IGURE
8:

GARP

D
ATA AND
R
ESULTS
................................
................................
..............

14

F
IGURE
9:

S
TATE
D
IAGRAM FOR
D
ESKTOP
G
ARP
................................
................................

16

F
IGURE
10:

S
AMPLE
.
DXL FILE

................................
................................
...........................

18

F
IGURE
11:

D
ESKTOP
G
ARP
-

B
EFORE EXPERIMENT
................................
............................

20

F
IGURE
12:

D
ESKTOP
G
ARP
-

A
FTER EXPERIMENT
................................
..............................

21

F
IGURE
13:

S
AMPLE
O
UTPUT
F
ILE

................................
................................
.....................

22

F
IGURE
14:

D
ESKTOP
G
ARP
T
HIN
C
LIENT
P
ERFORMACE
M
EASURE

................................
...

28

F
IGURE
15:

M
ICROSOFT
A
PPLICATION
C
ENTER
T
EST
S
TATISTICS

................................
.....

29

iv

ACKNOWLEDGEM
ENTS


I would like to thank Dr Daniel Andresen, Dr Shawn Hutchinson and Dr Mitchell Neilsen
for their guidance
and s
upport
during the entire course of the project.
I would
also
like to
thank Will Baldwin for his help in making this project a success.


Sp
ecial thanks to

R. Scachetti
-
Pereira
from

the University of Kansas
for providing the
original DesktopGarp Visual Basic source code and DLL files.

Special thanks to Kathryn
Burton
and Sethuraman Subramanian
for
their

help and patience in setting up the pro
ject
workspace
s each time I requested
additional
one
s
,
registering

DLL files and providing
necessary
access permissions
.

1

Chapter
1

Introduction

1.1

Overview

Advances in genetic algorithms have led to
the
development of various decision support
tools. Des
ktopGarp is one such tool that is inherently a standalone Windows Visual
Basic application that uses Genetic Algorithm for Rule
-
set Production.

As is obvious by
the very nature of genetic algorithms, th
ese tools are heavily CPU bound causing other
applica
tions and sometimes even the operating system to freeze.

It is to overcome this
limitation
that has provided the motivation for this research.

The aim was to convert the
existing standalone application into a web application within the .NET environment.


The
application was successful converted into a VB.NET web application. Conversion to a
C#.NET web application was carried out until a point where language
constraints and
DLL compatibility
issues
were
too
complex

to handle

as
compared to

rewriting the
a
pplication
.

1.2

Decision Support Tools

Comput
er based decision support tools,
derived from theoretical models of the decision
making process
, rely on
Genetic Algorithms

for producing useful results
.
These g
enetic
algorithms are adaptive heuristic search a
lgorithm
s premised on the idea of natural
selection and genetic.
The basic concept of genetic algorithms is to simulate processes in
a natural system necessary for evolution

based on the principle of “Survival of the fittest”
as first laid down by Charles

Darwin
.
O
ne such model for decision making
,

based on
evolution

and application of rules
,

relies on

Genetic Algorithm for Rule
-
set Production

2

(GARP). These rule following methods are more organic in nature and sensitive to
mechanisms of variation, select
ion and retention.

1.3

Need for
a
Thin Client Inter
f
ace

Though
standalone
decision support
tools have come into existence over the last decade
,

they are highly CPU intensive

because of the iterative learning nature of genetic
algorithms
. They

demand more
than a st
andalone desktop can provide
,

potentially
stall
ing

the system

and render
ing

it useless for any other purpose.
DesktopGARP is one
such modeling tool that is in use
today
and
whose performance is

hind
ered by system
limitations forcing scientists to

redo their experiments.

It is in order to
supply

a
hindrance free working environment for scienti
sts to run their experiments on
,

that

this
research aims at
providing
a thin c
lient interface for DesktopGARP.

The goal is to
provide the same familiar inte
rface as the standalone application while performing all the
tasks in the background on a server
.

While client
-
server environments pose unique
problems of their own, they help alleviate the immediate need for CPU cycles by
bringing along with them a pleth
ora of resources
. This research thus
implement
s

DesktopGARP as a server side tool
,

thereby
removing

the load on the client side while
simultaneously providing a usable environment for multiple clients to
work
in parallel

without affecting the
individual
r
esponse times
.


The rest of this report talk
s

about genetic algorithms in

general
and GARP in
particular in
chapter
2
. Chapter
3

deals with

the general working of
DesktopGARP
f
ollowed by
implementation

specifics s
uch as
conversion to VB.NET and C#
,

and i
ssues with DLLs
in chapter
4
.
Finally, chapter 5 will talk about
conclusions and
possible
future
enhancements
.

3

Chapter
2

Genetic Algorithms

2.1

Introduction

Genetic algorithms are adaptive heuristic search algorithms premised on the idea of
natural selec
tion and genetic. The basic concept of genetic algorithms is to simulate
processes in a natural system necessary for evolution. They represent an intelligent way
to exploit a given search space to obtain meaningful results.

Each individual in the
search

space symbolizes a point and a potential solution.

The individuals in the
population are then made to go through a process of evolution.

A fitness function is then
used to evaluate individuals, and reproductive success va
r
ies with fitness.

2.2

Genetic A
lgorithm for Rule
-
set Production

Genetic Algorithm for Rule
-
set Production (GARP) was originally developed by Dr.
David Stockwell at ERIN Unit of Environment Australia and enhanced at the
San Diego
Supercomputer Center.

GARP is a genetic algorithm that cr
eates ecological niche
models for species. The models describe environmental conditions under which the
species should be able to maintain populations.
It is an artificial intelligence based
algorithm that works by combining sets of rules to build the most

accurate
prediction

possible for the region being considered.
For input, GARP uses a set of point localities
where the species is known to occur and a set of geographic layers representing the
environmental parameters that might limit the species' capabi
lities to survive.

It

searches
iteratively for non
-
random correlations between species presence and absence and
environmental parameter values using several different types of rules. Each rule type
4

implements a different method for building species predic
tion models. Currently there are
four types of rules implemented: atomic, logistic regression, bioclimatic envelope, and
negated bioclimatic envelope rules.

Ecological niche models produced are then projected
onto a landscape to provide a prediction of th
e species’ geographical distribution.

2.3

Rule Types

The general form of a rule is:

Given

that if A then
B and A is true, then predict B

The proposition
A

is referred to as the precondition and
B

is the antecedent.

A

can be
composed of several propositio
ns by use of conjunctions and disjunctions
. When a
precondition is satisfied a portion of the search space is selected.

Below we discuss in
detail the four rules implemented in GARP.

2.3.1

Atomic Rules

Atomic rule is the simplest form of rule. It uses o
nly a single value of the variable in t
h
e
precondition of the rule
.

2.3.2

BIOCLIM Rules

A BIOCLIM rule is based on the form of model used in the BIOCLIM program

for
predicting the range of a species from the enviro
nmental tolerances of a species
.
The
BIOC
LIM program develops a model th
r
ough enclosing the range of the environmental
values of the data points where a species occurs in a statistically defined envelope,
typically the 95 percentile range.

The environmental envelope defined by this range
enclose
s 95% of the data points where the species occurs. The distribution of the species
is predicted at those points that fall within that environmental envelope, and absence
5

predicted outside those points.

In contrast to the atomic rules, variables in BIOCLIM

rules may take a range of values instead of the variable taking on a single value.

A
number of other characteristics of BIOCLIM rules may be noted:

1.

The predictor variables need not be restricted to climate variables; any variables
other than
climatic va
riables can be used.


2.

The rule is defined by all variables
available

to the model, that is, a range is
defined for all variables even if they are not particularly useful in prediction.

3.

The rules are evaluated for significance and accuracy after formation
of the range
from the percentile range. This permits an accurate estimate of the quality of the
rule, which does not necessarily have a relationship to the percentile value.

4.

The negation of a BIOCLIM rule can be used to predict presence or absence.

5.

The r
ule can predict presence or absence of a species, but not both.

2.3.3

Range Rules

A

range rule is a
generalization

of the BIOCLIM rule. In a range rule
,

a number of
variables may be regarded as irrelevant, that is, all possible predictor variables need no
t
be used in the rule. When applying these rules, the undefined variables are
inconsequential and may take on any value as long as the precondition is satisfied.

The
rules above are useful when the response of a species has the form of environmental
toler
ances or limitations. Range rules also allow negation, i.e. the rule applies outside of
the indicated range.

6

2.3.4

Logit Rules

Logit rules are an adaptation of logistic regression models to rules. A logistic regression
is a form of regression equation wher
e the output is transformed into a probability.


As
with all rules, if the performance of the rule is deemed adequate (as determined by the
rule's "significance" measure) then the rule is maintained in the final model.

Figure 1 below shows the DesktopGarp
architecture.

The modeling kernel
requires data
point layer and the projection layer as input

and runs on top of the GARP algorithm
.
The
user interface is such that

the

users can specify the
maximum iterations the experiment
should run
for, convergence l
imit for the genetic algorithm, the percentage of training
data points

to use

and
rule types

that bind the
algorithm

execution.


Figure
1
:
DesktopGarp Architecture



7

Chapter 3

DesktopGARP

3.1

Overview

DesktopGarp is a standalone
application

that works on top of Intel/ Windows platform. It
is a
decision support tool that provides the graphical user interface and helps build a
bridge between the user and the decision algorithm.
It

is a software package for
biodiversity and ecologi
c research that allows the user to predict and analyze wild species
distributions.

It allows the user to manipulate the input via the interface. This affects the
decision to be made and the circumstances that influence the decision.

The data is
processe
d by the background algorithm and the output is displayed in
a format
meaningful to the user. In this case, there is just one window in which the user specifies
the parameters and the data to be used in the experiment.

Figure
2

below shows the
sample of
the DesktopGarp interface.

8


Figure
2
:
DesktopGarp Interface


Below is a detailed functional description of each user interface panel

currently in use
.

3.1.1

Species Data Points

The Species Data Points panel handles the species occ
urrence (point) data. A sa
mple of
this
panel

is shown in Figure 3
.

New species occurrence information can be entered by
clicking the Upload Data Points button.

This

will open a dialog box to specify the
location of the
occurrence

data file

on the hard

di
sk
.

DesktopGarp currently supports
three input formats that are required to strictly follow some conventions. The three
formats are Comma delimited, MS Excel Spreadsheets and ArcView Shapefiles.

9


Figure
3
:
DesktopGarp Species
Data Points Panel


Comma delimited and Excel files should contain three columns: the first one for species
name, the second for longitude, and the third for latitude. The first line in the input file is
ignored, so it can be used for labels. Each line of

the file represents a single data point
entry for the species. Data points for the same species must come together. Different
species names define different species for the software.

Choosing ESRI Shapefile brings
up a prompt for the species name colum
n. In this case, the feature class should be of type
Point.

The list box will present all species loaded and the number of data points (in
parenthesis) for each one.

The check box to the left of each species in the list allows the
user to control which s
pecies from the list will be used in the experiment.

In this panel,
the user can also specify two parameters that define how the data will be sampled and
used.

The first option allows the user to specify what percentage of points will be used
for trainin
g, i.e., model construction.


The remaining points will be used for testing.


If
100% is specified for training, no significance test will be performed on the models.

The
second option allows the user to specify a minimum number of points to be used for
t
raining.


To enable it, check the box to the left of this option.

When enabled, it will
override the percentage value and use at least the specified number of points for training.

This option is useful for species with few data points because it forces t
he program to use
10

a minimum number of points for analysis.

The algorithm typically does not perform well
with fewer than 20 data points for training.

3.1.2

Optimization Parameters

On the Optimization Parameters panel, the user can specify some parameters
that control
the overall behavior of the genetic algorithm. A sample of this panel is shown below

in
Figure 4
.

The number of runs defines how many times each distinct task will be
performed within the experiment. For example, for two species and 10 runs

per
experiment, 20 runs in that experiment will be executed: 10 for the first species and 10
for the second one.

The convergence limit establishes a stop condition for iterations
within the genetic algorithm.


Its behavior varies depending on how difficu
lt or easy the
problem is.

Usual values are between 0.01 and 0.10.

If this parameter is set to 0, the
algorithm will stop only when the maximum number of iterations is reached.


Figure
4
:
DesktopGarp Optimization Parameters Pane
l


Max iterations value establishes another stop condition for the genetic algorithm. It
forces the optimization to stop at the specified iteration, even if the convergence limit has
not been reached yet. More iteration tends to yield more stable results
. Usual values are
11

between 100 and 1000. The rule type checkboxes allow the user to specify which
algorithm is used to produce rules in the species model. The all combinations checkbox
generates one task for each combination of the checked rules. For e
xample, if range,
logit and atomic rules are checked, DesktopGarp will create tasks where only each of
those rules are used, then one for range and logit rules, one for range and atomic rules,
one for logit and atomic rules, and one for all three rules com
bined. This is useful for
analyzing the impact of each particular rule on the results. The labels below the
checkbox show how many combinations will be created and also the total tasks or runs
that will be executed (combinations times runs).

3.1.3

Enviro
nmental Layers

The Environmental Layers
or Native Range Datasets
panel allow the user to define the
environmental coverages that will be used as input for the prediction.


A sample of this
panel is shown below in Figure 5
.
The algorithm will try to correl
ate the input data
points to the values on those layers to get the final prediction.

The dataset combo box
displays the choices for the dataset that will be used on the experiment.

Once the dataset
has been chosen, DesktopGarp will automatically list all

layers present on that dataset on
the layers to be used list box.


There, the user can control which layers will be used by
clicking on the checkbox that appears to the left of each layer name.

12


Figure
5
:
DesktopGarp Environmenta
l Layers Panel


Below the layers list, there are three radio buttons that define how the selected layers will
be used.


The first one, all selected layers, will force DesktopGarp to use all selected
layers in the optimization.

All combinations of selected

layers will cause the experiment
to have one task for each possible combination of the selected layers. The

all
c
ombinations of selected size N


radio button has similar effect, but will limit the
experiment to the combinations that contains exactly N l
ayers.

The last two alternatives
using combinations of layers are useful for determining which layers are important to a
species.

3.1.4

Output Parameters

The Output panel specifies the output prediction map format and the output directory for
maps and oth
er generated documents.

A sample of this
panel is shown below in Figure 6
.

13


Figure
6
:
DesktopGarp Output Panel


The prediction maps can be generated in three formats:

1.

bitmaps: MS Windows bitmaps, with extension "
.bmp
";

2.

ASCII rast
er grids: ASCII text format, with extension “.asc”;

3.

ESRI Arc/ Info grids:
ESRI proprietary format for grid spatial data storage and
management.

A separate directory is created for each grid.

Another important file that is stored on the output directory is

the file result.txt

and
result.xls

which stores a summary of all tasks, error messages, result parameters,
statistical tests, accuracy, and more.

3.1.5

Projection Layers

In the Projection Datasets panel, the user specifies which datasets will be used in t
he
projection phase of the experiment. A sample picture of this panel is sh
own below in
Figure 7
.


Figure
7
:
DesktopGarp Projection Layers Panel


14

At the end of each task, DesktopGarp will project the rule set obtained during
opti
mization onto every dataset specified on the Current Datasets list. DesktopGarp will
also project the rule set onto the native range dataset, defined on the Native Range
Dataset panel.

A list of available datasets is shown on the Available Datasets combo

box.


The Add button adds the dataset selected on the combo box.


To remove a dataset from
the Current Datasets list, highlight it and then click the Remove button.

Figure 8

below
shows how the GARP algorithm operates on top of the data point layer and
projects the
results
over

the environmental projection layers

to obtain the predicted distribution
.


Figure
8
: GARP Data
and Results



15

Chapter 4

Thin Client
Implementation

4.1

Working of DesktopGarp

DesktopGarp is the
reengineer
ed
deskto
p version of the GARP algorithm

that
runs on
Intel/ Windows platform. It was first developed by R. Scachetti
-
Pereira for The
University of Kansas Biodiversity Research Center
.
While
the

front
-
end
user interface
along with some business logic
was

implemented using
Microsoft
Visual

Basic 6.0
, all
calls to
the
core GARP algorithm
were

implemented

as DLL COM components

in
Microsoft
Visual C++ 6.0
.

Below, we discuss
the important files present in the
DesktopGarp project and their functionality
.

Figu
re
9

below show
s

the state diagram of

the

DesktopGarp application.

4.1.1

frmMain.frm

This file c
ontains the graphical user interface of DesktopGarp

and acts as the interface to
the GARP
algorithm
.
It a
llows users to interact with the interface

and handles

all the
events that are triggered by these user interactions. It p
erform
s

client side validation on
the file types being uploaded and calls the supporting functions residing in the class
module files.

T
he total combinations

based on rule type selection

and
number of
runs

is

calculated

here
.

4.1.2

DataPoint
s
.cls

When the user interacts with the Species Data Points panel in the GUI,
cmdDataPointUpload_Click

function
in frmMain
is called. Depending on the
input
file
16

type being uploaded, the corresponding u
pload
function
in DataPoints.cls
is called. The
four functions are:


1.

UploadDataPointsFromShapeFile

2.

UploadDataPointsFromExcelWorksheet

3.

UploadDataPointsFromCsvFile

4.

UploadDataPointsFromTextFile

The
uploaded
file is
then
parsed to calculate the number of spec
ies present

and
each data
point is added to the
oDataPoints

collections object
as a

key
-
value pair
thereby
initializing it.
Once loaded into the
oDataPoints

object, the set up for the data points is
complete.


Figure
9
:
State Diagram for DesktopGarp

Select Data Points

Select Projection Lay ers

Set UI algorithm parameters

Upload / Uploading Data Points

Upload / Uploading Projection Lay ers

DataPoints Uploaded

Datasets Uploaded

Run GARP E
xperiment

17

4.1.3

DataPoint.cls

A call to
loadFromXMLNode

function
checks if the current XML node representing a data
point from the data points input is valid and contains latitude, longitude and

species

id.

4.1.4

Data
s
ets.cls

When the user interacts with the Environmental Layers panel in the GUI,
mnuDatasetsBasedir_Click
function in frmMain is called
.
This function calls the
ScanDirectory

function
in Datasets.cls which in turn calls
SearchDatasetsRecursive
function to

recursively search for the .dxl file in the directory.

The .dxl file
is an XML
file that
contains a list of environmental layer files to use while running the GARP
algorithm.
Figure 10

below shows a
classic

.dxl file.
Environmental layer files are .raw

files that are present typically in the same directory as the .dxl file and represent the
different environmental factors such as climate, rainfall and temperature.


Upon locating the .dxl file, the file is parsed to retrieve the individual .raw files wh
ich are
in turn parsed and stored as
oDatasets

collections object that contains the entire list of
environmental layer information. Once loaded into the
oDatasets

object, the set up for
the environmental data sets is complete.

18


Figure
10
:
Sample .dxl file

4.1.5

GarpExperiment.cls

Once the user
is done altering

the GARP algorithm settings via the GUI, the GARP
algorithm is
initiated

by

the clicking the Run Model button which triggers the
Button_RunModel_Click

event handler

function
.

At this point, all user inputs have been
parsed and stored into the
ir

respective objects. This function then calls the
RegenerateInputAsXML
function
in GarpExperiment.cls
which converts the objects
oDataPoints

and
oDatasets

into
the corresponding XML s
tring representation and
combines them with other user input data like rule types and maximum iterations
to form
19

one complete Garp

Experiment xml
string
representation.

This string is then loaded into
the XML DOM object

called
xmlDoc
.

The function
CreateT
asks

is then called to resample the species data points into two
sets: one for training and one for tests depending on the percentage specified by the user.

This function
then
loads the re
-
sampled data into another XML DOM object called
oDoc

and appends i
t as a child to the
xmlDoc

object
.

Finally, the
RunExperiment
function call manipulates this XML DOM object via calls
to
the GarpLib.dll which contains the core GARP algorithm.

The GARP algorithm
iteratively works on top of the
xmlDoc

object for
iMaxItera
tions

number of times
,

every instance producing

the required output files as requested for in the output panel of
the GUI.

These prediction maps are graphical representations of the predicted
geographic distribution of the species on a particular task wit
hin the experiment.
The
experiment

also generates an MS Excel worksheet and a text file containing the
summarized results of the experiment.


The conversion process was carried out keeping in mind that user interface provided by
the original DesktopGarp
standalone Windows application remained the same.

Hence a
similar

UI was created using .NET web forms.

This way, users did not have to re
-
learn
the application.

Figure 1
1

and 1
2

show the thin client interface
snapshot
of DesktopGarp

before and after run
ning an experiment.

20


Figure
11
: DesktopGarp
-

Before experiment

21


Figure
12
:
DesktopGarp
-

After

experiment

22

Output files are displayed in the Output Files panel and can be viewed
in the browser
by
selectin
g the file and clicking
the
Display Results button.

Figure 1
3

shows the snapshot
of a sample output file as seen on the browser.


Figure
13
:
Sample Output File

4.2

Issues with
Conversion

The conversion required converting approxi
mately nine thousand lines of Visual Basic
6.0 code (also called unmanaged code because it is outside the Common Language
Runtime framework) to Visual Basic.NET (also called managed code).
To facilitate this
process, an auto code converter that converts h
undred lines of
VB
code at a time

to
VB.NET

was used.

Though this conversion process did sav
e a lot of time, it also
23

managed

to introduce a lot of bugs not originally present.
Some of the most common
bugs
caused because of the
conversion process
are desc
ribed below.

1.

T
he numerous references to the GARP DLL files to execute the cor
e algorithm
could not be handled

as conversion was only hundred lines of code at a time.
This generate
d

many upgrade warnings.
The conversion process created
many
new objects
of the DLL
classes

in order to handle this error.

2.

A variable of type double was converted
to integer and
a variable of type
integer

was converted to

short.

This was because in
the
.NET

environment
, the datatype
for 16
-
bit whole numbers is now Short, and t
he datatype for 32
-
bit whole numbers
is now Integer

(Long is now 64 bits)
.

3.

The

CLR runtime
requir
e
s

that all objects be instantiated using the “new”
keyword. This was not a requirement in VB 6.0 and the conversion process was
not able to handle the situat
ion effectively.

4.

F
unction call
s that

had both call by value parameters and

call by reference
parameters w
ere not handled effectively, in that, call by value parameters were
changed to call by reference.

5.

One of the most subtle issues was the fact that the
C
LR
runtime environment
requires t
h
at all objects be instantiated during compile time. VB 6.0 created
objects at runtime. Though this is not thrown as an error in CLR
runtime
environment, it would disable the intellisense of the objects.
This caused a lo
t of
errors as i
t was not possible to verify the properties
and functions

an object
supported.

24

6.

VB specific properties such as “cType” had to be changed according to the
System.Convert namespace to better gel into the manage
d

code of the CLR
runtime

environ
ment
.

7.

One of the major
problems

faced was due to the fact that the original
DesktopGarp application was a standalone windows application. To convert it
into a client
-
server environment required that every object’s state be
somehow
saved across the statele
ss web’s request and response cycle.

For this, suitable
points of storage had to be located. Two important points were located
: one was
just after the user’s species data point object
oDataPoints

was populated and the
other was just after the environment
al layer object
oDatasets

was populated.

These were identified as the

only two objects that had to be

stored

as they

are the
container of all data and
also
the final
XML DOM object is constructed using
these

objects
.

These objects were hence loaded into
session variables
immediat
ely after they were constructed and re
-
constructed from the session
variable as and when required.

All the above issues were dealt with and solved for user inputs files of type .csv
(comma

separated version).

The VB.NET web appli
cation was
successfully implemented
for this
file type.

Microsoft Excel (.xls) input file types were not dealt with as it was found that
the original DesktopGarp V
isual
B
asic

application used
the Excel.exe COM component
that implemented
certain
features t
hat required separate licensing

when used for the web
.

OWC
11.dll, which is the web equivalent for Excel.exe
COM

component was tested as a
replacement but
with little success.

25

4.2.1

Conversion to C#

The same mechanisms that were user for the

conversion fro
m Visual Basic to Visual
Basic .NET were used to convert Visual Basic .NET project to a C# project. The
conversion process involved converting hundred lines of code at a time. As expected,
most of the errors were because of the conversion process and are

the same as discussed
above.

One of the most significant
problems
, however,

was with the dll files.

It was
observed that the
original
dll files were created in view of the Visual Basic application.
As a result, functions and methods
within the dll clas
s
had the
optional

parameters
and
variant

types
that are
supported in Visual Basic.

C# does not support both
optional

parameters and
variant

types.

This
rendered
the dll files
useless within the C# project.

Also, function names were changed
and their op
tional parameters were now mandatory
when the original dll files were used as direct references.

To overcome th
e
s
e

issue
s
,
wrapper
dll
classes

were created around the
classes
present
in the
original
dll files

and
function calls were
manipulated to suite t
he original
version.

Other language specific
i
ssues such as lack of support for


Collection


objects which is widely used in the
original application rendered conversion to C# infeasible. It was hence concluded that
recoding the application in C# would b
e a better option.

4.3

Issues with DLL
F
iles

4.3.1

Introduction

The core GARP algorithm is implemented in Visual C++ and resides in a DLL file called
Garp.dll. This dll uses two other supporting dll files called ShpLib.dll and
CombEnum2.dll.
Initially, t
hese dll files were plucked out of the installation directory of
26

the DesktopGarp installation and used within the project.
This was done

because
installation would automatically
guarantee

that all the dll files
are
registered on the server
and no further
action needs to be taken to ensure this.

While trying to add these dll files
as
COM
reference
s

within the .NET framework,
the CLR environment
complained
saying that the dll files were not registered

and hence a reference
could

not be added
.

Even separate
ly registering each dll using the
regsvr32.exe <dll name>

command did
not help.
This problem could only be solved by installing DesktopGarp in the bin
directory of the project and then adding the dll references to the project.

This ensured
that the dll f
iles are registered
from

exactly the same path as required.


One other issue with dll files was the way objects were declared in Visual Basic 6.0.

In
Visual Basic, the objects were declared using the following syntax:

Set <object> = CreateObject("<class a
s string>")

This is known as late binding. The CLR runtime environment manages code
better
via
early binding
. The advantages of early and late binding are discussed below.

4.3.
2

Advantages of Early Binding

Some of the advantages of early binding are as f
ollows:

1.

Because objects are compiled upfront,
the compiler can better allocate memory
and
the code runs considerable faster.

This is not possible in the case of late
binding because objects are
compiled

at run
t
ime.

2.

Because objects are compiled upfront, d
ebugging is easier.

3.

Early binding provides full access to the object

s
in
-
built constants,
properties and
methods via intellisense

and the object browser
.

27

4.3.
3

Advantages of Late Binding

Some of the advantages of late

binding are as follows:

1.

Late binding
makes the compiled code version independent as objects are
compiled at run time.

2.

Projects with lots of references take longer to compile each time and hence
compiling

the code

on the fly would be an easier option.

The CLR runti
me environment did not allow
these COM component objects to be
declared via late binding and threw the following run time error:



Object reference not set to an instance of the object

This was overcome via early binding and instantiating the objects usin
g

the
new

keyword
.

4.4

Visual
Basic
versus

.NET Environment

While both VB.NET and C#.NET provided equally rich environments for managed code
,
they provided little
support

for

backward compatibility towards

unmanaged code
.
It is
obvious that Microsoft has reengineered the .NET framewo
rk rather than just deliver it as
the next version for Visual Basic.

That said, the .NET environment provides a far
more
robust
, secure

and
a

rich

development

platform.


The DesktopGarp

conversion from the unmanaged Visual Basic code to VB.NET
as such
d
id have numerous errors and upgrade warnings.
The converted product does not
fully
utilize the features provided by the .NET platform.
For example, the application still uses
MSXML
2
.dll for manipulating the XML objects rather than the System.xml library
provided in the .NET environment.
Hence, o
verall the .NET framework is definitely a
better option than Visual Basic.

28

Chapter 6

Testing

and Performance Evaluation

DesktopGarp is primarily
based on genetic algorit
hms
.

As with
every

other genetic
algorit
hm
, GARP refin
es
its search space until the
user defined
convergence limit is
reached or until it has run a specific number of iterations.

As is obvious, DesktopGarp is
heavily CPU bound.
Performance of such an application depends primarily on the power
of the machine it is being simulated on.

Microsoft Application Center (ACT) t
ests were
carried out on a
Pentium machine and the results obtained are analyzed below. Tests
were simulated for two hundred users and ten simultaneous browser connections. Fig
ure
1
4

below shows the graph of the number of requests handled by the server per second.



Figure
14
: DesktopGarp

Thin Client Performace Measure


As can be seen from the graph, the peaks indicate the times when the server is fre
e and
hence can accept client requests. DesktopGarp being heavily CPU bound, takes up a
large number of CPU cycles and clogs the server. The
troughs indicate the times when
the server is actually executing the genetic algorithm and is fully utilized. He
nce, it is not
able to accept any new client reque
st. This argument is further justified
by

the statistics
obtained
from the tests
as shown in figure 1
5
.

29


Figure
15
5
: Microsoft Application Center Test Statistics

From these tes
ts, we can see the need for distributed programming. Distributing such a
CPU bound application would provide for faster response times.

30

Chapter 5

Conclusions and Future Work

5.1

Conclusions

The project was aimed at providing a thin client interface for

the GARP algorithm to aid
scientists in their research by providing at their disposal
high end
client
-
server
technology.

The DesktopGarp application was successfully converted to a VB.N
ET

web
application
for

csv
input
file

types

w
h
ile main
t
a
in
ing the sam
e interface as the original
standalone application.

Conversion to a C# web application from the VB.NET web
application was
also
carried out. It was found that every
DLL

file in the VB.NET web
application required a corresponding wrapper class in order to

maintain the same
functionality.

Also, since the original code was written in Visual Basic, there wer
e
many

language sp
ecific issues that had to be dealt with
. It was
hence
concluded that recoding
the application in C#
would be a better option as this w
ould also permit better use of the
C# language and
the
CLR runtime environment.

Also, as a standalone application DesktopGarp searched through the
directory

recursively
for the required

dependent input files. This was not feasible in a web application
whe
re
the user had to upload all the dependent files for the algorithm to run successfully.

This
was found to be the biggest drawback for going against a web application.

5.2

Future Work

The web application required a whole new bunch of supporting environmen
tal layer files
each time the species data points had to be evaluated for different environmental factors.
This required that the user upload a
ll the supporting files to run the experiment.

This was
31

the biggest drawback.

It is also known that the enviro
nmental factors for a region do not
change. Running the web application to test against only a pre
-
defined set of
environmental layers would require the user to upload just a single species data point
layer.

The DesktopGarp web application can hence be
us
ed to experiment against

only

the most commonly used
environmental factors.

This would require a minor change in
the
functionality

where the user selects
from a list of
predefined

environmental layer
groups
.

Also, DesktopGarp being a standalone windows a
pplication, it would better suite
to integrate it
as a tool into
ESRI’s ArcGIS software.

This is understandable because
DesktopGarp is mostly used
by scientists
who
feed

the DesktopGarp output
into

their
GIS applicat
i
ons. It is also a known fact that ESR
I’s ArcGIS software supports Visual
Basic for Application which an equivalent to Visual Basic 3.0.

This would require
modifying the existing DesktopGarp application to make it backward compatible

to suite

the GIS needs.

32

REFERENCES

[1]

The University of K
ansas Center for Research, Feb. 2002
;

http://www.lifemapper.org/

desktopgarp/

[2]

Karen Payne and D.R.B Stockwell, “GARP Modelling System User’s Guide and
Technical Reference,”

http://biodi.sdsc.edu/Doc/GARP/

Ma
nual
/

manual.html#Introduction

[3]

Naranker Dulay, “
Genetic Algorithms,


htt
p://www.doc.ic.ac.uk/~nd/surprise_96/

journal/
vol1/hmw/article1.html#introduction


[
4
]

Glenda Eoyang, “
Genetic Algorithm as Decision Support Tool
,”

1996;
http://www.winternet.com/
~eoyang/gene
ticalg.htm

[
5
]

Visual Studio
Language Equivalents,

2005;

http://msdn.microsoft.com/library/

default.asp?url=/
library/en
-
us/dnvb600/html/ vb6to
vbdotnet.asp

[6
]

Stockw
ell, D. R. B., and D. P. Peters,


The GARP modelling system: Problems and
solutions to automated spatial prediction
,”

International

Journal of Geographic
Information Systems
.

1999
.

[7
]

Stockwell, D. R. B., and I.

R. Noble,


Inductio
n of sets of rules from animal distribution
data: A robust and informative method of analysis
,”

Mathematics and Computers in
Simulation
,
1992
.

[
8
]

N
ikhil Kothari and Vandana Datye
,

Developing Microsoft ASP.NET Server Controls and
Components
,
Microsoft Pres
s
, 1 e
dition, 2001.

[9
]

Melanie Mitchell,
An Introduction to Genetic Algorithms
,
The MIT Press, 1998.

[1
0
]

David E. Goldberg,
Genetic Algorithms in Search, Optimization
, and Machine Learning
,
Addison
-
Wesley Professional
, 1989.

[11
]

Alex Homer, Dave Sussman
, Rob Howard, Brian Francis, Karli Watson

and

Richard
Andreson,
Professional ASP.NET 1.1.
,

Wrox, 2004.


33

[12
]

Joel Murach

and

Doug Lowe,
Murach’s C#
,
Mike Murach & Associates, 2004

[13
]

Dino Esposito,
Applied XML

Programming for Microsoft .NET
,

Microsoft Pr
ess, 1
edition, 2002.