as i mentioned before, the last time i talked to high performance systems,
i got the impression that they were not considering a port of stella
the the pc. although i believe that there is some talk at pugh-roberts
of putting a graphic front end on dynamo for windows. as i remember,
however, the cost was going to be exorbitant.
as for moving stella stuff around, it can't actually be transported in
ascii, but like any mac file there's no reason it can't be binhexed
for transport on the wires.
another alternative would simply be to use the dynamo equivalents of the
stella diagrams. these diagrams are, after all, just exactly the kind that
dynamo modelers draw before committing their models to code. they can
be sketched from code just as well. for example, the dynamo code for the
drawing i posted is as follows: (with exhaustive comments... please bear
with me.)
l level1.k=level1.j+(dt)(rate1.jk)
this is a level equation, stating that a level variable named level1
will at time k be equal to its value at time j (the previous timestep,
k-1), plus some difference defined by a rate times the integration
interval.
n level1=1000
an initialization statement, setting the value of level1 at the beginning
of the run.
r rate1.kl=-10+error.k+noise()
the rate of change of level1 is defined as a constant depletion of -10
per timestep (there's your hole in the tank) plus the current error value,
plus the output of a noise function (whose parameters i have forgotten...
i think they are mean and sd. one could also use a suite of function
generators.)
a error.k=reflevel-perclev.k
an auxiliary equation defining the error as the difference between a
reference and the current perceived level.
c reflevel=500
constant definition for reference level.
a perclev.k=delay1(level1,5)
one possible transformation of actual level1 to pereceived level. the
perception of level1 lags by 5 time intervals (not integration intervals).
other possible transformations include table lookups, where the perceived
level is a function of real level, which can even be drawn on a graph.
and that's basically it. without all the comments it's only 5 lines,
leaving out a couple of lines of program run specs. the language is fairly
straightforward, and is, for me at least, a comfortable crossover from
mathematical to textual representation. the equations also clearly define
the drawings from which they derive. and you don't have to worry about order
of calculation, either. the dynamo compiler manages that for you.
all of which is to say that i think we've got workable alternatives to
ascii graphics for the effective communication of model structures.
-----------< Cognitive Dissonance is a 20th Century Art Form >-----------
Eric Harnden (Ronin)
<HARNDEN@AUVM.BITNET> or <HARNDEN@AMERICAN.EDU>
The American University Physics Dept.
4400 Mass. Ave. NW, Washington, DC, 20016-8058
(202) 885-2748
---------------------< Join the Cognitive Dissidents >-------------------