XENON1T / pax

The XENON1T raw data processor [deprecated]

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Need e-field dependence in fax

pdeperio opened this issue · comments

Am 17.06.2017 um 19:19 schrieb @sdiglio sara diglio:

I tried to generate some Kr83m events with 2 different drift electric
fields: 155 V/cm (i.e cathode 15 KV) and 82 V/cm (i.e cathode 8 kV).

In order to see if the electric field variation was correctly taken into
account, I compared the drift time : I expected to see a longer drift
time in correspondence of the lower field.
Unfortunately what I got is attached in the mail, where you see no
difference between the two samples (40 events each).

This clearly means that the field variation have not been taken into
account. In particular, the maximum drift time in the attached figure
corresponds to what expected at 155 kV/cm (that also corresponds to the
default electric field when generating events). It is thus clear that
for some reason the production with 82 kV/cm did not work properly.

In order to understand if I did something wrong while generating the
events, I copy here the syntax I used:

a) to generate events with 155 V/cm field (default, cathode 15 kV) in
the liquid

python mc_process.py --flavor NEST --config TPC_Kr83m --batch-size 2000
--events 40000 --mc-version v0.3.0 --pax-version v6.6.5 --grid-type osg

b) to generate events with 82 V/cm field (cathode 8 kV) in the liquid

python mc_process.py --flavor NEST --config TPC_Kr83m --batch-size 2000
--events 20000 --mc-version v0.3.0 --pax-version v6.6.5 --grid-type osg
--preinit-efield preinit_EF_C8kVA4kV.mac --start_job 20

Many thanks in advance for your help!

On Jun 18, 2017, at 1:08 PM, @l-althueser Lutz Althüser L.Althueser@uni-muenster.de wrote:

The Geant4 part of the simulations works fine and uses a custom drift
field. This can be checked in the MC output file - there should be an
entry in the LXe material with a certain drift field and in the macros
directory of the root file should be an entry for the drift field macro.
The part in the MC Chain which is not yet tested is FAX. I have looked
in the PAX repository and saw that there is a drift field used which is
given by the default config file. This means that FAX always uses the
value of the XENON1T.ini (500 V/cm).

Do you agree Patrick and should we change this to the value of the ROOT
file? Should we generate a PAX issue from these mails?

Dear @sdiglio, sorry we overlooked this, indeed fax/pax is not taking into account variations of e-field in simulations.

For real data, the reconstruction (pax) pulls the drift velocity from a function in the corrections DB, shown under "Drift velocity correction" in XENON1T/cax#95. @JelleAalbers, would you be able to include this function directly in pax too (instead of the hardcoded drift_velocity_liquid in XENON1T.ini)? Then we'd only need to specify the drift_field, which should pull drift_velocity_liquid from your function, right?

Furthermore, we'd also need the diffusion_constant_liquid e-field dependence, which I don't think has been fully derived yet. @weiyuehuan started this for the SR1 nominal field, but would need to be extended to all relevant fields and using the correct drift velocity function. Is anyone able to do this?

In the meantime, @sdiglio, you can also specify these parameters manually in the paxer command in run_sim.sh, e.g.:

paxer  --config XENON1T SimulationMCInput --config_string "[WaveformSimulator]truth_file_name=\"${FAX_FILENAME}\"; drift_field=x; diffusion_constant_liquid=y; [DEFAULT]drift_velocity_liquid=z"

@l-althueser The field value would need to be added into the Patch output ROOT file, and then read into fax/pax to override the default.

Indeed fax does not attempt to derive a changed drift velocity or diffusion constant from an electric field, any dependence we would put in would be superceded by the direct measurements we do.

Somewhat confusingly there is actually an electric field value in the config, but it's only used for some obscure part of the full S1 time structure model we no longer use (hence it's still set to a placeholder value: https://github.com/XENON1T/pax/blob/master/pax/config/XENON1T.ini#L244)

The function used in cax is simply a polynomial fit, and it's only for getting a halfway decent result if you go to a new voltage for the first time. Then, we should look where the cathode is in drift time and update the function (in the corrections database) so it's almost exactly right at the new point. Since this might change often we chose to put it in cax. I can image that you might want to simulate what happens at a different field of course, then you can change the value in the ini or as Patrick described.

