Questions about TEve

[Manqi]

Dear Root Developers:
First I would like to thank you for providing us the TEve tools for the 3D-display. It’s really nice and has huge potential of application. Currently I’m working on a 3D event display program for the International Large Detector (for ILC), and the idea is to show the detector geometry, detector hits (calorimeters + trackers) and estimated MC/Reconstructed particles (with reading information from the data file). The attached plot shows what we have currently. Here I have some questions:

   1) The range of the box size: I used the TEveBoxSet::kBT_FreeBox to describe the calorimeter hits, and I want to keep the size of the box exactly the same as the size of calorimeter cell. However, when I lowed the cell size below 2*2 cm, in the display it just doesn't show the Box. It doesn't helps if I scale the whole detector by 10 times (just as to switch the length unit from cm to mm, with lower the magnitude field by 10 times). I can found the corresponding information in the objects list, but it doesn't draw in the 3D display. 

     2) Do we have a way to keep the object information but not show directly?
     For the full detector events, we have lots of low energy tracks. If we show them by event, it will make your display like a mess and make the display rather slow. But some time we do need those information to understand the shower details. So is there a method, for us to keep the object information but not displayed by default? Idealy, it could be turned on interactively by the user.

     3) How to attach the text information to TEveArrow & TEveBox?
     For the TEveTrack & TEvePointSet, we could attach a text msg on the objects, which could be easily picked up by putting your mouse on it. However, this could not be used on the TEveArrow & TEveBox classes, while sometime we need this. For example, for a Box represent the calorimeter hit, people want to pick it up by mouse and directly know the hit position & energy. So maybe we could also adding those functions to the Arrow & Box classes?

    4) The error msg during the display: I get lots of the invalid value error msgs during the display, especially when I try to zoom & rotate the detector.

Error in <TGLViewerBase::RenderNonSelected - pre exit check>: GL Error invalid value

    However, I didn't really found that something is wrong in the display. So what caused this error msg, does it really harms & how could we get rid off it?

     5) A small bug reporting: For the particle with some rarely PID, its tracks could not get correctly displayed. For example, PID = 1000010020, deutrino. I think those need also to be adding into the particle list. 

     6) TEvePathMarker: we used several Path Marker to make sure the track go through some important point. However, we found through it allows us to set a set of pathmarkers, actually only the first pathmarker works, while others give no real constraint on the track display. I guess that's some internal bugs there...

Many Thanks for your help & waiting for your answer

[matevz]

Hello,

First, thank you for your encouraging words. Also, it is very nice to
see an ILC detector and event in EVE

What version of ROOT are you using? Is it possible for you to use
trunk? This way we can fix any problems immediately and you’re ready
to go with the next release.

Replying to your points now.

========================================

1. This is strange – it should work
   How many boxes do you put in each TEveBoxSet?
   Is bounding box calculated correctly? [shift-left-click on the box-set in the gl-viewer]
   Do your boxes have “the third” dimension? There was a problem in ROOT
   GL that I fixed about a month ago – volume of bounding box was taken
   to determine if the object is worth drawing and this lead to
   disappearance of 2D and 1D objects. Now we use bounding-box diagonal.

2. There are two flags in TEveElement class – the base class of all
   Eve elements:

   Bool_t fRnrSelf; // Render this element.
   Bool_t fRnrChildren; // Render children of this element.

By setting this to false, you can prevent display of the element (or
its children). You probably noticed that every eve-element can hold
children. So, you can add child particles to the “main” particle:
electron->AddElement(delta_electron);
and so on.

3. Not all eve classes are “pickable” in the gl viewer by default
   (pointset and tracks are). You have to call:

   arrow->SetPickable(kTRUE);

and then the element’s title will appear as tooltip.

For TEveBoxSet the thing is not so trivial as it holds a lot of
separate boxes. If you make one box-set per tower, the above trick
will work.

Otherwise you have to use secondary selection – that is achieved
by Alt-left-click on the box (Ctrl-Alt if Alt is used to move
windows on your desktop).

You can assign a TObject* as an external reference to each box. This
is in fact implemented already in the base-class –
TEveDigitSet. Then, when you secondary-select the box the Print()
method of the assigned TObject will be called. See
tutorials/eve/quadset.C for an example.

