Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need e-field dependence in fax #585

Open
pdeperio opened this issue Jun 18, 2017 · 15 comments
Open

Need e-field dependence in fax #585

pdeperio opened this issue Jun 18, 2017 · 15 comments

Comments

@pdeperio
Copy link
Contributor

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!

@pdeperio
Copy link
Contributor Author

On Jun 18, 2017, at 1:08 PM, @l-althueser Lutz Althüser [email protected] 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?

@pdeperio
Copy link
Contributor Author

pdeperio commented Jun 18, 2017

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"

@pdeperio pdeperio changed the title Need e-field dependence of drift velocity in fax Need e-field dependence in fax Jun 18, 2017
@pdeperio
Copy link
Contributor Author

@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.

@JelleAalbers
Copy link
Contributor

JelleAalbers commented Jun 18, 2017

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

@pdeperio
Copy link
Contributor Author

pdeperio commented Jun 18, 2017

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.

@sdiglio
Copy link

sdiglio commented Jun 19, 2017

@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.

@jMasbou
Copy link

jMasbou commented Jun 21, 2017

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é

@jMasbou
Copy link

jMasbou commented Aug 7, 2017

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é

@pdeperio
Copy link
Contributor Author

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.

@jMasbou
Copy link

jMasbou commented Aug 10, 2017

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é

@pdeperio
Copy link
Contributor Author

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.

@jMasbou
Copy link

jMasbou commented Aug 10, 2017

Ok thanks !

@sdiglio
Copy link

sdiglio commented Aug 10, 2017

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.

@JelleAalbers
Copy link
Contributor

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.

@JelleAalbers
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants