Obsolete or duplicated gas definitions

CMargalejo · August 9, 2021, 11:08am

Revising the gases available at https://sultan.unizar.es/gasFiles/gases.rml I have seen that there are some very similar definitions and I am not sure if they are all complety valid. For example, for Ar+5%isobutane there are 3 definitions:

// ----- 5.0% ---------------------------------------------------------------------------------------------
<TRestDetectorGas name="Argon-Isobutane 5Pct 10-10E3Vcm" title="Argon-Isobutane Mixture (5Pct Isobutane)">
<parameter name="pressure" value="1"/>
<parameter name="temperature" value="293.15"/>
<parameter name="maxElectronEnergy" value="400"/>
<parameter name="W_value" value="26.145"/>
<parameter name="nCollisions" value="10"/>
<eField Emin="10" Emax="1000." nodes="20"/>
<gasComponent name="ar" fraction="0.95"/>
<gasComponent name="iC4H10" fraction="0.05"/>
</TRestDetectorGas>

 //------- User : jgalan ---- REST version : 2.2.7 ---------------------------
<TRestDetectorGas name="Argon-Isobutane 5Pct 10-10E3Vcm ACC" title="Argon-Isobutane Mixture (5Pct Isobutane)">
<parameter name="pressure" value="1"/>
<parameter name="temperature" value="293.15"/>
<parameter name="maxElectronEnergy" value="800"/>
<parameter name="W_value" value="26.145"/>
<parameter name="nCollisions" value="10"/>
<eField Emin="10" Emax="1000" nodes="20"/>
<gasComponent name="ar" fraction="0.95"/>
<gasComponent name="iC4H10" fraction="0.05"/>
</TRestDetectorGas>

//------- User : jgalan ---- REST version : 2.3.4 ---------------------------
<TRestDetectorGas name="Argon-Isobutane 5Pct 0.1-10E3Vcm" title="Argon-Isobutane Mixture (5Pct Isobutane)">
<parameter name="pressure" value="1"/>
<parameter name="temperature" value="293.15"/>
<parameter name="maxElectronEnergy" value="800"/>
<parameter name="W_value" value="21.965"/>
<parameter name="nCollisions" value="10"/>
<eField Emin="0.1" Emax="1000" nodes="20"/>
<gasComponent name="ar" fraction="0.95"/>
<gasComponent name="iC4H10" fraction="0.05"/>
</TRestDetectorGas>

Among the first and the second, only maxElectronEnergy changes, but in the third one the W-value and the electric field range also change.

I have seen this is happening with other gas mixtures too, I just put this one as an example.

I also think the W-value is not correct in many cases, as 21.9 eV is a value that appears many times and it correspondes precisely to the one used in the dummy gas (which by the way is the value for pure Xe). I am not sure how much this value can effect the analysis, but I think it’s worth revising it.

There is a table in the PDG where one can obtain these values at https://pdg.lbl.gov/2019/reviews/rpp2019-rev-particle-detectors-accel.pdf, that I think could be used to revise these values:

To calculate, e.g., the W-value of 95%Xe+5%isobutane, would it be just 220.95 + 260.05 = 22.2 eV?

What do you think? Should we revise this?

jgalan · August 9, 2021, 12:06pm

Hi Cristina,

yes, these are good observations.

The 3 definitions you mention, are in principle the same gas mixture, but each new version improves something, as you say in version 1 is with maxElectronEnergy=400, in version 2 with maxElectronEnergy=800, and in the third version v2.3.4 the range of validity of the electric field is increased from 0.1V/cm/bar to 1000V/cm/bar. It is important to know that this range is normalized using bar, so to get the range of validity in V/cm you have to multiply by the gas pressure to get the range in V/cm. That is, at 10 bar the valid range for that gas will be between 1V/cm and 10kV/cm. You can request the value of the gas parameters outside that range, but the values will be meaningless (or wrong).

The fact that this is so is that gases.rml is always cumulative (you can add but not remove, in principle), the name of each gas is always different, and you can use all 3 interchangeably. So someone interested in using one of these gases has to see which one he/she is more interested in. Here it is clear that it is the one in v2.3.4. The other gases can be for testing purposes, i.e. to see how it affects the maxElectronEnergy, for example.

If this creates confusion we could always adopt the policy of cleaning up and deleting the “obsolete” gases.

======

For the Wvalue issue, it is true that many of those values are not correct. The ideal would be that in the gas generation with Magboltz the values are calculated inside the simulation and we get a simulated value. But at present this is done manually and is much more affected by “human error” or “human laziness”.

The important thing (for us) in this case (although ideally there should be a way that does not lead to sources of error) is to identify how these values are used within the framework. For this I can see that in TRestDetectorGas and TRestDetectorDriftVolume define methods that extract this value W. And I can take a look and see where they are used.

So, if I run the following:

jgalan@sultan:~/rest-framework/source/libraries/detector$ cd
jgalan@sultan:~$ cd rest-framework/source/libraries
jgalan@sultan:~/rest-framework/source/libraries$ grep -rnw . -e "GetWvalue"
./detector/inc/TRestDetectorDriftVolume.h:67: virtual Double_t GetWvalue() { return fW; }
./detector/src/TRestDetectorTriggerAnalysisProcess.cxx:66: fW = gas->GetWvalue();
./detector/src/TRestDetectorGas.cxx:352: fGasMedium->SetW(GetWvalue());
./detector/src/TRestDetectorElectronDiffusionProcess.cxx:99: if (fWvalue <= 0) fWvalue = fGas->GetWvalue();
./detector/src/TRestDetectorAvalancheProcess.cxx:100: Double_t fW = fGas->GetWvalue();
jgalan@sultan:~/rest-framework/source/libraries$