You can also connect to a signal from TEveDigitSet:

virtual void SecSelected(TEveDigitSet* qs, Int_t idx); // SIGNAL

If you make a sub-class of TEveBoxSet you can override this method.

4. This usually signals an old OpenGL version – in general we use
   OpenGL-1.4 without checks and later functionality only if higher
   version of GL is available.

What OS are you using? Which GL version? (type glxinfo)

Can you tace down which class produces it by disabling objects one by one?

5. Yes, this should go into TDatabasePDG but you can also add them
   yourself during initialization. An example from ALICE code:

TDatabasePDG pdgDB = TDatabasePDG::Instance();
Int_t ionCode = kion+10020;
if(!pdgDB->GetParticle(ionCode)){
pdgDB->AddParticle(“Deuteron”,“Deuteron”,2kAu2Gev+8.071e-3,kTRUE,
0,1,“Ion”,ionCode);
}

6. Hmmh, I’m pretty sure this works (for example see
   tutorials/eve/track.C). If you click on propagator in object list and
   then on Refs in the object editor you can enable/disable fitting of
   various path-mark types. I think most are on by default.

========================================

If you have trouble with anything else don’t hesitate to ask.

Best regards,
Matevz

[Manqi]

Hi Matevz:

Really nice to get you reply! Thank you for your quick echo.

Currently I'm using Root_v5.22.00 and Root_v5.24.00. There is no significant difference for those two versions noticed during my display. I'd be very happy to use the trunk and get involved in the root developement :slight_smile: Just telling me how to get the corresponding tarballs.

I'm really happy about the RnrSelf & SetPickable Stuff! That's exactly what I need!!

    Now about the questions:


1) About the Boxset:
    I use only 1 box in each Boxset, for, I want to attach the hit information to the boxset name. With your suggestion I send them pickable and now works quite nicely. ( Only 1 question, is it used too much resources if I keep an Boxset/Pointset for each calorimeter/tracker hit? )
    About the size it's quite strange. My box is set with length = weight = 10* height, with an global scale factor acting on each dimension. So when I have the length = weighth >= 3 cm, it's properly showned; when I reduce the length to 2 cm, I need to swithch off the detector geometry & rotate a bit to get it displayed. With the cell size ~ 1cm (which is the real cell size according to current design), I cannot get it shown. The shift-left-click on the hits seems fine, see attached plot. I think the bug you mentioned about the GL calculation about if the object worth drawing is quite possible...
    BTW, is there a way to set the transparency & lightness of the boxes?


2) About the Tracks:
    Yes I tried the nice example on tutorials, and that's why I got myself totally puzzled (they works so nicely there!)...

    The track is not a trivial stuff, for we can only estimate its path through the following information (reading from the MC Particle List in the data file), the Vtx point (creating point), the end point (dead point) and initial momentum, and based on your simulation, a set of detector hits created by this particle.

    There is another question I want to ask, which maybe also concering this problem, is do we have a method to make sure that the track ends at an given point? So far to me, the 'MaxOrbs' is the only parameter I know concering the length of the helix. And I used a rather rude way to define the length for each charged track:
    Seting the 'MaxOrbs' to a very small value, say

        TEveTrackPropagator* propsetCharged = new TEveTrackPropagator();
        propsetCharged->SetMaxOrbs(0.00001);

    And attach the End point as its pathmark. Which, to my observation, for most of the cases works (some time causes track missing )... But I believe there should be some more elegant, straightforward method to get this job done.

    Currently in my code, for neutral paritcle, low energy particles or particle with length between creating point and end point less than a threshold, I use a straight line to link the 2 points directly; and for Charged particle with proper momentum, I use an helix with some PathMarkers -- a charged track can have at most 3 PathMarkers in current version, they are:
    1) The End point, used for every track.
    2) The last hits in the tracker: if the track created in tracker region and end outside;
    3) The muon detector hits with the longest distance from the VTX: mostly for muon only.

    However, I found that the last two end points doesn't really constraint the track... see attached plot. (With some cout it do find the right position of the PathMarker, but just doesn't work) I don't know if its associated with my setting of MaxOrbs...


