<div dir="ltr">Hi Richard<div><br></div><div>Taking Zhiwen's diagram at face value, I note that EVERY grey arrow attaches ONLY to the detector definition. To my mind the detector definition is an entity that moves smoothly from memory of a running program back/forth to files as well as back/forth to a database. Since memory means root (we didn't yet demand this, but I think it is implicit), the detector definition entity is a C++ class (or collection thereof), let's call it DD for short.</div><div><br></div><div>=======================</div><div><br></div><div>How the DD is initialized before moving seamlessly between volatile and non-volatile representations is a separate question and I think this is the one you're raising. What could work:</div><div><br></div><div>WHAT WOULD TOM DO:</div><div>What I would do is that *IN ADDITION* to the object having root streamers, it should be made into a dictionary (2 more lines of code...we're not up to 4). In this case, my personal default preference for intiializing the object would be via a root macro. This macro would:</div><div>a- Instantiate a DD.</div><div>b- Use its methods to set a series of values.</div><div>c- Stream it out where I want to keep a record of it (database, file, or even just start using it in memory!).</div><div><br></div><div>This is just me and a singular personal preference. I think it is the one that you indicate as having least amount of work on our part to realize.</div><div><br></div><div>WHAT WE HAVE HEARD APPEALS FOR:</div><div>Perl seems to be appealing to people. If there is a way to initiate a DD from perl, why not. It does not seem a natural fit to me (apparently you agree), but I am not infinitely clever. Even if the DD were initiated by perl, it would still be streamed to database and files for subsequent use and sharing.</div><div><br></div><div>I will admit bias with regard to perl. I code *LOTS and LOTS* of little perl macros to do *LOTS and LOTS* of individual string manipulations. I like perl for file list handling, generation of batch job submission files, and I even make student scores available to them via perl scripts in the cgi-bin area of a web server. Perl is ABSOLUTELY GREAT for handling individual little jobs. I see why some find it appealing.</div><div><br></div><div>I would point out however, that perl is not built with collaborative concepts intrinsic to the language (like one has in C++ e.g. inherited interface definitions to standardize analysis modules). As a result, doing anything more than singular simple stand-alone tasks in perl seems to be a big risk for a large experiment like SoLID. That said, I would neither push nor deny any language at this time.</div><div><br></div><div>=======================</div><div><br></div><div>I think that the current issue is not so much what language one uses for various steps. It is agreement on the following concepts:</div><div><br></div><div>A: We should formulate a specific design for a DD.</div><div>B: The DD should move smoothly back/forth from memory to file and memory to database (I've suggested root streamers as making the least work on us).</div><div>C: The DD should be written in a manner to maximally appeal to offline users to simplify analysis code.</div><div>D: All elements (sim, digi, reco, anal) in the analysis chain speak ONLY to the DD as our means of assuring consistency between simulated and real data.</div><div><br></div><div>As we design the DD (there is still a lot to do in making this damned simple, aesthetically appealing, and FUNCTIONAL) issues of how it is instantiated by any method other than reading an already existing version from file/database will become clear at the time. </div><div><br></div><div>All the best,</div><div>Tom</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 10:56 PM, Richard S. Holmes <span dir="ltr"><<a href="mailto:rsholmes@syr.edu" target="_blank">rsholmes@syr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Tom's ideas are good, but I think there's one point that needs clarification (for someone... possibly me, possibly not):</div><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 4:51 PM, Thomas K Hemmick <span dir="ltr"><<a href="mailto:hemmick@skipper.physics.sunysb.edu" target="_blank">hemmick@skipper.physics.sunysb.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I) Root streamers mean that with ZERO WORK, we can store/retrieve the detector definition objects to/from a file.</div>
<div></div></blockquote></div><br></span>It seems to me, unless I'm mistaken, there's a few words missing from the end of this sentence, which are: "in a C++ program linked against ROOT". It's NOT a zero work problem to store/retrieve detector definition objects to/from a file in a Perl script. This is what I alluded to earlier: If you generate information in a Perl script (or Python, or ...), you then have to do the work of getting that information out of the script and into the simulation and digitization and reconstruction and analysis codes, whether via local file or pipeline or a database. You can't do it with ROOT streamers. And changes in the detector definitions would have to be handled in (at least) two places: the script, and the class definition, which you would have to take care to keep synchronized. Whereas if the definition is implemented within a C++ class, and never needs to be understood by a script, it can just be written and read with, as you say, zero work. If that class is in a library then the simulation, digitization, reconstruction, and analysis codes can link against it and if properly implemented, changes to a definition would automatically and synchronously be propagated to all parts of the software.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Or am I misunderstanding something?<span class=""><br clear="all"><div><br></div>-- <br><div>- Richard S. Holmes<br> Physics Department<br> Syracuse University<br> Syracuse, NY 13244<br> <a href="tel:315-443-5977" value="+13154435977" target="_blank">315-443-5977</a><br></div>
</span></div></div>
</blockquote></div><br></div>