xenon1t / processing Goto Github PK

Current conversion/flattening of fax truth information into event-by-event format (from peak-by-peak):

https://github.com/XENON1T/processing/blob/master/montecarlo/fax_waveform/TruthSorting.py

only stores a single S1 and single S2 peak, so we lose information about multiple coincidence/scatters.

@jhowl01, @mcfatelin: Can this be expanded to store the arrays of peaks (in both Pickle and ROOT formats)?

(Note this is another workaround to @JelleAalbers's suggestions here: XENON1T/pax#453)

(Simple task for anyone wanting to get more familiar with the workflow.)

Need to add "-s" argument to run_sim.sh here:
https://github.com/XENON1T/processing/blob/master/montecarlo/run_sim.sh#L125

nSort arguments documented here:
https://github.com/XENON1T/mc/blob/master/nSort/nSort.C#L21

As well as more flexibility for PATCHTYPE argument, which has been expanded according to Table 2 here:
https://xecluster.lngs.infn.it/dokuwiki/doku.php?id=xenon:xenon1t:sim:notes:marco:xenon1t-tips-for-mc-production#running_the_patch_scripts

Need to decide whether it should be a command line argument to run_sim.sh (for e.g. mc_process.py grid submission), or just modified locally by user for each configuration.

Currently the type of peak isn't stored in truth root file (See fax WaveformSimulator), which makes the current TruthSorting extremely difficult since in the latest release of fax the photoionization after pulses are also saved ( pax v6.4.0 ).

We have in run_sim.sh#L77 the following definition of the parameters, where the EFIELD is defined as V/cm for SR0 and kV/cm for SR1. I think that this is not correct and that we should check all involved parts of MC, nSort and FAX if the definition is consistent.

# Taken from lax (https://github.com/XENON1T/lax/pull/62)
# e-lifetime: https://xecluster.lngs.infn.it/dokuwiki/doku.php?id=xenon:xenon1t:org:commissioning:meetings:20170628#electron_lifetime
if [[ ${SCIENCERUN} == 0 ]]; then
    DIFFUSION_CONSTANT=22.8  # cm^2/s
    DRIFT_VELOCITY=1.44      # um/ns
    ELECTRON_LIFETIME=450    # us
    EFIELD=124               # V/cm
else
    DIFFUSION_CONSTANT=31.73 # cm^2/s
    DRIFT_VELOCITY=1.335     # um/ns
    ELECTRON_LIFETIME=550    # us
    EFIELD=0.082             # V/cm
fi

I have produced some simulation data using the README, which is very clear and works fine almost all the way for me :) In step 11, the organize script expects that all files are in a folder named output which for me aren't. I suppose that this should be explicit in step 10, i.e.
/project/lgrandi/xenon1t/simulations/mc_v<MC_VERSION>/pax_v<PAX_VERSION>/<MC_FLAVOR>/<MC_CONFIG>/output
In my case, since I already untarred 10000 files, the argument list was event too long for a simple mv so that I fixed this with for f in *; do mv -v $f output/; done, just for future reference.
Do you agree on this? In that case I'll just update step 10 in the README.

the get_config function in mc_process.py (line 154) takes as an input only "experiment". It looks for macros in the directory "latest_dir + "/macros"+ experiment.
Therefore, if the mc_version (mc_releases) isn’t the last deployed it doesn’t find the macros.

I saw that in FAX/HAX there is also an option the set the drift_field and s2_mean_area_fraction_top. I don't know if we need them but we could add them to the sciencerun flag and use the actual values. At least the drift_field could be adjusted by the field macros.

(Simple task for anyone wanting to get more familiar with the workflow.)

Add flag to toggle tar'ing and copying in run_sim.sh here:
https://github.com/XENON1T/processing/blob/master/montecarlo/run_sim.sh#L178
such that it can be used locally. Default can be off so as to minimize changes in mc_process.py.

PR 230 in the MC repo will break compatibility with the processing scripts. Current workaround is to delete all related options from both python files.
We have to decide how to move forward - we probably need a logic so that 1T simulations are not affected (if we would just drop the options in all files ..). @ramirezdiego what do you think?

Seems to be lots of redundant code for custom input files in Pegasus.DAX3: https://github.com/XENON1T/processing/blob/v0.0.2/montecarlo/mc_process.py#L262
Maybe can make a function.

error points to Xenon1tStackingAction.cc:65
other isotopes run fine, fault seems specific to stacking for G4Triton.