ELOG Rome

Back Midas Rome Roody Rootana

Rome Analyzer Framework, Page 6 of 11

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

211 Entries

Goto page Previous 1, 2, 3 ... 5, 6, 7 ... 9, 10, 11 Next All

ROME examples : histoGUI

> I have succesfully written a ROME application ...

For the record, at TRIUMF we have moved away from ROME towards the ROOTANA ROOT-based analyzer 
package which has some simple C++ classes for reading midas raw data, some simple classes and examples for 
working with midas data in ROOT, and some fairly advanced graphical example applications.

https://bitbucket.org/tmidas/rootana

K.O.

ROME examples : histoGUI

Dear Farrukh

If you want to control the frequency of update of all tabs, maybe, you could use the same method (namely using 'none' DAQ') for calling event methods of tasks and tabs also for non-event based
application.
You may add a task in which you only call 'sleep' function for controlling the frequency.
For allowing you to use GUI buttons also during the sleep, you need to call the sleep function like following.
ProcessEvents function allows you to use GUI parts also during the sleep.

   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

gettimeofday is defined in sys/time.h header file in UNIX-like OS.
gSystem is in TSystem.h

For controlling the frequency, in this example, I added a new steering parameter for the task, which is defined like,

     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

Best regards,

Ryu

> Dear Farrukh
>
> The 'histoGUI' example was prepared as an example for displaying histograms.
> And the data are generated randomly in FillHisto task instead of reading from an input file.
> So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is
> implemented in include/ROMENoDAQSystem.h, and it actually does nothing.
>
> With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.
>
> When you run the example, the frequency is not so fast because the CPU is used for updating the display.
> If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through
> the task is increased because you update the display with a less frequency (thus lower CPU power is
> needed).
>
> If you are going to use ROME for non-event based application, there are two ways to call some functions
> defined in tabs.
> 1) With GUI parts, like buttons, menus, sliders and so on
> 2) With calling a function periodically.
>
> 1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for
> operate the tab.
>
> 2) is suitable if you want to update the display without any operations.
> You can see examples/argus/timer/ and examples/argus/thread as examples.
>
> Best regards,
>
> Ryu
>
> > Dear Colleagues,
> >
> > I have succesfully written a ROME application for monitoring MIDAS events and
> > understand that the appearance of a new MIDAS event record triggers the calling
> > of the event method in the Fill Histogram task.
> >
> > My two questions are however about the example in $ROMESYS/example/histoGUI -
> >
> > 1) In this example there is no MIDAS event nor event record - what then is
> > triggering the calling of the event method
> >
> > 2) Is it possible to regulate the frequency that the event method is called in
> > this example ?
> >
> > best wishes
> > Farrukh Azfar

ROME examples : histoGUI

Dear Ryu,

many thanks for your reply that's very useful.

For my knowledge and for the sake of understanding the basics.

1) Its the line : gSystem->ProcessEvents(); that calls all the event methods in the Fill classes and the Tabs classes yes ?

2) This way I am controlling the filling of the tabs at an interval regulated by "sleep" then what has happened to the program itself calling ProcessEvents ? Have I overriden that call by calling ProcessEvents or will it continue to be called - perhaps I just set the <UpdateFrequency> 0</UpdateFrequency> to disable the programs own calling and only use mine ?

I hope I've been clear. Thanks very much for your continued help.

-Farrukh

Ryu Sawada wrote:

   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

ROME examples : histoGUI

Dear Farrukh

ProcessEvents is nothing to do with ROME.
It is a ROOT function to process events called by timer, click, sockets etc.
"event" is not MIDAS event, but for example, an event where someone clicked a button.
For example, if you click an "update" button, ROOT needs to call a function connected to the button; ProcessEvents does the job.
So if you want to use the GUI during the sleep of a task, you need to call ProcessEvents sometimes.

https://root.cern.ch/root/html604/TSystem.html#TSystem:ProcessEvents

You need not to overwrite ProcessEvents.

Best regards,

Ryu

Farrukh Azfar wrote:

Ryu Sawada wrote:

   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

ROME analyzer crashes on reading midas file.

Hello,

So I'm stuck on this problem. The ROME based analyzer I use crashes everytime it attempts to open a midas file giving me this error:

Reading Midas-File /home/sheets4/run04750.mid.gz

