Subject: Re: Julius's presentation on Visulisation Date: Mon, 30 Aug 1999 14:11:56 +0200 From: Julius Hrivnac Organization: CERN To: Stephen Haywood CC: atlas-atf@atlas-lb.cern.ch References: 1 Hi Stephen, > Concerning a forum for discussion of Exception Handling etc., etc., I am not > sure where the appropriate place is for all of these things, but one might > start discussion in the Weekly Software Meeting and take it from there ? The Weekly SW Meeting has limited and unstable audience. I'm afraid, more systematic approach is needed. > The Graphics Meetings are probably the best place to discuss Graphics > Libraries. I have mentioned your question about GUI libraries etc. and will > record it in the recent ATF Minutes in an attempt to get some sort of > response. We will prepare some proposal (in October) for the graphical libraries. > My understanding of the interaction between us and your group is that we > are providing the fundamental tools to control Dataflow, access Data, > interact with the Classes provided by other Domains etc so that with > the Visualisation specific code, you can build Applications, ie. Graphics > (or Analysis) programs. Yes. > I see your Visualisation 'Glue' as a Framework (Toolkit) which sits on top > of the Atlas Framework, which in turn will sit on a Framework of basic > Class Libraries. This is how the Gaudi guys illustrated things. Mostly yes. I would only add that it is one part of the Atlas Framework (where nothing except final application depends on it). > I understand the separation of Data Objects from their Graphical > Representations. Presumably this leads to greater flexibility (more > modularity) and more compact (less complex) Objects (although more of them). Yes. There are really many objects needed for Visualization. But it doesn't create any serious problem, because: 1) Functional (dummy) classes are created automatically by the Wizard-like script. So if someone doesn't need something, he can ignore it. 2) Everything will be available in shared libraries (when external references allow). So user will only load what he needs. > To what extent do you see the Visualisation Domain as you conceive it > touching the On-line environment ? For sure On-line displays will be very > valuable, but the way in which they see Data may be quite different from > the Off-line. I don't know whether there would be a need to take Data from > the Event Buffers (this may be in common with the requirements of the > Event Filter), and maybe one will want to spy on Data before complete Events > will have been built. > Would all of this impose special Requirements. I hope VALERIO could comment > on this. What is the current thinking ? See my answer to Valerio's mail. > The Data Model will presumably have a 'fundamental' representation, as well > as representations for Simulation (presumably close or identical to the > fundamental and related to the G4 descriptions) and Reconstruction. > What would be required for the Graphics ? Just your 'Representation' Classes > - any other Requirements ? In the current Graphics Design, there's one requirement: Each visualized object should inherit from something. Empty class with just virtual destructor is enough. This requirement is there so Graphics can use RTTI for run-time identifications of objects. Event this requirement can be, however, removed for limited number of classes. This will be necessary for small objects (in the OODB), where even the space overhead of that inheritance would be unacceptable. > When you say 'Logging', this sounds like a Data Browser - is it ? No exactly. It's just textual snapshot of the objects. Writing log-files. > You talk later about an Object Browser. Such a thing would be useful to > 'dump' an Object's data for debugging in batch mode, Object Browser itself is mostly interactive application (very much like file browser in your favorite OS). But the used technology (in fact, what is now in graphics/ObjectBrowser package) will allow dumping of objects. The question, however, remains, how much sense has just dumping single object. > and also to be used in > an interactive manner to browse/check data, either standalone or while using > a Graphics Application. Yes, this is the Object Browser. It will allow (graphically) navigate through the data, inspect them and send them into other Scenes. > The Graphics will need to interact with the Simulation to interactively > simulate sets of particles traversing the detector. I assume this does not > impose any special constraints, in so far as the Simulation code will create > the appropriate Objects, which the Graphics will subsequently display. > This will be valuable for debugging. See my answer to mail from Valerio. > Does Reconstruction impose any constraints ? It would be nice to reconstruct > interactively to test new algorithms and get insight. What might be > interesting is to be able to select hits on a track using a mouse and refit > the track. This might involve some more complex interactions. One can > envisage a general desire to interact with the data 'by hand' and then > repeat the reconstruction. Graphics Design does foresee this (as the fulfillment of the "Context Sensitive Actions" requirement). It is not implemented yet, mainly for two reasons: 1) We don't have needed objects and code from Event+Reconstruction (Track,...). 2) There is still discussion going on about the real usefulness of it. The idea is, that user would be able to inspect and change any (?) data member and even call any (??) member function from the UI (for example Object Browser). The question is, should it be just access to "bare" objects or should there be another layer making the access more relevant (Model object is appropriate for implementing that layer) ? Afterall, data members should be "private" :-) And calling most of the member functions in isolation doesn't have much sense. > >From your comments, I understand that the details of the Visualisation would > be largely decoupled from the rest of the Architecture, and hence the > Graphics Domain could fit easily into an Architecture like Gaudi or something > similar. Do you know if the same would be true of Object Networks ? Object Networks don't impose any constrain on the Graphics itself. We would have only to "dress" our Scenes with the module envelopes. Logically, it's quite natural to see Scenes as "filters" (const or non-const, i.e. changing or not the object flowing through). The same is probably true also for other Domains: Object Networks Design doesn't impose very much on the design of that Domains, it changes the way, how they are used. I.e. how the top application is built. Julius -- ######################################################################## # E-mail: Julius.Hrivnac@cern.ch # # WWW: http://www-hep.fzu.cz/~hrivnac/ # # S-mail: EP Division; 40-3D-11; CERN; 1211 Geneve; Switzerland # # voice: (022)-767-1238 # ########################################################################