xenon1t / processing Goto Github PK
View Code? Open in Web Editor NEWProcessing scripts for XENON data
License: Apache License 2.0
Processing scripts for XENON data
License: Apache License 2.0
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.
processing/montecarlo/mc_process.py
Line 164 in 6d9f405
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.