Re: TDSet::Process(TSelector * selector) missing

From: Maarten Ballintijn <maartenb_at_mit.edu>
Date: Mon, 15 Jan 2007 08:45:24 -0500


Hi Antonio,

Great, it sounds like you are almost there.

The solution for your problem is to simply use the input list and the output list to pass these kind of objects.

We introduced the concept of these lists because it provides a clean, easily understandable model for data passing from client, to master, and on to the slaves. And in the opposite direction for the output list. Without unduly restricting the the data members of a TSelector.

An easy model to keep in mind is that there are three phases in the execution of a TSelector based query and that the communication between is only possible using the lists:

Begin() - Runs on the client, after Begin() returns the InputList is transfered to the slaves in the case of PROOF.

SlaveBegin(),Init(),Notify()Process()....SlaveTerminate() - All run on the slaves in the case of PROOF. After SlaveTerminate() returns the OutputLists of the slave are merged by the master and send back to the client.

Terminate() - runs always on the client, has the results in the output list. Keep in mind that this need *not* be the same session / TSelector object as where Begin() ran. [because of the new disconnect/re-connect functionality]. So, do all the necessary initialisation, e.g. creating a canvas, in Terminate() itself

Hope this helps!

Cheers,

Maarten.

Antonio Bulgheroni wrote:

> Hi Leandro,
>        you perfectly got my point and I've understood your explanation.
> I hope it's not going to be a difficult modification and in the mean
> time, I'll try exporting as global the configuration object.
> 
> Cheers,
> 
> Antonio
> 
> -- 
> Antonio Bulgheroni, PhD
> 
> If several things that could have gone wrong have not
> gone wrong, it would have been ultimately beneficial
> for them to have gone wrong.
> 
> On 1/15/07, *Leandro Franco* <lfranco_at_cern.ch <mailto:lfranco_at_cern.ch>>
> wrote:
> 
>     Hi,
> 
>     I think Antonio wants to pass a specific (instantiated) object of
>     his class. 
>     While this doesn't present big problems in a normal ROOT session, I
>     suppose it's trickier in PROOF. 
>     As Maarten said the slaves need to be aware of the new class and
>     after that we would have to be able to pass 
>     the object instead of the file.
> 
>     I know this is a bit disappointing since you (Antonio) are probably
>     using PROOF in just one machine, but if 
>     you think in a normal session where the client, the master and the
>     slaves are in different machines it makes sense.
> 
>     I don't know how difficult the modification is but I will take a look.
> 
>     For the moment the only way out is to configure the selector inside
>     itself, it could for example open the conf file you mention in
>     the constructor (hard coding it or with the global you suggest).
> 
>     Good Luck,
>     Leo
> 
> 
> 
>     On Jan 15, 2007, at 11:17 AM, Antonio Bulgheroni wrote:
> 

>> Thanks Maarten and Constantin for your answers.
>>
>> For Maarten,
>> This is actually what I'm doing. TAnalysisSelector is the
>> name of my TSelector class (not a macro). Of course I've uploaded
>> a PAR file with a library containing TAnalysisSelector definition
>> on each slave of the proof cluster.
>>
>> The point is the following: the tree analysis is steered by many
>> parameters that are stored in a TConfiguration object (another
>> user-defined object inheriting from a TObject) and one of the data
>> members of the TAnalsysSelector is a pointer to such
>> TConfiguration object. In the normal way of operation w/o PROOF, I
>> do the following:
>>
>> TConfiguration * conf = new TConfiguration();
>> conf->LoadFromConfFile(confFileName);
>> TAnalysisSelector * selector = new TAnalysisSelector();
>> selector->SetConfiguration(conf);
>> tree->Process(selector); // note I'm passing a reference to
>> TAnalysisSelector
>> ...
>>
>> This can be done because TTree has a method Process(TSelector *).
>> But when running on PROOF, this is not available and PROOF wants
>> to create an instance of TAnalysisSelector and processes it
>> immediately without giving the user the chance to call any other
>> method of the newly created TAnalysisSelector.
>>
>> The only (maybe not elegant) way out is to make declare a global
>> TConfiguration * gConf and use it inside the TAnalysisSelector. Do
>> you think is it going to work?
>>
>> For Constantin,
>> I've read on the PROOF Twiki
>> (http://root.cern.ch/twiki/bin/view/ROOT/PROOF
>> <http://root.cern.ch/twiki/bin/view/ROOT/PROOF>) that developing
>> your own TSelector derived class (using MakeSelector) is the first
>> step. That's why I did it!
>>
>> Thanks again for your help,
>>
>> Antonio
>>
>> --
>> Antonio Bulgheroni, PhD
>> INFN - Sez. Rome III
>>
>>
>>
>> On 1/12/07, *Maarten Ballintijn * < maartenb_at_mit.edu
>> <mailto:maartenb_at_mit.edu>> wrote:
>>
>> Hello Antonio,
>>
>> You can pass the name of your class, rather then a the name of a
>> macro, e.g.
>>
>> dset->Process("TAnalsysSelector")
>>
>> This requires that the class is know in the client and on the
>> slaves. This is normally achieved using a PAR file which provides
>> a library with your class(es) and their dictionary.
>>
>> Cheers,
>>
>> Maarten.
>>
>> Antonio Bulgheroni wrote:
>> > Dear ROOTers,
>> > apologies for bothering you with another question about
>> PROOF, but
>> > the more I (try to) use it, the more I like.
>> >
>> > So far, I have prepare a brand new custom selector inheriting
>> from
>> > TSelector and I've filled in all the automatically generated
>> methods and
>> > I've added my personal methods and data members. To work
>> properly, this
>> > TAnalsysSelector needs to be set up before executed. I mean,
>> I have to
>> > set few variables before calling tree->Process(mySelector).
>> While this
>> > is possible when working w/o PROOF, I can't find a way when
>> working w/
>> > PROOF because TDSet::Process(TSelector*) is missing and the only
>> > available method is TDSet::Process(const char*). In my case
>> this is
>> > going to fail, because I have no more chance to set up the
>> > TAnalysisSelector.
>> >
>> > What's wrong? Is there another way out? Is it possible to have
>> > TDSet::Process(TSelector*)?
>> >
>> > Thanks a lot,
>> >
>> > Antonio
Received on Mon Jan 15 2007 - 14:45:53 CET

This archive was generated by hypermail 2.2.0 : Mon Jan 15 2007 - 17:50:00 CET