Re: Averager usage

[sme]

[Moved to from swarm-support to swarm-modelling]

Thanks Ken,

Another unfortunate consequence of the time-zone difference Jan
mentioned is that after pulling an all-nighter to solve a problem that
I posted to the list earlier I wake to read a far more elegant
solution ... and last night's efforts labelled 'hackish' ;-)

>>>>> "Ken" == Ken Cline <address@hidden> writes:

    Ken> The possible work-arounds that pop into my head immediately
    Ken> are: (1) subclass or modify the Averager class directly (and
    Ken> maybe the matching protocol as well), (2) use some type of
    Ken> closure or nested function (ala Java inner classes) or (3)
    Ken> use another (possibly global, singleton) object to hold the
    Ken> target pigment and species information when `update' is
    Ken> called.  I think #3 is probably the easiest but feels a
    Ken> little hackish.

    Ken> Hmmm... actually you probably don't really need the
    Ken> "SpeciesPigmentInfo" singleton, you can store this
    Ken> information directly into each WaterClass.


    Ken> (IMHO, the first two options I suggested are more appealing
    Ken> from a coding-style point of view.  One reason for this is
    Ken> that they couple the selector with what is being selected.
    Ken> In a multi-threaded environment, hacks #3 & #4 would be risky
    Ken> without using a little resource locking.  But I digress... )

Yes, and by the time you've got this it seems more efficient to simply
use a line of C to average the pigments and save incurring additional
method calling overheads by using Averager!

I freely admit that my coding style is "C hack, ObjC wrap, Swarm
deliver"! Although with 10K line of code and only 3 months to thesis
submission I'm stuck with it.

Option #2 interests me. I don't know Java but the "In a Nutshell"
comments on nested and member classes esp. scope versus inheritance
are well received. 

The classes in my model (planktonClass, phytoClass, zooClass,
waterClass, oceanClass), as their names suggest, closely mirror
physical structures in the problem domain. This has been seen as a
major advantage of the OOP paradigm for ecological modelling although
some regard the class structure too rigid to represent biotic
interaction [Derry (1998) Ecol.Model.107,145]. In my case, the
superclass of phytoClass and zooClass, planktonClass, was the
"natural" place to have methods for interaction although I'd have been
less happy if I'd been modelling planktiverous whales! My previous
problem could be solved by having a pigmentClass subclassed to
phytoClass without breaking biological realism (option #3). My reason
for constraining my class hierarchy has been on the assumption that
message passing eats cycles in a model that already solves a primitive
equation ocean mixing model, a spectrally-resolved sea surface
irradiance model, and a runge-kutta solution of 1+3*phyto+zoo state
functions every simulated 15 minutes (roll on the PetaFlop hardware I
want to ramp up!).

The Runge-Kutta routine is a case where #2 would be an ideal
solution. At present it is in a top-level class needing to use
instance variables from phytoClass, zooClass and waterClass. As it's
purpose is to "advance the biology" I've always considered that it
would be better placed in planktonClass so it can access all the
biotic variables without message calls (apart from getting nutrient
and light from the waterClass which at least maintains biological
integrity).

Reading the ObjC manual I didn't get how, or whether, you can use
Java-like member classes. I've seen examples where people have two or
more classes in a single .m file but they appear to be top-level
classes without implicit access to each others instance variables. Am
I wrong? 

I guess I'm at the stage where I'd like to start afresh. I looked into
available CASE tools and design methodologies at the start of the year
with an interest in reverse engineering my model into UML. Ha! At
SwarmFest 98 a breakaway group talked about UML - did anyone get
anywhere with it? I've noticed one use in 3 years on the
list. Personally, I found it hard enough going to give up. In any case
I'm of the opinion that existing software engineering practices are
geared towards a supply-demand client-server problem domain that
doesn't address the needs of scientific models which, by their nature,
are exploratory.

What experiences have other users had? Are we predominantly a hive of
utilitarian hackers evolving out of the knowledge that both Swarm and
the operating system are rapidly changing environments. The need to
muck about with the innards is but an upgrade away ;-) Since most
users have specific problem domains I'd be interested how people have
dealt with the problem of transforming their conceptual models into
Swarm code. What tools have been used? Have formal verification
techniques been used? To what extent are classes designed for
reusability? To what degree has using Swarm enabled you to separate
conceptual modelling from implementation?

To a large extent computer modelling is paradigmatic of scientific
method ... science progresses more through instrumentation than
rationalism (after all it's not philosophy *grin*) so it's not
surprising the uses a scientist can find for a "general purpose
machine". It's become accepted that a modelling paper specifies the
platform on which it ran. Reading older papers in my field I try to
guess - 8-bit mainframe/punched card/FORTRAN, 8086 512K RAM etc. Guess
I know why none of them considered an individual-based plankton
model!. 

The scope of a model is constrained by the hardware. Furthermore, the
design is constrained by the software. If, then, science develops at a
pace determined by advances in the computer industry we must be
thankful that playing Quake (O.K. I'm outta touch) and watching DVDs
suck CPU cycles! A direct consequence of improving computation seems
to have been the development of systems models->IBMs->multimodels. I
know that large-scale models have code control (a colleague sends off
code to Bracknell to run on their GCM - definitely not "quick hack"
territory). However, with few exceptions [such as Laval (1997) MEPS
154,1] other models has been written without using software
engineering. How then can they be verified? A theoretical model may
*only* be testable by verification and not by validation (a common
situation in the antialias prone oceanographic environment). Heuristic
models can invariably be "tuned" to fit validation data and predictive
models without verification are on as shaky ground as astrology!

Perhaps I'm unlucky. Having taken options in software engineering
(which proved to be no real preparation for practice!) I've known the
pitfalls and am dissatisfied with my solutions. Colleagues without a
computing background seem to cope without such retrospection. Theses
get written, papers get published. The computer, after all, is just a
tool. They are ubiquitous. A skill to acquire.

During my Master's a lecturer in software engineering suggested that
Visual Basic brought down more small companies than did the
recession. His argument was that every cost-conscious proprietor
risked his/her livelihood by relying or ersatz DIY programs.
Drag'n'drop ... tappity! tap! ... that's my stock control system!
Maybe a sweeping assertion but I've seen examples. I've also found
semantic errors in code that has quelled premature enthusiasm with
some output or stiff-lipped embarrassment with a published result (not
guilty of the latter ... yet).

I apologise for my indulgent rambling. Unbridled from thesis
constraints I couldn't stop myself!  I had hoped at this stage to have
been able to make a strong argument for the use of OOP, Swarm,
software engineering practices along the lines of testability,
reusability, quality assurance and high-level modelling. I'm willing
to admit that I am not as smart as I had hoped. It would help for my
thesis though to have polled other users thoughts. 

Regards
Steve

-- 
  Steve Emsley                    Ecology & Epidemiology Group
-----------------------------------------------------------------
  address@hidden                   University of Warwick


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================