I see that the method is being called in TRestDetectorElectronDiffusionProcess and in TRestDetectorAvalancheProcess.

I have used mostly TRestDetectorElectronDiffusionProcess and I know well that the value of W is not going to affect the result of this process. Moreover, the process itself allows to define the value of W, and even, if one limits the number of electrons to be produced in the process to, for example, to 10000 electrons, then the value of W will be truncated so that the diffusion is “simulated” with 10000 electrons maximum. Ideally, a small MonteCarlo should be made and the number of electrons in this process should be taken. Anyway, the number of electrons is not important here, just that it is statistically significant, but it does not need to be exact.

For the TRestDetectorAvalancheProcess that I have not used, I am not sure, but I think it will be something similar to what I commented in TRestDetectorElectronXX.

Of course it would be best if those values acquired the correct value of W, so that one would have more confidence in what one is using. That would be the most appropriate. And the calculation you mention seems to be correct. Ideally W would be a value generated internally within TRestDetectorGas by accessing the table you mention.

As it is now, our only choice is to modify/correct those values by hand at gases.rml.

Although according to the above, ideally we would not have to specify it in the RML, the value of W would be calculated through the table you mention, and stored directly inside the TRestDetectorGas structure.

I created an issue to follow this problem.

github.com/rest-for-physics/detectorlib

Implement W gas parameter inside TRestDetectorGas directly at the time of gas file generation

opened 12:05PM - 09 Aug 21 UTC

jgalan

This issue is connected with the following discussion at the forum http://res…t-forum.unizar.es/t/obsolete-or-duplicated-gas-definitions/508 Ideally we would fix the value of W (average ionization potential of the molecules inside the gas mixture) at the time of gas generation. Actually this value is given at the RML, and many values at the server https://sultan.unizar.es/gasFiles/gases.rml contain wrong values. Therefore, the best would be that we do not define manually `W` at the RML, but its value is calculated and registered directly at the associated `TRestDetectorGas` metadata member. The calculation could be done for example using the table proposed at the forum by @cmargalejo https://pdg.lbl.gov/2019/reviews/rpp2019-rev-particle-detectors-accel.pdf ![image-2](https://user-images.githubusercontent.com/12447509/128703589-01c61d34-d241-4fd2-a4a5-8cecd72e63b2.png)

CMargalejo · August 9, 2021, 2:56pm

The gas generation is like a black box to me… Does the W-value we write in the RML affect the gas generation by Magboltz? Or could we completly remove that line to generate the gas? If the output from Magboltz is affected by the W-value we input, then even if the W-value is only used by 2 processes within the framework, it might be affecting the gases stored in the database and thus the values we extract form them (e.g. diffusion coefficients, drift velocity…), no?

jgalan · August 9, 2021, 3:11pm

No, the W-value has no effect at all on gas generation. It is just a passive metadata member value that is registered in the class.

All the gas generation takes place at the method TRestDetectorGas::CalcGarfield( ... ), where the Garfield method fGasMedium->GenerateGasTable(fNCollisions, true); is called. There you see the parameters that play a role on the definition of the Garfield object fGasMedium.

    if (fNofGases == 1) fGasMedium->SetComposition(gasStr[0], fGasComponentFraction[0] * 100.);
    
    if (fNofGases == 2)
        fGasMedium->SetComposition(gasStr[0], fGasComponentFraction[0] * 100., gasStr[1],
                                   fGasComponentFraction[1] * 100.);
    
    if (fNofGases == 3)
        fGasMedium->SetComposition(gasStr[0], fGasComponentFraction[0] * 100., gasStr[1],
                                   fGasComponentFraction[1] * 100., gasStr[2],
                                   fGasComponentFraction[2] * 100.);
        
+---  5 lines: if (fNofGases > 3) {-----------------------------------------------------------------------------------------------
                                   
    fGasMedium->SetTemperature(fTemperatureInK);

    if (fPressureInAtm != 1)
        warning << "-- Warning : The gas will be generated for gas pressure = 1atm" << endl;

    fGasMedium->SetPressure(1 * REST_Units::torr);
        
    fGasMedium->SetFieldGrid(Emin, Emax, n, n > 1);
    
    fGasMedium->SetMaxElectronEnergy(fMaxElectronEnergy);

No W value is used there, on the gas generation.

jgalan · August 9, 2021, 3:14pm

I believe @nkx did a try to retrieve the W value from gas file.

// This was just a test to try to Get the calculated W for the gas definition.
// However, I tested with Xe+TMA and I got an error message that TMA
// photoncrossection database is not available
void TRestDetectorGas::GetGasWorkFunction() {

However, doing it manually using an ASCII tables with the known “theoretical” values would be also a good approach, I imagine.

nkx · August 10, 2021, 1:43am

I don’t remember that I tried to retrieve W-value from garfield simulation. However, I tested TRestDetectorGas::GetGasWorkFunction() with the thrid gas and the printed w-value looks good

(The lines of fGasMedium->SetW(fW) in TRestGax.cxx should be removed in order to do this test)