Re: [Swarm-Modelling] Question

[Susheel Varma]

Dear Swarm users,

Sorry about the delay in my response, but I was waiting to see how the
thread develops. Its interesting for us to see some interest in Flame
and talk of possible collaborations. Just to help you all understand
our framework, in lieu of possible collaborations; I will try to
explain our framework in a little detail. The main features of Flame
are high performance and a formal testing capability. There are three
main components to Flame:

a. Agent specification via XMML(X-machine Markup Language)
b. User defined functions or behaviours associated with each agent.
c. The core compiler/parser that will generate a serial and/or
parallel version of the code.

The agent specification is just a list of agents specified by its
memory(parameters), functions(behaviours) and messages. The agent
communicates through messages and functions can read these messages to
perform a certain task associated to that agent. There is also a
special function(X-machine) that allows the agent to arbitrate between
messages and relevant functions. All of this is specified via the XMML
document.

Each behaviour or function can be specified in any language, but will
have to some how manipulate internal C structs. We are also currently
developing bindings for Java and Python. Note, that bindings to any
language other than C will have performance issues. Performance is
very critical for us, and hence we would recommend the use of C
functions, as we are able to perform bit-level optimizations to the
generated executable. The modeller can access the internal data
structures through an C API that abstracts serial and parallel
versions of the internal code. We did review Swarm early on, and did
find it to be very useful as a benchmark. Swarm excels at providing
fantastic high-level interfaces to ABM, while we specialise in high
performance and testability. A by product of using a underlying formal
X-machine model is that we are able to test the model, without
actually running the code for simulating a million agents.

The core parser/compiler will parse the XMML definition and the
related user-defined functions to generate optimized code for your
platform. We currently support a large number of HPC platforms and
user desktops(*nix, mac,pc). The only extra C dependencies for the
generated code will be MPICH for the parallel version else none apart
from the standard C libraries. All other dependencies are
user-dependent. For eg if a user writes code that calls a specific
Math library eg. NAG then that dependency must be handle by the user
themselves, by adding the required headers and compilation flags. The
generated code has certain runtime functions performs intelligent load
balancing and message arbitration between compute nodes in the
parallel version to achieve optimum performance. We are also currently
building a hybrid threaded version of Flame to achieve better
performance.

So to allow Metascape to generate Flame code, all that needs to be
done is to transform your meta-model to a Flame XMML document and
user-defined functions wrapped in C. The reverse use-case might be
tricky to achieve, although we do have two concurrent projects that is
looking into specifying high-level code as part of the XMML itself and
libraries. This won't allow us to completely remove all the
user-defined functions, but rather it will be embedded within the XMML
itself as tags. There are certain issues regarding this, an example is
what are the fundamental concepts we should aim to support, list,
tuples, while loops, etc to acheive maximum usability. For now, this
might just be data structures and algorithms used in our use cases
alone, which are sub-cellular and cellular, population and economics
modelling.

Hope this helps clear up things about Flame and hope this will kindle
your "flames" of curiosity in our project. Sorry for the length of
this email, I didn't have the time to write a shorter one.

Sincerely
Susheel

--
Susheel Varma
Flame Development Team (www.flame.ac.uk)


On Fri, Mar 21, 2008 at 5:31 AM, Miles Parker <address@hidden> wrote:
>
>  On Mar 20, 2008, at 5:39 PM, Marcus G. Daniels wrote:
>
>  > Miles Parker wrote:
>  >> I'd really want to be able to parse the isolated C bits, e.g. from
>  >> the xml, not the generated code -- dunno if that would be possible
>  >> w/ this approach.
>  > The idea here would be to have the C/Java compiler write out a
>  > suitably high level intermediate representation (e.g. as XML), and
>  > then direct embed that in the model.   The goal being completely
>  > eliminate the need for opaque procedures, in favor of a
>  > representation the model development environment could directly
>  > manipulate.
>
>  Exactly, that is on the metaABM --> Flame side, right? That's "easy".
>
>  I was just thinking idly about the other side, though the use case
>  isn't really there..
>
>
>
>  >
>  >
>  > _______________________________________________
>  > Modelling mailing list
>  > address@hidden
>  > http://www.swarm.org/mailman/listinfo/modelling
>
>  _______________________________________________
>  Modelling mailing list
>  address@hidden
>  http://www.swarm.org/mailman/listinfo/modelling
>