Here is the piece of codes I wrote for the PathMarker...

        track = new TEveTrack(ChargedTrack, propsetCharged);
            TEvePathMark* pm1 = new TEvePathMark(TEvePathMark::kDaughter);
            TEvePathMark* pm2 = new TEvePathMark(TEvePathMark::kDaughter);
            TEvePathMark* pm3 = new TEvePathMark(TEvePathMark::kDaughter);

        if( (Vz<2350 && Vz>-2350 && GenRadius<1810) && (Ez>2350 || Ez<-2350 || EndRadius>1810) )   // if cross the board of TPC
            {
            std::string SETHitCollection = "SETCollection";
            LCCollection* col = evt->getCollection( SETHitCollection ) ;
                    int nHits = col->getNumberOfElements();
                    int count = 0;
                    for(int j=0; j<nHits; j++)
                    {
                    SimTrackerHit* hit = dynamic_cast<SimTrackerHit*>( col->getElementAt(j) );
                    MCParticle* hitMCPart = dynamic_cast<MCParticle*>( hit->getMCParticle());
                    if(hitMCPart==part && count==0)
                    {
                    TEveVector SetHit(hit->getPosition()[0], hit->getPosition()[1], hit->getPosition()[2]);
                    pm1->fV.Set(SetHit);
                    cout<<"For "<<i<<"th Track, SET PathMarker Located!!"<<hit->getPosition()[0]<<"\t"<<hit->getPosition()[1]<<endl;
                    track->AddPathMark(*pm1);
                    count=1;
                    }
                    }

            }

        if ( (Vz<3381.6 && Vz>-3381.6 && GenRadius<3973.6) && (Ez>3381.6 || Ez<-3381.6 || EndRadius > 3973.6) )   // if end outside the HCAL
            {
            float MuonCaloHitDis = 0;
            float EndPointDisMax = 0;
            float Xmax = 0;
            float Ymax = 0;
            float Zmax = 0;

            const std::vector< std::string >* strVec = evt->getCollectionNames() ;
                    for( name = strVec->begin() ; name != strVec->end() ; name++){
                    LCCollection* col = evt->getCollection( *name ) ;
                    string SubD (*name, 0, 4);
                    if ( SubD=="Muon" )
                    {
                    cout<<"Muon Calo Hit Located"<<endl;
                    int nMuonHits = col->getNumberOfElements();
                      for(int i = 0; i<nMuonHits; i++)
                            {
                            SimCalorimeterHit* hit11 = dynamic_cast<SimCalorimeterHit*>( col->getElementAt(i) );
                            MCParticle* hitMCPart11 = dynamic_cast<MCParticle*>( hit11->getParticleCont(0));
                            if( hitMCPart11==part )
                              {
                              MuonCaloHitDis = sqrt(hit11->getPosition()[0]*hit11->getPosition()[0]+hit11->getPosition()[1]*hit11->getPosition()[1]+hit11->getPosition()[2]*hit11->getPosition()[2]);
                              if(MuonCaloHitDis>EndPointDisMax)
                                {
                                 EndPointDisMax = MuonCaloHitDis;
                                    Xmax = hit11->getPosition()[0];
                                    Ymax = hit11->getPosition()[1];
                                    Zmax = hit11->getPosition()[2];
                                }
                              }
                            }
                    }
                    }
                    TEveVector MuonFarHit(Xmax, Ymax, Zmax);
                    if(EndPointDisMax>10)
                    {
                    pm2->fV.Set(MuonFarHit);
                    cout<<"For "<<i<<"th track, Muon Calo Hit PathMarker Set, X: "<<Xmax<<" Y: "<<Ymax<<" Z: "<<Zmax<<endl;
                    track->AddPathMark(*pm2);
            }
            }

            pm3->fV.Set(End);
            track->AddPathMark(*pm3);

3)  About the OpenGL:
    Version: Here is the output I got from type glinfo and I guess the version is 1.2... I must say I got lost with those information :slight_smile:
    The OS I'm using is Fedora.
    I tried a bit to target the object creating the OpenGL Error msg:

    With only draw the geometry (Based on TGeoPGon classes), there still show 1 or 2 lines of 'GL Error invalid operation', and then no matter how I zoom & rotate, it just seems fine.
    With calorimeter hits (TEveBoxset) & tracker hits (TEvePointset), clean, no error msg.
    With estimated tracks based on TEveTrackPropagator, TEveTrack: printing lots of the error msg, espiceally when you rotate & zoom.