*** Break *** segmentation violation
Generating stack trace...
0x00002b93efa9cd5c in gzread + 0xfc from /home/sheets4/root/lib/libCore.so
0x00000000004c47d9 in ROMEMidasDAQ::Event(long long) + 0x165 from ./danceanalyzer.exe
0x00000000004c452e in ROMEMidasDAQ::BeginOfRun() + 0x534 from ./danceanalyzer.exe
0x00000000004bf3da in ROMEDAQSystem::BeginOfRunDAQ() + 0x32 from ./danceanalyzer.exe
0x00000000004c1555 in ROMEEventLoop::DAQBeginOfRun(long long) + 0x15d from ./danceanalyzer.exe
0x00000000004c0721 in ROMEEventLoop::ExecuteTask(char const*) + 0x2d5 from ./danceanalyzer.exe
0x00000000004bb395 in ROMEAnalyzer::Start(int, char**) + 0x35d from ./danceanalyzer.exe
0x00000000005d121d in main + 0x2b1 from ./danceanalyzer.exe
0x000000363331c4bb in __libc_start_main + 0xdb from /lib64/tls/libc.so.6
0x00000000004b2e1a in TApplicationImp::ShowMembers(TMemberInspector&, char*) + 0x82 from ./danceanalyzer.exe
Aborted

I'd guess the problem is connected with ROOT but I'm not sure how to fix it.

I run ROOT v5.10.00
ROME v2.4
on a machine with Dual AMD opterons, 64 Bit with Red Hat Enterprise.

Any help would be appreciated.

thanks,
Steven

ROME analyzer crashes on reading midas file.

From the error message I don't see where the problem is.
Are you sure that your midas file is ok?

You can send me the xml definition file, all source files of your project and the midas file. Then I will take a look at it.

Matthias

Steven Sheets wrote:

ROME analyzer crashes on reading midas file.

I have tested midas file reading on 64 bit CPU. And there was no problem.

My environment is

-- Wring
Linux 2.6.9 SMP pentium4 32bit
ROOT v5.11/06 32 bit
MIDAS rev.3165 32 bit
midas files was written by frontend in midas/examples/experiment

-- Reading
Linux 2.6.17 SMP x86_64 AMD dual-core Athlon 64bit
ROME rev.1223 64 bit
ROOT v5.08/00b 64 bit

midas file was compressed with gzip 1.3.3

ROME / Argus crashing between runs with MIDAS

I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
 In our set up there is generally a few seconds between MIDAS runs.  ROME
handles the first run just fine, but always crashes when runs are taken in quick
succession like this.  When running in a slower mode, letting ROME finish
whatever run of end task exist, the online analyzer does not have this problem.
 I've suppressed writing all output files while in the online mode and I don't
have any end of run operations in any of the tasks.  What is happening at the
end of running that is causing ROME to crash?

Thanks for any help.

ROME / Argus crashing between runs with MIDAS

> I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
>  In our set up there is generally a few seconds between MIDAS runs.  ROME
> handles the first run just fine, but always crashes when runs are taken in quick
> succession like this.  When running in a slower mode, letting ROME finish
> whatever run of end task exist, the online analyzer does not have this problem.
>  I've suppressed writing all output files while in the online mode and I don't
> have any end of run operations in any of the tasks.  What is happening at the
> end of running that is causing ROME to crash?
> 
> Thanks for any help.

You have to provide a stack trace from your crash. RTFM the gdb command "where".

K.O.

ROME / Argus crashing between runs with MIDAS

Hello,

You can try to set <MidasOnlineCommunicationThread>to be true in your config XML file.
By doing it, the communication with the midas system will be done in a dedicated thread so it runs independently 
of analysis tasks.

Ryu

> I'm running ROME+Argus as an online analyzer and display for a MIDAS DAQ system.
>  In our set up there is generally a few seconds between MIDAS runs.  ROME
> handles the first run just fine, but always crashes when runs are taken in quick
> succession like this.  When running in a slower mode, letting ROME finish
> whatever run of end task exist, the online analyzer does not have this problem.
>  I've suppressed writing all output files while in the online mode and I don't
> have any end of run operations in any of the tasks.  What is happening at the
> end of running that is causing ROME to crash?
> 
> Thanks for any help.

Sometimes I hear that going to interactive session after end of analysis is uncomfortable. In fact it is possible to quit program immediately with -b option.
But -b is not only for that, It suppresses print. So I propose to make QuidMode in which program exit without going interactive session.
-q option is good, because ROOT has same option which means quit program just after macro is executed.

done.
Users can specify quit mode with option -q or configuration file.

Proposal reorganiztion directory structure

