27 Jan 2005, Stefan Ritt, Suggestion, messaging system
|
> I implemented the cm_msg calls.
You should implement a central "message dispatcher". So all errors etc. should go to someting linke
rome_msg(). If compiled with midas online support, rome_msg() should call cm_msg(). If rome is compiled
without midas libraries, a printf() there would be enough. If someone uses rome in a different
environment, only can function needs to be changed to reroute all messages to somewhere else. |
28 Jan 2005, Matthias Schneebeli, Suggestion, messaging system
|
> > I implemented the cm_msg calls.
>
> You should implement a central "message dispatcher". So all errors etc. should go to someting linke
> rome_msg(). If compiled with midas online support, rome_msg() should call cm_msg(). If rome is compiled
> without midas libraries, a printf() there would be enough. If someone uses rome in a different
> environment, only can function needs to be changed to reroute all messages to somewhere else.
Of course, that's the way I implemented that. |
06 Mar 2005, Ryu Sawada, Suggestion, Cint mode on online
|
We sometimes want to use trees in ROME.
One way is to read it by TSocket connection. But treees are larger than histograms in general, and it
takes time to download.
And I need to make shared library when I changed the structure of folders.
So, I want to propose is to prepare Cint mode with continueing analysis in background.
Currently, when user press "i", ROME stops analysis and goes into cint mode. This is good for offline
mode, but this is not good for online mode. So I propose that when user press "I", ROME goes cint
mode, and continue analysis in background.
Then we can see Trees at run time.
In addition, If you are going to implement this feature, please prepare short way to call trees in cint mode.
If I understand correctly, the way to call a tree is like,
gAnalyzer->GetTreeObjectAt(0)->GetTree()->Draw("");
but it is too long to use in interactively and we need to remeber the number of trees.
gAnalyzer->GetTree("trigger")->Draw(); is better. |
29 Mar 2005, Ryu Sawada, Suggestion, Input file format
|
I am going to make a new ROME project to analyze MC data. Input file will be ROOT which is created by
h2root.
And my friend who is working on dark matter search at Columbia university in NY is going to use
ROME. His file format is special binary format.
If I understand correctly, currently ROME can read midas and ROOT format.
Midas file names are always assumed as "run99999.mid". (99999 is run number)
ROOT files need to have structure defined in definition xml file.
I guess this is not enough to analyze special binary format or ROOT files created by h2root.
What I propose is to allow users to have own daq class. It might be something like
<DAQs>
<DAQ>
<DAQName>daqname</DAQName>
</DAQ>
</DAQs>
Then builder creates [shortcut][daqname].h, [shortcut][daqname].cpp.
[shortcut][daqname] class inherits ROMEDAQSystem class, and users must fill GetTimeStamp(),
Initialize(), Connect(), ReadEvent(int event), Disconnect(), Termination()
When "InputDataFormat" in configuration xml file is "daqname" analyzer uses this class.
|
03 Apr 2005, Ryu Sawada, Suggestion, user defined command line options
|
This is not strong request, just a proposal because the same thing can be done by configuration file.
It may be useful if users can have his command line options.
For instance.
<CommandOptions>
<CommandOption>
<OptionFlag>m<OptionFlag>
<OptionName>isMC<OptionName>
<OptionType>Bool_t<OptionType>
<OptionInitialization>false<OptionInitialization>
</CommandOption>
<CommandOption>
<OptionFlag>t<OptionFlag>
<OptionName>TriggerType<OptionName>
<OptionType>Int_t<OptionType>
<OptionInitialization>0<OptionInitialization>
</COmmandOption>
</CommandOptions>
Then user can change the variable with command line option like
./megframework -m -t 2;
Then builder creates new method.
(Bool_t) MEGAnalyzer::GetisMC()
(Int_t) MEGAnalyzer::GetTriggerType() |
14 Apr 2005, Ryu Sawada, Suggestion, GetDataBase, GetActiveDAQ
|
There is no check if the pointer returned by GetDataBase,GetActiveDAQ is valid. This can result
segmentation fault.
For instance, if one specifies DAQ system as "none", or one does not specify DataBaseName, rome
stops without error message.
It is better to modify this behavior.
* One way is to stop application like.
ROMEDAQSystem* GetActiveDAQ() {
if(!fActiveDAQ){
gAnalyzer->Println("some error message");
fApplication->Terminate(1);
}
return fActiveDAQ;
};
*Other way is to use a dummy DAQSystem and DataBase which does nothing when user does not
specify DAQ or DataBase. When dummy is used, warning message must be shown, because it is
dangerous that users do not realize they are using dummy. |
15 Apr 2005, Matthias Schneebeli, Suggestion, GetDataBase, GetActiveDAQ
|
> There is no check if the pointer returned by GetDataBase,GetActiveDAQ is valid. This can result
> segmentation fault.
> For instance, if one specifies DAQ system as "none", or one does not specify DataBaseName, rome
> stops without error message.
>
> It is better to modify this behavior.
>
>
> * One way is to stop application like.
> ROMEDAQSystem* GetActiveDAQ() {
> if(!fActiveDAQ){
> gAnalyzer->Println("some error message");
> fApplication->Terminate(1);
> }
> return fActiveDAQ;
> };
>
> *Other way is to use a dummy DAQSystem and DataBase which does nothing when user does not
> specify DAQ or DataBase. When dummy is used, warning message must be shown, because it is
> dangerous that users do not realize they are using dummy.
done |
15 Apr 2005, Ryu Sawada, Suggestion, About parameters in definition and configuration file
|
At first there must be several opinions and discussions. Following is just my opinion.
Probably asking opinion some users before changing ROME is better.
There are some properties for histograms and databases.
* database name
* database type and connection
* field database name and path
* histogram properties
I assume that definition file is shared by several persons in experimental group and configuration files
are created for each users at the first execution. If you assume that we should share also configuration
file, story written below is different.
My basic concept is that
*Parameters which is complicated or will be shared among several users should be in definition file.
*Parameters which can be often changed at run time should be in configuration file.
The good point to specify values in definition file is that they are flexible, because we can use
ROMEString::SetFormatted.
It is outstanding point of ROME that we can design framework very flexibly due to builder.
Other point is that parameters in definition file will be written by programer while those in
configuration file can be written by non-experts. It is better that the application can work with few
changes of configuration file as possible. In my feeling, to specify database paths and histogram
parameters in configuration file correctly is too tough for normal users.
In my opinion, they are separated like,
Definition file:
* field database name and path
* histogram properties
Configuration file:
* database type and connection
* (histogram properties)
-- about database path
Normally, users share the same database structure. So I think it should be in definition file. I don't think
paths are changed so often.
-- about database type and connection
At first type and connection can be written in one line like,
xml://directory_of_database/database_name
mysql://[user_name]:[passwd]@[hostname]:[port]/database_name
none://
( odb://[host_name]/[experiment] or odb://experiment@host_name )
(parameters in [] are optional)
These parameters will be changed user by user, because they can have xml files in different place, and
they can use replicated SQL servers.
Password can be written in connection. So it should be in configuration file.
-- about histogram parameters
We can specify them with calculation if they are in definition file. I think it should be in definition file.
And to allow to overwrite in configuration file is also attractive. In my opinion overwriting with normal
type like Float_t,Int_t... is enough.
---------
In result, my opinion is like following.
Database name, database paths and histogram parameters are in definition file.
In default configuration file, config class writes database entries appeared in definition file.
Config class writes histogram parameters entries with empty values if the histogram is <Configurable>.
Only when
some value is written there, analyzer overwrite these parameters.
As I wrote above I think normal number like following are enough as values of histogram parameters in
configuration file.
<HistXmax>1000</HistXmax>
I don't think following is necessary.
</HistXmax>/GSP/parameter</HistXmax>
Definition file
<Folder>
<FolderName>foldername</FolderName>
<DataBaseAccess>true</DataBaseAccess>
<Field>
<FieldName>fieldname</FieldName>
<FieldType>Float_t</FieldType>
<DataBaseName>first_database</DataBaseName>
<DataBasePath>"/Path/to/record"</DataBasePath>
</Field>
<Field>
<FieldName>fieldname2</FieldName>
<FieldType>Float_t</FieldType>
<DataBaseName>second_database</DataBaseName>
<DataBasePath>"/Path/to/record2"</DataBasePath>
</Field>
</Folder>
...
<Histogram>
<HistName>histname</HistName>
<Configurable>true</Configurable>
<HistType>TH1F</HistType>
<HistTitle>ADC0 Bank</HistTitle>
<HistFolderTitle>ADC</HistFolderTitle>
<HistArraySize>gAnalyzer->GetGSP()->GetNumberOfADC()</HistArraySize>
<HistXNbins>4094</HistXNbins>
<HistXmin>1</HistXmin>
<HistXmax>4095</HistXmax>
</Histogram>
Default configuration file
<DataBases>
<DataBase>
<Name>first_database</Name>
<Connection>none://</Connection>
</DataBase>
<DataBase>
<Name>second_database</Name>
<Connection>none://</Connection>
</DataBase>
</DataBases>
...
<Histogram>
<HistName>histname</HistName>
<HistFolderTitle></HistFolderTitle>
<HistArraySize></HistArraySize>
<HistXNbins></HistXNbins>
<HistXmin></HistXmin>
<HistXmax></HistXmax>
</Histogram> |
15 Apr 2005, Ryu Sawada, Suggestion, <Online> in configuration file
|
<Online> in configuration file is MIDAS specific thing. Non MIDAS users don't need it.
And it can be used when MIDAS is linked.
So it is better that <Online> appears only when MIDAS is linked. |
18 Apr 2005, Pierre-Andre Amaudruz, Suggestion, ROOTCINT path
|
As ROOTSYS is required for the ROME build, I would suggest to
include the code below in the builder for the application Makefile.
This will make Rome less dependent on the ROOT path.
Replace in ROMEBuilder.cpp:
buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());
by
buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
-f %sDict.cpp -c -p ",shortCut.Data()); |
18 Apr 2005, Matthias Schneebeli, Suggestion, ROOTCINT path
|
> As ROOTSYS is required for the ROME build, I would suggest to
> include the code below in the builder for the application Makefile.
> This will make Rome less dependent on the ROOT path.
>
> Replace in ROMEBuilder.cpp:
>
> buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());
>
> by
>
> buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
> -f %sDict.cpp -c -p ",shortCut.Data());
That's in the cvs now, thanks. |
22 Apr 2005, Ryu Sawada, Suggestion, user defined command line options
|
> Then user can change the variable with command line option like
> ./megframework -m -t 2;
>
> Then builder creates new method.
> (Bool_t) MEGAnalyzer::GetisMC()
> (Int_t) MEGAnalyzer::GetTriggerType()
I realized better way. In this way users can add or remove command line options without changing their
task files. And it is not necessary to add new object in ROME.
What I propose is to make it in steering parameter. That is <SPCOmmandOption> in steering parameter's
properties.
<SteeringParameterField>
<SPFieldName>isMC</SPFieldName>
<SPFieldType>Bool_t</SPFieldType>
<SPCommandOption>m</SPCommandOption>
</SteeringParameterField>
<SteeringParameterField>
<SPFieldName>TriggerType</SPFieldName>
<SPFieldType>Int_t</SPFieldType>
<SPCommandOption>t</SPCommandOption>
</SteeringParameterField>
Then user can change the variable with command line option like
./megframework -m -t 2;
when -m is typed, isMC becomes true.
Trigger type will be 2.
They can specify the value both with config file and command line option just same as run numbers.
Values in config file will be overwritten by command line option.
|
22 Apr 2005, Ryu Sawada, Suggestion, user defined command line options
|
>
> > Then user can change the variable with command line option like
> > ./megframework -m -t 2;
> >
> > Then builder creates new method.
> > (Bool_t) MEGAnalyzer::GetisMC()
> > (Int_t) MEGAnalyzer::GetTriggerType()
>
> I realized better way. In this way users can add or remove command line options without changing their
> task files. And it is not necessary to add new object in ROME.
>
> What I propose is to make it in steering parameter. That is <SPCOmmandOption> in steering parameter's
> properties.
>
> <SteeringParameterField>
> <SPFieldName>isMC</SPFieldName>
> <SPFieldType>Bool_t</SPFieldType>
> <SPCommandOption>m</SPCommandOption>
> </SteeringParameterField>
> <SteeringParameterField>
> <SPFieldName>TriggerType</SPFieldName>
> <SPFieldType>Int_t</SPFieldType>
> <SPCommandOption>t</SPCommandOption>
> </SteeringParameterField>
>
> Then user can change the variable with command line option like
> ./megframework -m -t 2;
> when -m is typed, isMC becomes true.
> Trigger type will be 2.
>
> They can specify the value both with config file and command line option just same as run numbers.
> Values in config file will be overwritten by command line option.
>
>
done. |
03 May 2005, Ryu Sawada, Suggestion, ROOTCINT path
|
> > As ROOTSYS is required for the ROME build, I would suggest to
> > include the code below in the builder for the application Makefile.
> > This will make Rome less dependent on the ROOT path.
> >
> > Replace in ROMEBuilder.cpp:
> >
> > buffer.AppendFormatted("rootcint -f %sDict.cpp -c -p ",shortCut.Data());
> >
> > by
> >
> > buffer.AppendFormatted("LD_LIBRARY_PATH=$(ROOTSYS)/lib $(ROOTSYS)/bin/rootcint
> > -f %sDict.cpp -c -p ",shortCut.Data());
>
> That's in the cvs now, thanks.
LD_LIBRARY_PATH is not dedecated for ROOT. One can already have it, and overwriting it may cause error.
For instance, if he installed libstdc++ in non-standard place, he will set LD_LIBRARY_PATH there.
In case of GNU Makefile, we can use "if" statemente like,
ifdef LD_LIBRARY_PATH
LD_LIBRARY_PATH += $(ROOTSYS)/lib
else
LD_LIBRARY_PATH := $(ROOTSYS)/lib
endif |
11 Jun 2005, Ryu Sawada, Suggestion, class members in TTree
|
I think that fUniqueID and fBits in TObject is not useful to store in TTree.
I found in ROOT users guide that we can disable that with
MyClass::Class()->IgnoreTObjectStreamer();
.
If you also think these are useless information, please implement it in ROME.
second topic.
This is just a matter of favor.
We sometimes use TTree interactively. At that time, I feel fRunNumber, fEventNumber, fTimeStamp,
fSequentialNumber are long to type.
I prefer shorter without upper case letter.
If many people agree it, I would like to ask to change them run,event,timestamp,number like MIDAS analyzer. |
28 Jun 2005, Ryu Sawada, Suggestion, Folder reset.
|
In Reset method of folders. Support folder members are ignored currently.
Reset method of support folder member had better to be called.
In addition, isModified() should check if the member support folders were modified.
For example
class A : public TObject
{
protected:
TypeB* B;
TClonesArray* C;
.
.
public:
A() {
B = 0;
C = 0;
};
.
.
.
void Reset() {
int i;
fModified = false;
if(B) B->Reset();
if(C) for(i=0;i<C->GetEntries();i++) { ((TypeC*)C->At(i))->Reset(); }
};
ClassDef(A,1)
}; |
28 Jun 2005, Matthias Schneebeli, Suggestion, class members in TTree
|
> I think that fUniqueID and fBits in TObject is not useful to store in TTree.
> I found in ROOT users guide that we can disable that with
> MyClass::Class()->IgnoreTObjectStreamer();
> .
>
> If you also think these are useless information, please implement it in ROME.
>
>
>
> second topic.
> This is just a matter of favor.
> We sometimes use TTree interactively. At that time, I feel fRunNumber, fEventNumber, fTimeStamp,
> fSequentialNumber are long to type.
> I prefer shorter without upper case letter.
> If many people agree it, I would like to ask to change them run,event,timestamp,number like MIDAS analyzer.
MyClass::Class()->IgnoreTObjectStreamer(); is implemented. |
28 Jun 2005, Ryu Sawada, Suggestion, class members in TTree
|
> This is just a matter of favor.
> We sometimes use TTree interactively. At that time, I feel fRunNumber, fEventNumber, fTimeStamp,
> fSequentialNumber are long to type.
> I prefer shorter without upper case letter.
> If many people agree it, I would like to ask to change them run,event,timestamp,number like MIDAS analyzer.
changed to run, event, time and number. |
10 Jul 2005, Ryu Sawada, Suggestion, ResetFolders
|
ResetFolders are called in DAQEvent for every events.
I have some folders who's information have to be kept during the run.
One possibility is to add new tag like <ResetBoforeEvents> in folder definition.
The other is give up reset in ROMEEventLoop and give users resposibility of reset. |
21 Jul 2005, Ryu Sawada, Suggestion, ResetFolders
|
> ResetFolders are called in DAQEvent for every events.
>
> I have some folders who's information have to be kept during the run.
>
> One possibility is to add new tag like <ResetBoforeEvents> in folder definition.
> The other is give up reset in ROMEEventLoop and give users resposibility of reset.
done.
The name of the tag is <NoResetByFramework> |
|