[manqi@localhost gear]$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.3-devel
OpenGL shading language version string: 1.10
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample,
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
GL_EXT_copy_texture, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements,
GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord,
GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays,
GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels,
GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object,
GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color,
GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap,
GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB,
GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object,
GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_ATI_fragment_shader,
GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays,
GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_program_debug,
GL_MESA_resize_buffers, GL_MESA_texture_array, GL_MESA_ycbcr_texture,
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_fragment_program,
GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1,
GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table,
GL_SGI_texture_color_table, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow,
GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays

3 GLX Visuals
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat

0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x56 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None

32 GLXFBConfigs:
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat

0x57 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x58 0 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x59 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x5a 0 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x5b 0 tc 0 32 0 r . . 8 8 8 8 0 0 8 0 0 0 0 0 0 None
0x5c 0 tc 0 32 0 r . . 8 8 8 8 0 0 8 16 16 16 16 0 0 Slow
0x5d 0 tc 0 32 0 r y . 8 8 8 8 0 0 8 0 0 0 0 0 0 None
0x5e 0 tc 0 32 0 r y . 8 8 8 8 0 0 8 16 16 16 16 0 0 Slow
0x5f 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x60 0 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x61 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x62 0 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x63 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x64 0 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x65 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x66 0 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x67 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x68 0 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x69 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None
0x6a 0 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow
0x6b 0 dc 0 32 0 r . . 8 8 8 8 0 0 8 0 0 0 0 0 0 None
0x6c 0 dc 0 32 0 r . . 8 8 8 8 0 0 8 16 16 16 16 0 0 Slow
0x6d 0 dc 0 32 0 r y . 8 8 8 8 0 0 8 0 0 0 0 0 0 None
0x6e 0 dc 0 32 0 r y . 8 8 8 8 0 0 8 16 16 16 16 0 0 Slow
0x6f 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x70 0 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x71 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x72 0 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow
0x73 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x74 0 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow
0x75 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None
0x76 0 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow

<img src="/uploads/default/original/2X/6/6176c6785ba1b467afe3b54e0e5540320c7beecf.png" width="690" height="431"><br/>

[matevz]

Hello,

The easiest thing is to start using SVN and compile ROOT yourself. In
principle it is as easy as:

svn co root.cern.ch/svn/root/trunk root
cd root
./configure
make

but the first time you might need to install some development packages
… look for complaints from configure and ask if you have no idea how
to go on.

See also this:
root.cern.ch/drupal/content/inst … oot-source

Now back to the points

1. Boxses:
   It is a bit wastefull - but as long as it works OK there is no fear.
   If you start hitting performance problems I can help you write a
   specialized class.

About dissaperance … try ticking the “Ignore sizes” check-box in
Viewer GUI, Style tab.

Transparency can be set … there is a number entry next to color
button. Or you can call “SetMainTransparency(UChar_t)”. Arg goes from
0 (opaque) to 100 (fully transparent).

Lightning should work by itself … you have any trouble with that?

2. Tracks … sorry, I’ll reply about that tomorrow, it’s getting late
   here

3. I’d suspect this to be a problem with your GL libraries (it says
   development version of MesaGL, OpenGL version 2.1, so it should in
   principle work ok). Can you try updating to the latest version? It
   should be something like mesa-libGL*.

Also, which graphics card do you have? You might profit a lot by
installing accelerated drivers.

Cheers,
Matevz

[matevz]

Hello again,

[ Sorry, but I didn’t catch your name.]

So now more about tracks and path-marks

First, a cut-n-paste from TEvePathMark class documentation:

Special-point on track:
kDaughter - daughter creation; fP is momentum of the daughter, it is subtracted from momentum of the track
kReference - position/momentum reference
kDecay - decay point, fP not used
kCluster2D - measurement with large error in one direction (like strip detectors):
fP - normal to detector plane,
fE - large error direction, must be normalized.
Track is propagated to plane and correction in fE direction is discarded.

So, by specifying kDecay path-mark you enforce the track to end there.

You have to sort the path-marks by “time”! I suspect you put the
kDecay first and then the later path-marks got ignored.