*) Currently, builder makes many files in the top directory.

XXXFolderDict.cpp
XXXFrameworkDict.cpp
XXXROMEDict.cpp
XXXTaskDict.cpp
XXXUserDict.cpp
XXXFolderDict.h
XXXFrameworkDict.h
XXXROMEDict.h
XXXTaskDict.h
XXXUserDict.h
xxxproject.exe
XXXProject.html
XXXUserHTML.html
libXXXProject.so
(romeConfig.xml)
Makefile
Makefile.usr

But I think it makes hard to find important files. And I'm afraid people feel ROME difficult.
Really important files are romeConfig.xml, Makefile and xxxproject.exe. So I propose followings
1) make "dict" directory and put all dictionary related files in it.
2) I have proposed to make XXXUserHTML.html before. But I started to feel this feature is not necessary any more.
3) remove libXXXProject.so from "all:" in Makefile. Users need to type "make so" to create shared library.
Makefile will look like
.
.
all: obj blank.d xxxproject.exe
.
.
so: libxxxproject.so
libxxxproject.so: $(objects)
g++ $(Flags) $(soflags) -o libxxxproject.so $(objects) $(Libraries)

*) There are still some complains that it is not easy to know which files are overwritten by builder
For instance, there is no warning messages in the header of XXXProject.html and Makefile.
And some files under "framework" directory are persistent. For instance user defined DAQ, user defined
database and folders with "editable class" flag are persistent. So I propose to separate them
at the first level instead of separating "framework" and "task". It will look like

top
|-- framework
`-- user
|-- daqs
|-- databases
|-- folders
`-- tasks

daqs, databases and folders may appear only when necessary.

All files which will be overwritten are put in framework. And others go under user.
When a task does not have "editable class" flag. the .cpp will go to user/tasks/ and
the .h file will go to framework/

This change is more like matter of favor.
And there are disadvantages.
.h will be various places, and it becomes difficult to find a .h file to know the class structure.
And the file with the same name can be in different places.
For instance, normally .h file of folder will be put in framework, but if it has "editable class" flag it will be put in user/folders/.
And if one changes "editable class" flag meanwhile, there can be two files with the same name. It may cause problem

With this change all ROME users need to move their files, so we have to think carefully.

( Anoter possibility is preparing nice document on ROME homepage instead of changing directory structure. )

P.S.
This is a very small point and is not related to directory structure.
Normally people associate online data taking with the word "DAQ". But in ROME, DAQSystem is something like input data format. ROME and database are not clearly DAQ.
When we have chanse, it may be good to rename nicer.

Problems with programming tabs when using TGraph

Dear Colleagues,
 
I have been using the ROME framework and have succesfully implemented a program 
to run on MIDAS input and plot histograms.

Not satisfied with the default settings of the Canvas, pads and text sizes etc I 
consulted Ryu who kindly showed me how to implement the event and init and update 
methods in the Tabs to bring the display closer to what I needed.

This has worked fine with histograms. However not with TGraphs:

I noticed that if I implemented the plotting of the TGraphs in the tab class then 
after setting points in the TGraph in the Fill tasks the Tab classes plot was 
empty -> is there something peculiar about TGraph ? Any tips would be great !

many thanks
Farrukh Azfar

Problems with programming tabs when using TGraph

Dear Farrukh

I presume you implemented your tab which draws the graph.
Which option do you use for Draw function of the graph ?
I am afraid you might forget to add 'A' in the option.
For example, you need to use 'A' like,

  graph->Draw("APL");

Best regards,

Ryu

> Dear Colleagues,
>
> I have been using the ROME framework and have succesfully implemented a program
> to run on MIDAS input and plot histograms.
>
> Not satisfied with the default settings of the Canvas, pads and text sizes etc I
> consulted Ryu who kindly showed me how to implement the event and init and update
> methods in the Tabs to bring the display closer to what I needed.
>
> This has worked fine with histograms. However not with TGraphs:
>
> I noticed that if I implemented the plotting of the TGraphs in the tab class then
> after setting points in the TGraph in the Fill tasks the Tab classes plot was
> empty -> is there something peculiar about TGraph ? Any tips would be great !
>
> many thanks
> Farrukh Azfar

Problems with programming tabs when using TGraph

Hi Ryu,

thanks for your reply. yes I am(was) using it.

Ryu Sawada wrote:

  graph->Draw("APL");

Problems with programming tabs when using TGraph

Dear Farrukh

If you attach your code related to the problem, I can investigate the problem.

