sorry for not answering sooner, but I am very busy trying to get ROOT v2.0
out of the door.
Concerning your simulation problem. I think the ROOT framework would
be able to provide most, if not all, of your needs (being one of
the main authors I am of course slightly biased -:)).
Concerning interprocess communication, we currently support TCP/IP sockets
and shared memory. Both methods support full object semantics (i.e. objects
can be passed by value between processes).
Concerning animation/visualization, v2.0 wil come with a new fully scriptable
GUI kit and the current graphics supports already fairly well animation.
Once you've integrated your classes in the ROOT framework (usage of the
ClassDef/ClassImp macros and TObject inheritance) you can generate
automatically the full reference documentation via the ROOT THtml
documentation generation system.
Also once the above condition is true, all your classes can be made persistent.
Either as single objects in a database or as a collection of identical objects
in a special Tree container.
Trees are typically used for the storage of many, many objects of the same
class (i.e. events in high energy physics, bills or persons in some
business applications, etc.). Run state is probably best written out as
a single object (just runinfo->Write() could do the job). During analysis
you read in this runinfo object to get back the run state. State (time slices)
during the simulation is probably best collected in a Tree. How to partition
the tree in branches depends a lot on the expected access patterns during
the analysis phase. Each object attribute in a single branch (automatic
split mode) makes sense when you plan to access only a few attributes
at a time during analysis. If you always plan to access all attributes
of an object it makes sense to put this object in a single branch.
Multiple trees might also be an option in certain cases.
All platforms you mention are supported (alpha/linux is coming soon).
If you have more specific questions or would like some more discussion
don't hesitate to contact me.
Cheers, Fons.
>
> Hi!
>
> I'm currently evaluating the use of ROOT in our in-house simulation of
> factory-floor and warehouse operations, and am looking for comments on
> this type of application...
>
> Background:
> Plattforms: Intel/Linux, Alpha/Linux, Alpha/Digital Unix
>
> The simulation currently is partitioned into 3 areas:
> - Simulation-engine itself, i.e. no graphics, analysis, etc.
> This consists of 3 processes (warehouse, disposition and
> assembly-lines) communicating via pipes. Input and output data
> (some 100Mb) is in ASCII format. They are implemented in
> C++ using some self-made utility classes, and basically flat
> inheritance..
>
> - The animation/visualization GUI: Tcl/Tk, which reads the ASCII
> files produced by the engine
>
> - Manual and automatic analysis generation, via perl, some clever
> Makefiles, output in SGML(DocBook).
>
> As the current version suffers from some design and implementation
> faults, and has to be adapted to new requirements, a nearly total
> rework is planned.
>
> My current plan would be to use ROOT as the application framework for
> all three areas, utilizing the utility classes/RNG and TTrees in the
> engine, and using the GUI and rest of the framework in animation and
> analysis generation (which would probably be folded into one
> application)...
>
> Would anybody like to comment on this, i.e. do you think this makes
> sense, is appropriate, etc.? Things I should look out for?
>
> A more specific question that I have:
>
> Given a warehouse, which is partitioned into different named locations
> (which are fixed within one simulation run, but may differ between
> different runs), I would want to write out the current state
> (i.e. number and type of parts, etc. in each location/sublocation)
> every time an event has influenced the warehouse.
>
> Using TTrees for output, I can't quite make up my mind, which would be
> the best way of arranging the different parts, such that I can simply:
>
> - write out the whole warehouse-state for every event during simulation,
> - select only one location, and graph the resulting levels of usage
> for the whole duration...
>
> It seems to me, that branches would be the way to do it, but all the
> examples either use auto-branching of a fixed object-type
> (e.g. Event), or create branches manually for things that are totally
> different in number and name between events (e.g. Tracks).
>
> It seems to me, that this is a simple problem to solve, and I'm just
> missing something...
>
> Any help, comments, etc. will be much appreciated...
>
> TIA
>
> Regs, Pierre.
>
> --
> Pierre Mai <dent@cs.tu-berlin.de> http://home.pages.de/~trillian/
> "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
>
-- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland Phone: +41 22 7679248 E-Mail: Fons.Rademakers@cern.ch Fax: +41 22 7677910