Neutral particles are propagated as straight line … just set the
charge to 0.

MaxR and MaxZ of TEveTrackPropagator determine maximum R and Z to
which the track will be propagated.

Maximum number of orbits is mostly relevant for low transverse
momentum tracks … otherwise you can get verrry looong spirals
through the detector.

You can print-out the assigned path-marks from a context menu (“PrintPathMarks()”).

What kind of magnetic field are you using? I fear that EVE convention
is negated compared to the rest of the world (following a mistake in
ALICE simulation code) … so use experimental approach to determine
its sign.

Good luck with the path-marks!

Cheers,
Matevz

[Manqi]

Hi Matev:

Manqi Again :slight_smile: I'm currently a Post Doc working in LLR, Ecole-Polytechnique on the ILC Project.

I test on the trunk version of root, and it compiles and works nicely with my display software. If I had done some change to the source code, to whom shall I report & send the modified codes?

I also update my graphic card driver, and now the annoying error msg disappear. Thank you again for your great help!

But as for the size of box, I tried both to tick the "Ignore size" icon and hard-coded way to make the system Ignore the box size, but it just doesn't helps. Nothing in the display really changes.
And for the tracks, for the case with 3 pathmarkers, according to the manual, I re-define the first 2 PathMarkers with the type kReference, and the last one with type kDecay. Still, Nothing really changes in the track display. Also I noticed, for all the charged track, if I don't change the parameter of 'MaxOrbs' (by tick in the GUI or hard-codely with SetMaxOrbs when we record the track), the last Charged track is always not displayed (While the information there is correctly recorded).

If it's convenient for you, maybe you could have a quick glace at my source code? It could be accessed at