Best regards,

Ryu

Farrukh Azfar wrote:

Hi Ryu,

thanks for your reply. yes I am(was) using it.

Ryu Sawada wrote:

  graph->Draw("APL");

Problem in adding two TGraphs in the same pad using <Argus> block in tabbing

I wanted to add two different TGraphs (Corresponding to two calorimeters) into
the same pad.
So in the xml file I did:
<Graph>
  <GraphName>MyGraph</GraphName>
  <GraphFolderName>mygraphs</GraphFolderName>
  <GraphType>TGraph</GraphType>
<GraphArraySize>2</GraphArraySize>
  <GraphXLabel>Event no.</GraphXLabel>
  <GraphYLabel>Island no.</GraphYLabel>
  <GraphXmin>0</GraphXmin>
  <GraphXmax>10000</GraphXmax>
  <GraphYmin>0</GraphYmin>
  <GraphYmax>100000</GraphYmax>
 <Argus>
<Tab>
      <TabName>SummaryFCBank</TabName>
    <ObjectArrayIndex>0-1</ObjectArrayIndex>
      <Index>1</Index>
 <DrawSamePad>true</DrawSamePad>
    </Tab>
  </Argus>
</Graph>


And in src/tasks:
in the HGUITFillHisto.cpp code I did:
 for(int icalo=1; icalo<3; icalo++)   [For each calorimeter there is one bank, and one n_islands value from that
bank per event.]                        
    {
GetMyGraphAt(icalo-1)->SetPoint(gAnalyzer->GetCurrentEventNumber(),gAnalyzer->GetCurrentEventNumber(),n_islands);

 GetMyGraphAt(0)->SetMarkerColor(2); 

 GetMyGraphAt(1)->SetMarkerColor(3);

 ArgusHistoDisplay::SetLimits(GetMyGraphAt(icalo-1));

}

But then I get an empty pad in the tab. 
It works when I create the TGraph for only one calorimeter, using GetMyGraph().

Any help would be much appreciated.

Thanks!
Sudeshna

Problem in adding two TGraphs in the same pad using <Argus> block in tabbing

I tried to reproduce the problem with using histoGUI example.
However I couldn't reproduce it; namely two graphs are shown.

I attached a modification for the example, which I applied for the test.

If you attach something similar which can reproduce the problem, it will be easier for me to find the reason.

Ryu

diff --git a/examples/histoGUI/histoGUI.xml b/examples/histoGUI/histoGUI.xml
index 3043dec..489052a 100644
--- a/examples/histoGUI/histoGUI.xml
+++ b/examples/histoGUI/histoGUI.xml
@@ -34,6 +34,7 @@
 				<GraphName>MyGraph</GraphName>
 				<GraphFolderName>mygraphs</GraphFolderName>
 				<GraphType>TGraph</GraphType>
+				<GraphArraySize>2</GraphArraySize>
 				<GraphXLabel>X</GraphXLabel>
 				<GraphYLabel>Y</GraphYLabel>
 				<GraphXmin>0</GraphXmin>
@@ -43,7 +44,9 @@
 				<Argus>
 					<Tab>
 						<TabName>GeneratedHisto</TabName>
+						<ObjectArrayIndex>0-1</ObjectArrayIndex>
 						<Index>4</Index>
+						<DrawSamePad>true</DrawSamePad>
 					</Tab>
 				</Argus>
 			</Graph>
diff --git a/examples/histoGUI/src/tasks/HGUITFillHisto.cpp b/examples/histoGUI/src/tasks/HGUITFillHisto.cpp
index 6ada840..c4dd95f 100644
--- a/examples/histoGUI/src/tasks/HGUITFillHisto.cpp
+++ b/examples/histoGUI/src/tasks/HGUITFillHisto.cpp
@@ -51,7 +51,10 @@ ClassImp(HGUITFillHisto)
 
 void HGUITFillHisto::Init()
 {
-   GetMyGraph()->SetMarkerStyle(31);
+   GetMyGraphAt(0)->SetMarkerStyle(31);
+   GetMyGraphAt(1)->SetMarkerStyle(31);
+   GetMyGraphAt(0)->SetMarkerColor(2);
+   GetMyGraphAt(1)->SetMarkerColor(4);
    GetMyGraphError()->SetMarkerStyle(8);
    GetMyGraphError()->SetMarkerColor(4);
 }
