When merging simulations and creating libraries you might want to change the run number and the event number.
For example in my last library all events were asigned run 0 and event 1 at the time of producing the rawroot file, and when creating the grandroot file i would have liked to change the event number to something different for each event.

• Understand the needs of using of grand lib
• Understand the constraints of use specific to grand lib

doc ref:

• pres. Valentin

This seems to be due to efield2voltage.py, line 160: when antenna positions x,y,z are larger than 22 000 000, the program crashes.

Related to #59

The first time the source env/setup.sh is executed the "Install external lib gull and turtle" should be executed of course, but for the next times, it should be skipped and the script should just set the environment. Or the readme should say, that source env/setup.sh should be executed just when running for the first time, and then some other script should be sourced just to set up the environment in the following uses.

I noticed it when using 1000 events, but never when using order 10. It happens about 30% of the time. The results seem to be ok so far

Renaming files to proper file names
Segmentation fault (core dumped)

I understand that time is split into two fields (du_seconds and du_nanosecond), in all TTrees.
I fear this makes it a bit cumbersome to manipulate in the analysis.
Would it be possible to merge those in a same field?...
Or maybe have for a given coinc a single (UNIX?) timestamp with second granularity, and a nanosecond timestamp for each tigger in the coinc, eg measured with reference to the first trigger?
This could be discussed.

One additionnal problem is the integer type for these 2 fields: this does not work forZHaireS sims which have a 0.5ns time step. ALso in practice we might have a sampling frequency which translate in a nn-integer sampling step.

Getting the position of xmax using a function with hard-wired numbers is not optimal at all. We will be simulating with different atmospheric profiles eventually.

More importantly, the numbers used here dont correspond to the actual atmosphere that is usually used in ZHAireS simulations (the Linsley standard atmosphere, a multilayer atmospheric model).

Doing the integral from the top of the atmosphere, where the atmosphere is very thin, is also not ideal, since this is where the atmospheric models have the greatest relative diferences....and this will translate to bigger errors in position (since smaller densities require larger distances to make the same mass path)

I belive the position of xmax is an important parameter, that should be part of the event structure and should be provided by the shower simulator, either as an output of the simulation or as a responsibility of the routine that reads the simulation output to build the event (that can try to calculate it from the information available from the simulation, or the simulation input file, or if it is not available make any desired aproximation).

By the way, ZHAireS already outputs the exact position of Xmax (and it will be correct regardless of the atmospheric model used during the simulation).

Cheers!
Matias

few issues encountered using data rootfiles (from what I have found while dealing with GP13 data, maybe similar for g@a)-

• parameters like atmospheric temperature, pressure etc are given in adc values by gtot, would be good to have them converted in realistic values within gtot.
• sometimes values like timestamp are wrong/missing if read from classes other than tadc (e.g. trawvoltage).

Sometimes, when analysing a lot of files/events, we get:

Error in <TTreeCache::FillBuffer>: Inconsistency: fCurrentClusterStart=0 fEntryCurrent=176 fNextClusterStart=178 but fEntryCurrent should not be in between the two

Analysing the files on which it happens separately does not seem to cause the error.

According to this old ROOT thread:
https://root-forum.cern.ch/t/inconsistency-error-message-in-ttreecache-fillbuffer-when-using-clonetree-and-ttreereader/35152/2
This indicates only reduced performance. But it would be nice to figure out what is the problem at some point.

Hi,
I wanted to install the grand lib on me laptop, but the link for the turtle library that is needed refers to the gull library.
Would it be possible to have the correct link to this Turtle library?

Thanks a lot!
Aurélien

grand refined python module logging and its function getLogger()

code review may be necessary to evalute status of logger in grand package

For a set of specific branches update grand sonarqube with CI:

• need launch pylint , coverage.py without interruption (=> always True) to generate report
• need to install sonar-scanner (each time? in docker ?)
• apply sonar-scanner on file properties correclty configurated

Likely location of bug: /grand/dataio/root_trees.py

There is a bug when one tries to assign a value to trace_ch in a TADC tree. If you try to assign tadc.trace_ch = [my_trace_list], you get a very long error message that starts with:

