All of the X/Y nodes are outside boundaries. (Problem with TRestMesh)

RESTFramework
1

REST version : v2.2.18.
REST commit : 368fcd4f.

Hi!
I am stuck with a problem: when I am trying to reconstruct 10 restG4 events I receive a lot of warnings like this:

REST WARNING (TRestMesh) : X node (-40.5) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : X node (-37.5) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : X node (-37.5) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : X node (-37.5) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : X node (-40.5) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : Y node (1.125) outside boundaries. Setting it to : 0
REST WARNING (TRestMesh) : Y node (1.125) outside boundaries. Setting it to : 0

In my configuration.rml file I employ TRestFastHitsToTrackProcess which should use TRestMesh if I am not mistaken.
world_size in the GeometrySetup.gdml file was set to “4000”, therefore In order to solve such problem with TRestMesh I tried to modify TRestFastHitsToTrackProcess parameters:

<parameter name="cellResolution" value="10mm" />
<parameter name="netSize" value="4000mm" />
<parameter name="netOrigin" value="(-2000,-2000,-2000)mm" />

However, It didn’t help.
I am not sure where is the problem exactly.
My confrig.rml , restG4.root (and, just in case, restG4.rml), geometry pack and readout.root files are listed here:
configFile_G4Hits_To_Track.rml (5.1 KB)
Run00062_electron2_2MeV_particle_gen.root (397.7 KB)
geometry.zip (13.9 KB)
Panda_140kg.root (3.7 MB)

Could you, please, help me where can I find the roots of these warnings?

2

Hi,

there were some updates to TRestMesh classes, mainly bug fixes, but that might have affected to this process.

I will give you some clues to try to identify the problem, and as soon as I have time I will look to it.

The first thing is to test why you get the warning. It is a problem with the following GetNodeX method that I copy/pasted here?

Int_t TRestMesh::GetNodeX(Double_t x, Bool_t relative) {
    if (IsNaN(x)) return 0;

    Double_t xInside = x - fNetOrigin.X();
    if (relative) xInside = x;

    if (xInside > fNetSizeX) {
        cout << "REST WARNING (TRestMesh) : X node (" << x
             << ") outside boundaries. Setting it to : " << fNodesX - 1 << endl;
        return fNodesX - 1;
    }

    if (xInside < 0) {
        cout << "REST WARNING (TRestMesh) : X node (" << x << ") outside boundaries. Setting it to : " << 0
             << endl;
        return 0;
    }

    Int_t nX = (Int_t)(xInside * (fNodesX - 1) / fNetSizeX);

    return nX;
}

Are you giving an x value that is within the range of the RML definition?
It is fNetOrigin, fNetSize and fNodesX properly initialized?

Just write some cout output with those values at that method to check those are correct.

3

Hi Andrii,

I am missing the file processFile_general.rml in order to reproduce the error.

4

Hi Javier,

I will try to do this right now.
Sorry for the missing file.
processFile_general.rml (34.0 KB)

5

Ok, I identified the problem.

The initial problem is that the data member values inside TRestFastHitsTrackProcess were not properly initialised.

I think that would have been easier to identify if we were able to see the metadata process members on screen, so now I have added the metadata output on screen by default at INFO output level.

The problem in origin is that it seems the section is identified by name, and not by process. The following output was the key this time.

Screenshot 2020-08-04 at 12.31.41
Screenshot 2020-08-04 at 12.31.412228×494 262 KB

This happens because, both, TRestHitsToTrackProcess and TRestFastHitsToTrackProcess had the same name : hitsToTrack in your RML file.

Then, the TRestHitsToTrackProcess RML section was used to describe your TRestFastHitsToTrackProcess. Personally I believe this is not the most intuitive. I thought the TRestProcess class used would be also checked/validated. @nkx?

If you replace the name (at both RMLs) inside TRestFastToHitsProcess by i.e. fastHitsToTrack. That would solve at least one problem.

6

Thank you very much.

I have changed the name of the processes.rml file, so that TRestFastHitsToTrackProcess and TRestHitsToTrackProcess have different names and after pulling your commit everything works fine.