If you want to make a diffusion constant vs Efield fit, here are a few other datapoints: https://xecluster.lngs.infn.it/dokuwiki/doku.php?id=xenon:xenon1t:aalbers:drift_and_diffusion#results

We don't yet have run dependence in the simulation, and would like to avoid requiring access to the DB until we do. For now, can you @JelleAalbers provide your (official) drift velocity function and notebooks/instructions for reproducing it?

And then we should use this notebook for updating with new fields and the diffusion constants. @sdiglio would you be able to look into this?

How does this compare to @weiyuehuan's derivation for lax? We should ensure these are consistent.

@pdeperio , @l-althueser , @JelleAalbers Thanks for the explanation.
Looking at Jelle's notebook and note, I see that the some of the values corresponding to the drift field we are interested in (cathode -4, -5 -6, -7 kV and anode +4kV) are not present. I think either myself or Chloé can provide those numbers (they can also be extracted from this previous note).

The only thing is that I will be available to work on it only from July the 6th. In the meanwhile, I think Chloé can take over, as soon as the CI-Connect account will be ready.

I think that I can provide the diffusion constant for the drift field with the cathode at -4, -5 -6, -7 kV and anode +4kV, using the dataset of February 7th (run 6861 to 6870), which are Kr83m datasets.

I started working on it and I will let you know when I am done.

Chloé

Hi Everyone!
Sorry for the late answer.

I calculated the parameters needed for a simulation at different electrical field : the drift velocity, the electron lifetime and the diffusion constant. To determine the diffusion constant, I used the same method as Jelle in this note https://xecluster.lngs.infn.it/dokuwiki/doku.php?id=xenon:xenon1t:aalbers:drift_and_diffusion#results

^ Voltage (V/cm) ^ Electrons Velocities (µm/ns) ^ Electron Lifetime (µs)^ Diffusion Constant (cm²/s)^
| 40 | 0,9945 +/- 0,0008 | 512.94 +/- 5.85 | 32.88 +/- 0.72 |
| 50 | 1,1187 +/- 0,0006 | 524.42 +/- 5.08 | 31.56 +/- 0.73 |
| 60 | 1,2119 +/- 0,0005 | 530.75 +/- 5.40 | 30.66 +/- 0.73 |
| 70 | 1,2802 +/- 0,0004 | 523.35 +/- 5.19 | 29.15 +/- 0.73 |
| 80 | 1,3313 +/- 0,0004 | 530.13 +/- 5.95 | 27.70 +/- 0.73 |

Do you think theses values are correct ?
Can I go forward for the MC simulation or did I need an other parameter ?
Do you want me to write a note about the method I used to provide these numbers?

Thanks !
Chloé

Hi Chloé, I see you've already made the note and it looks good.

Then yes, as discussed at the MC telecon, please go ahead with data/MC comparisons as a function of field. However, for e-lifetime reconstruction bias check, please keep e-lifetime constant while varying the other parameters.

Hi Patrick,

Just a last question : Do you have a recommendation for the e-lifetime value we should used?

Should we used the value given in run_sim.sh (i.e. 550 µs), or a mean value of the e-lifetimes I obtained in my note ?

Thanks,
Chloé

I just eyeballed 550 µs from the trend over SR1. So if you have a more precise number for comparing to specific runs, then use that.

You may also compare to the official number contained in each processed file in the pax_metadata under key electron_lifetime_liquid.

Ok thanks !

We just looked at electron lifetime's values used to process February data at different electric fields and, as expected ,they are way lower than Chloé's ones. I guess it comes from the fact that e-lifetime used to processed data is taken from Rn222.

The original issue was on whether fax should include semi-empirical functions for estimating the drift velocity and diffusion constant for different drift fields. I actually think this would be a nice feature for predicting how events will look under different fields. However, if the user enters measured values, they should take precedence.

The sr1_proc_latest_simbranch contains the effective diffusion constant map described here, which accounts for field inhomogeneity. If someone wants to continue development on this, that would be a good starting point.