*** Error in `python3': munmap_chunk(): invalid pointer: 0x000055bcdc9d65b0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7f474)[0x7fc44b063474]
[0x7fc38e68210e]
[0x7fc38e68230f]
[0x7fc38e68208e]
[0x7fc38e682284]
...

This is the same error one might encounter when using tadc.copy_contents(). However, tadc.trace_ch = np.array([my_trace_list]) DOES work. Hopefully this can help to solve this issue.

Note that there is no issue when assigning values to other TADC attributes, it's only a problem for tadc.trace_ch. Not checked for trace properties in other TTrees.

I was trying to use copy_contents to duplicate the contents of the tree so i dont need to fill everytihng in convert_efield2efield.py.
located https://github.com/grand-mother/grand/tree/master/scripts (will push it soon, you have to uncomment at the end the copy_contents() line)

to run:
./convert_efield2efield.py --verbose debug --target_duration_us 4.96 --target_sampling_rate_mhz 500 --seed=1234 ../sim2root/Common/sim_Xiaodushan_20221026_180000_RUN0_CD_DC2Alpha_0000/

it segfaults with

IncrementalExecutor::executeFunction: symbol 'ZN9__gnu_cxx13new_allocatorISt6vectorIfSaIfEEE9constructIS3_JS1_IdSaIdEEEEEvPT_DpOT0' unresolved while linking symbol '__cf_97'!
You are probably missing the definition of void __gnu_cxx::new_allocator<std::vector<float, std::allocator > >::construct<std::vector<float, std::allocator >, std::vector<double, std::allocator > >(std::vector<float, std::allocator >, std::vector<double, std::allocator >&&)
Maybe you need to load the corresponding shared library?
Fatal in TBufferFile::AutoExpand: Request to expand to a negative size, likely due to an integer overflow: 0x8de82690 for a max of 0x7ffffffe.
aborting
Generating stack trace...
0x00007ff06675e2c8 in TBufferFile::WriteFastArray(float const, int) + 0x68 from /opt/root/lib/libRIO.so
0x00007ff0667e4d65 in TGenCollectionStreamer::WritePrimitives(int, TBuffer&) + 0x265 from /opt/root/lib/libRIO.so
0x00007ff0667e86ad in TGenCollectionStreamer::Streamer(TBuffer&) + 0x1ed from /opt/root/lib/libRIO.so
0x00007ff0667b54d8 in TCollectionStreamer::Streamer(TBuffer&, void*, int, TClass*) + 0x58 from /opt/root/lib/libRIO.so
0x00007ff0667bad95 in TEmulatedCollectionProxy::WriteItems(int, TBuffer&) + 0x1d5 from /opt/root/lib/libRIO.so
0x00007ff0667bb227 in TEmulatedCollectionProxy::Streamer(TBuffer&) + 0xf7 from /opt/root/lib/libRIO.so
0x00007ff0667b54d8 in TCollectionStreamer::Streamer(TBuffer&, void*, int, TClass*) + 0x58 from /opt/root/lib/libRIO.so
0x00007ff0667bad95 in TEmulatedCollectionProxy::WriteItems(int, TBuffer&) + 0x1d5 from /opt/root/lib/libRIO.so
0x00007ff0667bb227 in TEmulatedCollectionProxy::Streamer(TBuffer&) + 0xf7 from /opt/root/lib/libRIO.so
0x00007ff0667b54d8 in TCollectionStreamer::Streamer(TBuffer&, void*, int, TClass*) + 0x58 from /opt/root/lib/libRIO.so
0x00007ff06675f45b in TBufferFile::WriteFastArray(void*, TClass const*, int, TMemberStreamer*) + 0xbb from /opt/root/lib/libRIO.so
0x00007ff0669dba33 in int TStreamerInfo::WriteBufferAux<char**>(TBuffer&, char** const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) at TStreamerInfoWriteBuffer.cxx:? from /opt/root/lib/libRIO.so
0x00007ff066839914 in TStreamerInfoActions::GenericWriteAction(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*) + 0x54 from /opt/root/lib/libRIO.so
0x00007ff06675eeb5 in TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*) at TBufferFile.cxx:? from /opt/root/lib/libRIO.so
0x00007ff0512faaaa in from /opt/root/lib/libTree.so.6.26
0x00007ff051307e0b in TBranchElement::FillImpl(ROOT::Internal::TBranchIMTHelper*) + 0x3fb from /opt/root/lib/libTree.so.6.26
0x00007ff051377f76 in TTree::Fill() + 0x166 from /opt/root/lib/libTree.so.6.26
0x00007ff0852c7024 in
0x00007ff067068697 in from /opt/root/lib/libcppyy_backend3_8.so.6.26
0x00007ff067069956 in Cppyy::CallI(long, void*, unsigned long, void*) + 0x36 from /opt/root/lib/libcppyy_backend3_8.so.6.26
0x00007ff0670f7843 in from /opt/root/lib/libcppyy3_8.so
0x00007ff0670e59a6 in CPyCppyy::CPPMethod::ExecuteFast(void*, long, CPyCppyy::CallContext*) + 0x36 from /opt/root/lib/libcppyy3_8.so
0x00007ff0670e5e40 in CPyCppyy::CPPMethod::ExecuteProtected(void*, long, CPyCppyy::CallContext*) + 0x110 from /opt/root/lib/libcppyy3_8.so
0x00007ff0670e373b in CPyCppyy::CPPMethod::Execute(void*, long, CPyCppyy::CallContext*) + 0x2b from /opt/root/lib/libcppyy3_8.so
0x00007ff0670e4730 in CPyCppyy::CPPMethod::Call(CPyCppyy::CPPInstance*&, _object*, _object*, CPyCppyy::CallContext*) + 0xb0 from /opt/root/lib/libcppyy3_8.so
0x00007ff0670e8e19 in from /opt/root/lib/libcppyy3_8.so
0x00000000005f3e1e in _PyObject_MakeTpCall + 0x29e from python3
0x0000000000570674 in _PyEval_EvalFrameDefault + 0x5cf4 from python3
0x00000000005f6836 in _PyFunction_Vectorcall + 0x1b6 from python3
0x000000000056b1da in _PyEval_EvalFrameDefault + 0x85a from python3
0x000000000056939a in _PyEval_EvalCodeWithName + 0x26a from python3
0x000000000068d047 in PyEval_EvalCode + 0x27 from python3
0x000000000067e351 in from python3
0x000000000067e3cf in from python3
0x000000000067e471 in from python3
0x000000000067e817 in PyRun_SimpleFileExFlags + 0x197 from python3
0x00000000006b6fe2 in Py_RunMain + 0x212 from python3
0x00000000006b736d in Py_BytesMain + 0x2d from python3
0x00007ff0bf6540b3 in __libc_start_main + 0xf3 from /lib/x86_64-linux-gnu/libc.so.6
0x00000000005fa5ce in _start + 0x2e from python3

Here's a list of things I've noticed while testing the raw sim to final root file pipelines:

• t_0 is not being stored, but can be calculated as: t0 = du_second[unit number] *1e9 + du_nanosecond[unit number]
• time_max is empty (what is that supposed to be anyway?)
• Zhaires traces have varying lengths, although we agreed that all traces should be 4096ns long
• time bin size needs to be stored properly - in my opinion, for each tree. Currently voltage and efield trees have traces with different lengths due to different time bin sizes

Something's very wrong with the traces since the most recent changes in dev_sim2root. Up until yesterday the times looked fine, both with t0 shifts and without. Now we have things like this:

currently we are saving t_pre and t_post, the parameters that define the time window arround the trigger time, in t_efieldsim.

I dont see where in the data files is this going to be stored. Should it be in trun?

• as in the tilte
• the objective is
• to have automatic filenaming as per the data managament rules, and an override function to give an output filename.
• to to output a simshower file with the trees asociated to the shower simulation, and a second simefiled file with the trees asociated to the efield simulation.

As a side projet, i will modify zhaires rawroot script to give the appropiate (ie unique) id to the antennas.

It seems that there is a probleme in the class VoltageEventTree in grand.io.root_trees
If I create 2 different VoltageEventTree objects and add datas to the trace_x in the first
and different datas to the second object, the first datas are also present in the second object.

As an example, the following code :

from grand.io.root_trees import *
tvoltage1 = VoltageEventTree()

data1 = [1, 2, 3]
tvoltage1.trace_x.append(data1)
print(tvoltage1.trace_x)

tvoltage2 = VoltageEventTree()
data2 = [3, 4, 5]
tvoltage2.trace_x.append(data2)
print(tvoltage2.trace_x)

produces the following output:

creating tree teventvoltage None
[[1.0, 2.0, 3.0]]
creating tree teventvoltage None
[[1.0, 2.0, 3.0], [3.0, 4.0, 5.0]]

in sim2 root there are 2 lines that try to compute the time at the du

# Generate trigger times from t0s
gt.tefield.du_seconds = np.int64((trawefield.t_0 - trawefield.t_pre)/1e9)  
gt.tefield.du_nanoseconds = np.int64((trawefield.t_0 - trawefield.t_pre)-np.array(gt.tefield.du_seconds)*1e9)

this is wrong (and crashes becouse it can give negative values and the variables are unsigned int.
Im not entirelly sure of what this variables should have, but either if it is the trigger time of the detector or the time of the first time bin, the complexity here is that times coming from zhaires and coreas can be negative. Time is 0 at the arrival of the core to the ground, so some antennas have a t0 (triggertime) that is negative. Thease means that in some cases the du_second can be the second before.

The event second and nanosecond (the core arrival time) is stored in the meta tree. So if we are going for trigger time the correct values should be assuming we want to store the first time in the trace (if this should be trigger time, remove t_pre)

if(event_nanosecond + trawefield.t_0 - trawefield.t_pre>=1e9):
gt.tefield.du_seconds = event_second +1
gt.tefield.du_nanoseconds = event_nanosecond + trawefield.t_0 - trawefield.t_pre -1e9
else if(event_nanosecond + trawefield.t_0 - trawefield.t_pre>=0):
gt.tefield.du_seconds = event_second
gt.tefield.du_nanoseconds = event_nanosecond + trawefield.t_0 - trawefield.t_pre
else : #this means its negative
gt.tefield.du_seconds = event_second -1
gt.tefield.du_nanoseconds = event_nanosecond + trawefield.t_0 - trawefield.t_pre +1e9

In some cases (when you are trying to compute effetive area for example) its also important to keep track of simulations that did not hit any antenna , but you tried, for statistical reasons.
Currently sim2root crashes, and even if we fix that the rest of the pipeline has never been tested in that case, and will fail in several places.
This is something we want to have, but is not urgent right now.

Regarding #59

After executing source env/setup.sh, the script downloads and unpacks grand_model_2304.tar.gz, which contains an older version of test_efield.root. The downloaded tra.gz must be updated to contain a compatible test_efield.root. Actually, I don't know where to get the compatible one.

Hi Jean-Marc, thanks for the nice documentation on Docker.
One small issue thoiugh: your link to Docker images of GRANDLIB points to https://hub.docker.com/, which is kind of a homepage. Shouldn't it be https://hub.docker.com/r/jcolley/grandlib_eclipse?

Thanks
Olivier
PS: solution 1 for display did not work for me (Ubuntu 18.04 on a VirtualBox) but solution 2 did.

sim2root seems to dislike negative values, but it needs to be able to handle them

Traceback (most recent call last):
File "/home/grand/sim2root/CoREASRawRoot/../Common/sim2root.py", line 383, in
main()
File "/home/grand/sim2root/CoREASRawRoot/../Common/sim2root.py", line 75, in main
rawefield2grandroot(trawefield, gt)
File "/home/grand/sim2root/CoREASRawRoot/../Common/sim2root.py", line 361, in rawefield2grandroot
gt.tefield.du_seconds=tempseconds
File "/home/grand/grand/dataio/root_trees.py", line 186, in set
inst += value
File "/home/grand/grand/dataio/root_trees.py", line 133, in iadd
if self.ndim == 1: value = array.array(cpp_to_array_typecodes[self.basic_vec_type], value)
OverflowError: can't convert negative value to unsigned int
Traceback (most recent call last):
File "/home/grand/sim2root/CoREASRawRoot/coreas_pipeline.py", line 70, in
subprocess.run(sim2root, check=True)
File "/usr/lib64/python3.10/subprocess.py", line 526, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['python3', '../Common/sim2root.py', 'Coreas_006100.root']' returned non-zero exit status 1.

Very stange:

grand/examples/simulation$ python shower-event.py
grand/examples/simulation$ echo $?
0

so OK, but

/grand$ python examples/simulation/shower-event.py 
/grand$ echo $?
1

NOK ?

error:

Traceback (most recent call last):
  File "examples/simulation/shower-event.py", line 31, in <module>
    shower = ShowerEvent.load(showerdir)
  File "/home/jcolley/projet/grand_wk/noAppIm/grand/grand/simulation/shower/generic.py", line 117, in load
    self = load(source)
  File "/home/jcolley/projet/grand_wk/noAppIm/grand/grand/simulation/shower/generic.py", line 127, in _from_datafile
    with io.open(path) as root:
  File "/home/jcolley/projet/grand_wk/noAppIm/grand/grand/io.py", line 477, in open
    f = _File(file, mode)
  File "/home/jcolley/install/miniconda3/envs/gd_test2/lib/python3.8/site-packages/h5py/_hl/files.py", line 507, in __init__
    fid = make_fid(name, mode, userblock_size, fapl, fcpl, swmr=swmr)
  File "/home/jcolley/install/miniconda3/envs/gd_test2/lib/python3.8/site-packages/h5py/_hl/files.py", line 220, in make_fid
    fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5f.pyx", line 106, in h5py.h5f.open
FileNotFoundError: [Errno 2] Unable to open file (unable to open file: name = '../../tests/simulation/data/zhaires', errno = 2, error message = 'No such file or directory', flags = 0, o_flags = 0)

Need to define a directory to store data for grand like :
HorizonAntenna_EWarm_leff_loaded.npy

This must be usable as well by clone package or by pip install package
=> not in tree structure of git package

Solution:
create in HOME a directory .grand

Reading trees as suggested on the script DC2Alpha/PlotEventTraces.py by Matias.

Simulation directory: GP300_Xi_Sib_Proton_1.25_53.9_60.52_13020/

*** Issues:

1 - The site height does not seem to be available on the root trees. It would be nice to have it in meters somewhere.

2 - gt.tshower.xmax_pos is missing. gt.tshower.xmax_pos_shc is available though.

3 - gt.tshower.shower_core_pos seems to be wrong
print(gt.tshower.shower_core_pos)
[-3541.518 5465.649 0. ]

3a - gt.tshower.direction is missing missing. I was able to evaluate it using
my_core = [0, 0, 1264]
ev = my_core - gt.tshower.xmax_pos_shc
print(gt.tshower.zenith, np.arccos(-ev[2]/np.linalg.norm(ev))*180/np.pi)
53.89 53.88996881224265

4 - du_xyz is supposed to be in site's referential
print(gt.trun.du_xyz[0])
[-788.5800170898438, -1965.6500244140625, 1336.5]
Is the output compatible with site's referential? Shouldn't the site height be subtracted here?

Wrap the radio-shower simulators within this object.

Is it possible to make confidential issues in a public git repository?

I could not make a small example to reproduce this issue, but is preventing me to run the simpipe reliably in lyon.
It happens on some set of files but not on all of them. But when you identify a set of files where it happens, it always happens.

it seems to be crashing somwhere inside of shower.load_root(self.shower) ((line 133 of efield2voltage.py)

the last two messages i get are
21:58:18.668 DEBUG [grand.geo.turtle 209] Map /pbs/home/t/tueros/GRANDlib/grand/data/egm96.png already in cache
21:58:18.669 DEBUG [grand.geo.coordinates 98] geoid_undulation for [40.99000168] [93.94000244]

looking at the output fo working events, these two lines should repeat a couple of times....but it dies at the first

is definitelly something happening in /grand/sim/shower/gen_shower.py , line 82 to 133, related to the coordinate system.

To make it more obnoxious, I have no problems running on my own PC, on any set of files.
In lyoon i run with apptainer, in my pc with docker.
Sorry i cant give anything easier to debug.

In class ShowerEventTree and ShowerEventSimdataTree we have a property called "date".
As date is a reserved keyword in many laguages it will lead to problems (for example it's forbidden to name a column "date" in a database).
I suggests to rename it (maybe in event_date).

For example, wrap the grand_tour C functions.

efield2voltage is missing the implementation of the ADC, and in particular to be able to handle traces that are not the same lenght as the hardware lenght.

For example, in
/sps/grand/DC2Alpha/CoREAS/sim_Dunhuang_20170401_000000_RUN1_CD_CoREAS_0000

-rw-r--r-- 1 tueros grand 12M Mar 15 05:27 adc_3205-47214_L1_0000.root
-rw-r--r-- 1 tueros grand 34M Mar 15 05:27 efield_3205-47214_L0_0000.root
-rw-r--r-- 1 tueros grand 63M Mar 15 05:27 efield_3205-47214_L1_0000.root
-rw-r--r-- 1 tueros grand 12K Mar 15 05:27 run_1_L0_0000.root
-rw-r--r-- 1 tueros grand 12K Mar 15 05:27 run_1_L1_0000.root
-rw-r--r-- 1 tueros grand 7.6K Mar 15 05:27 runefieldsim_1_L0_0000.root
-rw-r--r-- 1 tueros grand 8.3K Mar 15 05:26 runshowersim_1_L0_0000.root
-rw-r--r-- 1 tueros grand 28K Mar 15 05:27 shower_3205-47214_L0_0000.root
-rw-r--r-- 1 tueros grand 120K Mar 15 05:26 showersim_3205-47214_L0_0000.root
-rw-r--r-- 1 tueros grand 251M Mar 15 05:27 voltage_3205-47214_L0_0000.root

you can see voltage_L0 is 251M while efield_L0 is 34MB, efield_L1 is 63MB (even if it is the same lenght and lower sampling rate!) and ADC is 12MB.

I find this weird...

Add a way to specify geodetic coordinates height w.r.t. sea level or to the topography

Informations about:

• development cycle
• code quality : tools, SonarQube
• development environment: docker, github, git

Add a click and play way to edit the source from the published doc.

It seems that root_trees.py have some memory leaks.
When reading a large number of files in a loop, memory usage increases constantly and the job get killed because out of memory.

Ex: The simple code below illustrate it :

from grand.dataio.root_trees import *
from pathlib import Path
import psutil
id=0
p = psutil.Process()
print(p.memory_info())

pathlist = Path("/sps/grand/data/gp13/jul2023").rglob('*.root')
for pathdir in pathlist:
    path=str(pathdir)
    print(str(id)+" "+path)
    tadccounts = TADC(path)
    list_of_events = tadccounts.get_list_of_events()
    print(len(list_of_events))
    for event, run in list_of_events:
        pass
    trawvoltage = TRawVoltage(path)
    list_of_events = trawvoltage.get_list_of_events()
    for event, run in list_of_events:
        pass
    id=id+1
    print(p.memory_info())

produces the following output :

pmem(rss=389042176, vms=6187302912, shared=183660544, text=2457600, lib=0, data=5477257216, dirty=0)
0 /sps/grand/data/gp13/jul2023/t3_trigger/ROOTfiles/GRAND.TEST-CH1-AND-CH2-TRIGGER-ChanXYZ-20dB-11dus.20230727082822.100.11_dat.root
341
pmem(rss=463097856, vms=6377504768, shared=211886080, text=2457600, lib=0, data=5656481792, dirty=0)
1 /sps/grand/data/gp13/jul2023/t3_trigger/ROOTfiles/GRAND.TEST-CH1-AND-CH2-TRIGGER-ChanXYZ-20dB-11dus.20230727170958.100.1_dat.root
0
pmem(rss=463233024, vms=6377504768, shared=211886080, text=2457600, lib=0, data=5656481792, dirty=0)
2 /sps/grand/data/gp13/jul2023/t3_trigger/ROOTfiles/GRAND.TEST-CH1-AND-CH2-TRIGGER-ChanXYZ-20dB-11dus.20230727030733.100.5_dat.root
341
pmem(rss=475344896, vms=6519545856, shared=211890176, text=2457600, lib=0, data=5798522880, dirty=0)
3 /sps/grand/data/gp13/jul2023/t3_trigger/ROOTfiles/GRAND.TEST-CH1-AND-CH2-TRIGGER-ChanXYZ-20dB-11dus.20230727035812.100.6_dat.root
329
....
399 /sps/grand/data/gp13/jul2023/20dB/ROOTfiles/GRAND.TEST-RAW-10s-ChanXYZ-20dB-11dus.20230708174423.041_dat.root
3364
pmem(rss=2953019392, vms=71568863232, shared=211902464, text=2457600, lib=0, data=70847840256, dirty=0)
400 /sps/grand/data/gp13/jul2023/20dB/ROOTfiles/GRAND.TEST-RAW-10s-ChanXYZ-20dB-11dus.20230702023233.028_dat.root
3364
pmem(rss=2958274560, vms=71741800448, shared=211902464, text=2457600, lib=0, data=71020777472, dirty=0)

showing that the vms: aka “Virtual Memory Size”, this is the total amount of virtual memory used by the process grows constantly (from 6187302912 to 71741800448 after reading 400 files) and the data: aka DRS (data resident set) the amount of physical memory devoted to other than executable code. It matches “top“‘s DATA column) grows from 5477257216 to 71020777472 (so x10 in both cases).
When running this code @ccin2p3 it get killed after a while with error : slurmstepd: error: Detected 1 oom-kill event(s) in StepId=54442604.batch. Some of your processes may have been killed by the cgroup out-of-memory handler.

Currently the setup.sh script might fail because $(arch) can refer different names: linux64, amd64, x86_64, etc. which actually all correspond to the same architecture. This needs to be standardised.

I was mistaken about the coordinate system we agreed for the rawroot and introduced a shift in sim2root. This needs to be removed.
will do it next week, before we set into generating the DC2 library.