@@ -69,17 +72,23 @@ void HGUITFillHisto::Event()
    GetMyHistoAt(2)->SetLineColor(2);
    GetMyHistoAt(3)->SetLineColor(4);
    GetMyOtherHisto()->Fill(gRandom->Gaus(0,40));
-   GetMyGraph()->SetPoint(0,0,gRandom->Rndm());
-   GetMyGraph()->SetPoint(1,1,gRandom->Rndm());
-   GetMyGraph()->SetPoint(2,2,gRandom->Rndm());
-   GetMyGraph()->SetPoint(3,3,gRandom->Rndm());
-   GetMyGraph()->SetPoint(4,4,gRandom->Rndm());
+   GetMyGraphAt(0)->SetPoint(0,0,gRandom->Rndm());
+   GetMyGraphAt(0)->SetPoint(1,1,gRandom->Rndm());
+   GetMyGraphAt(0)->SetPoint(2,2,gRandom->Rndm());
+   GetMyGraphAt(0)->SetPoint(3,3,gRandom->Rndm());
+   GetMyGraphAt(0)->SetPoint(4,4,gRandom->Rndm());
+   GetMyGraphAt(1)->SetPoint(0,0,gRandom->Rndm());
+   GetMyGraphAt(1)->SetPoint(1,1,gRandom->Rndm());
+   GetMyGraphAt(1)->SetPoint(2,2,gRandom->Rndm());
+   GetMyGraphAt(1)->SetPoint(3,3,gRandom->Rndm());
+   GetMyGraphAt(1)->SetPoint(4,4,gRandom->Rndm());
    GetMyGraphError()->SetPoint(0,0,gRandom->Rndm());
    GetMyGraphError()->SetPoint(1,1,gRandom->Rndm());
    GetMyGraphError()->SetPoint(2,2,gRandom->Rndm());
    GetMyGraphError()->SetPoint(3,3,gRandom->Rndm());
    GetMyGraphError()->SetPoint(4,4,gRandom->Rndm());
-   ArgusHistoDisplay::SetLimits(GetMyGraph());
+   ArgusHistoDisplay::SetLimits(GetMyGraphAt(0));
+   ArgusHistoDisplay::SetLimits(GetMyGraphAt(1));
    ArgusHistoDisplay::SetLimits(GetMyGraphError());
 }

> I wanted to add two different TGraphs (Corresponding to two calorimeters) into
> the same pad.
> So in the xml file I did:
> <Graph>
> <GraphName>MyGraph</GraphName>
> <GraphFolderName>mygraphs</GraphFolderName>
> <GraphType>TGraph</GraphType>
> <GraphArraySize>2</GraphArraySize>
> <GraphXLabel>Event no.</GraphXLabel>
> <GraphYLabel>Island no.</GraphYLabel>
> <GraphXmin>0</GraphXmin>
> <GraphXmax>10000</GraphXmax>
> <GraphYmin>0</GraphYmin>
> <GraphYmax>100000</GraphYmax>
> <Argus>
> <Tab>
> <TabName>SummaryFCBank</TabName>
> <ObjectArrayIndex>0-1</ObjectArrayIndex>
> <Index>1</Index>
> <DrawSamePad>true</DrawSamePad>
> </Tab>
> </Argus>
> </Graph>
>
>
> And in src/tasks:
> in the HGUITFillHisto.cpp code I did:
> for(int icalo=1; icalo<3; icalo++) [For each calorimeter there is one bank, and one n_islands value from that
> bank per event.]
> {
> GetMyGraphAt(icalo-1)->SetPoint(gAnalyzer->GetCurrentEventNumber(),gAnalyzer->GetCurrentEventNumber(),n_islands);
>
> GetMyGraphAt(0)->SetMarkerColor(2);
>
> GetMyGraphAt(1)->SetMarkerColor(3);
>
> ArgusHistoDisplay::SetLimits(GetMyGraphAt(icalo-1));
>
> }
>
> But then I get an empty pad in the tab.
> It works when I create the TGraph for only one calorimeter, using GetMyGraph().
>
> Any help would be much appreciated.
>
> Thanks!
> Sudeshna

Attachment 1: screen.jpg

Option to analyse every Nth event

Dear Colleagues

I was wondering if there was an option to analyse only ever N events in ROME. If 
this is doable via an xml switch I am guessing this would be the best and most 
convenient solution.

Else any advice on how to do this in code would be great as well -

many thanks
Farrukh

Goto page Previous 1, 2, 3 ... 5, 6, 7 ... 9, 10, 11 Next All

ELOG V3.1.4-2e1708b5