[polywww.in2p3.fr/~ruan/ILDDispla ... 0.0.tar.gz](http://polywww.in2p3.fr/~ruan/ILDDisplay/Druid_0.0.tar.gz)

I'll soon put it also on the SVN forge of LLR... It's a tarball with size ~ 30M (most of which is the example data sample). I have some modules for reading the data/geometry file, which requires the support of LCIO/GEAR file accordingly, I put their header/library files in an Dependency sub-directory in this tarball. Thus by simply specify your ROOTSYS Path in the env.sh and compile you can have the execuable. (Also see the README in this tarball)

The source codes according to the Box & Track Display are CaloHits.cc & BuildMCTracks.cc . Waiting for your echo :slight_smile:

[matevz]

Hi Manqi,

Sorry for not catching your name – Manqi is probably as strange to me as Matevz must be to you – so I thought it is an alias

If you have any changes, just send them to me (matevz.tadel@cern.ch) … I’ll review them and eventually commit.

I managed to get Druid working … had to rebuild lcio and gear from scratch and it took me a while to figure out I have to disable 32 bit mode.

1. About boxes … I can’t see them disappear. What does:
   cd $ROOTSYS
   svn info
   say?

2. The problem with path-marks is the following (dump from PrintPathMarks in context menu of track):

TEveTrack ‘Track 0’, number of path marks 3, label -1
Reference p: 0.000000 0.000000 0.000000 Vertex: 2.462656e+02 1.816520e+03 1.838987e+03 0
Reference p: 0.000000 0.000000 0.000000 Vertex: 2.775000e+03 6.015000e+03 6.608150e+03 0
Decay p: 0.000000 0.000000 0.000000 Vertex: 3.924278e+02 7.500000e+02 8.260242e+02 0

As you see, the first two references are at larger distances than the decay!
So, the track is trying to reach the first reference when MaxR/Z stops the propagation. So … fix the coordinates.

Second, if you do not know the momentum at the reference point, use path-mark of type kDaugter and put 0 momentum. In case daughter the momentum is thought as the momentum of daughter and subtracted from the track. So, if you set it to 0, the momentum will not change.

=====================

Eventually you will have to start putting more than one point into point-set and box into box-set. This still works for a single track but will not scale to high multiplicities.

I will provide support for tooltips on per point/box basis.

Cheers,
Matevz

[Manqi]

Hi Matevz:
Oh, about the scale of the box there is something I forgot to tell you: Sorry for that.
I defined a variable called SF (Scale factor) according to the size of the box. It means how much times you scale the box comparing to the current design. And in line 142 of source code of CaloHits.cc, I set SF = 3, (corresponding to cell size 3cm * 3cm * 3 mm). As I mentioned in previous post, when you have SF >= 3 it’s properly displayed, but if you set SF = 1 than the boxes will disappear.

  The output about the SVN info is following:

[manqi@localhost root_trunk]$ svn info
Path: .
URL: [root.cern.ch/svn/root/trunk](http://root.cern.ch/svn/root/trunk)
Repository Root: [root.cern.ch/svn/root](http://root.cern.ch/svn/root)
Repository UUID: 27541ba8-7e3a-0410-8455-c3a389f83636
Revision: 31316
Node Kind: directory
Schedule: normal
Last Changed Author: moneta
Last Changed Rev: 31316
Last Changed Date: 2009-11-19 16:21:34 +0100 (Thu, 19 Nov 2009)

   I'm now checking the PathMarkers...

  ( Thank you for telling me the problem with compile Druid... do you mean your machine is an 64-bit machine while the libraries files I put in Dependency directory is created in 32-bit machine? ) 

Many thanks

Manqi

[matevz]

Hi Manqi,

I’ll check the SF stuff when I get back to my office … we are waiting for the first collisions in ALICE control room now

About 32/64 bit stuff … I have Fedora9 64-bit desktop and it complained that gear/lcio libs are incompatible on link time. So I went to download and recompile them myself and they build by default in 32-bit mode which didn’t work either with my 64-bit root. So, after a while, I figured that out and disabled 32-bit compatibility mode and everything was fine.

Cheers,
Matevz

[Manqi]

Really cool. Waiting for the Beautiful ALICE plot

[matevz]

Hi,

So, the beautiful images of first ALICE events are ready … they will be put on the CERN web pages shortly.

I tried with the SR = 1. It is true that the boxes are small and they are not visible from a far … but when I zoom in they are there. See attached screenshot.

During zoom-in, while the boxes are about 1 pixel big, they do flicker a bit. I can add a 1-pixel point for each box so that at least something will be always visible. This option is already implemented for TEveQuadset (enable via SetAntiFlick(kTRUE)).

But … I guess … your problem is different than that. Or maybe I’m looking at the wrong boxes.

Cheers,
Matevz

[Manqi]

Hi Matevz:
Yes, we also see the nice event display of ALICE… Hope this time all birds will staying safely with their bread

    I really zoomed quite hard but still cannot get the CaloHits for ECAL/HCAL displayed; (for Muon detectors I simply set them all = 10, and thus they never disappear). Here I attach several plots with scale factor SF=1, 2 and 3 (and to be clear I remove all the Geometry stuff). The big boxes in the right corner is corresponding to Muon detector hits, and the inner green points on the track is the tracker hits... you can see that when I set SF = 1, no HCAL/ECAL hits is displayed...

   In your plot, it's a little hard for me to identify if the hits is from ECAL/HCAL region...

[Manqi]

Yes you are right… for the track display, the 2 reference point is set to be scaled by 10 times (actually the default length unit is cm, while the unit in our data file is mm-- I forget to scale that for the reference points…),

Thank you !

[matevz]

Hi,

Good about the tracks

About the boxes … do you have the trunk of root now? No local mods?

Can you see them in wire-frame mode ‘w’ / outline mode ‘t’?

White-background ‘e’?

The only possibility would be a GL bug. You have the latest mesa now, right? What graphics card do you have? If it’s ATI or NVIDIA, can you try with their proprietary drivers? This should improve the rendering speed and quality.

/sbin/lspci should tell you which card you have (among other things).

Cheers,
Matevz

[pspe]

Dear Matevz,

I’d like to add a question to this thread since it seems related.

You mention the charge convention following a mistake in the ATLAS code. I set fSign of my reconstructed tracks therefore to -charge. But now the TEveMCTrack doesn’t have fSign, but takes the charge directly from the particle via the PDG code. There I cannot set the charge by hand. In this case I probably have to turn around the whole magnetic field. Is that right or do you see another solution?

cheers,
Peter

[matevz]

Dear Peter,

Yes, the correct way around this is to take it into account it in the magnetic field object you use.

Cheers,
Matevz

PS The error was in ALICE, not in ATLAS