lsartore / pyrate Goto Github PK

OS: Fedora Workstation 32, 64 bit. Python 3.8.6

Steps to reproduce:

1. Set up a python3 environment using venv.
2. Install all the listed dependencies using pip.
3. Run [email protected] without arguments -- no error
4. Run ./[email protected] -m models/SM.model -- this results in the output

============================================================================

             PyR@TE version 3.0 released August 4th 2020

       L. Sartore,

       F. Lyonnet, I. Schienbein (version 2)
       and F.Staub, A.Wingerter (version 1)
    Please cite arXiv:2007.12700
    Also, please consider citing 1906.04625 when using the 3-loop results

============================================================================

Loading the YAML file: /home/tst/Projects/pyrate/models/SM.model ... Done.
Loading the model ... Traceback (most recent call last):
  File "./[email protected]", line 63, in <module>
    model = Model(yamlSettings, runSettings, idb)
  File "/home/tst/Projects/pyrate/src/Core/ModelsClass.py", line 61, in __init__
    self.getGaugegroups(settings, realBasis=self.realBasis)
  File "/home/tst/Projects/pyrate/src/Core/ModelsClass.py", line 410, in getGaugegroups
    self.gaugeGroups[gpName] = GaugeGroup(gpName, gp, self.idb)
  File "/home/tst/Projects/pyrate/src/Definitions/GaugeGroup.py", line 24, in __init__
    self.sName = idb.get(self.type, 'name')
  File "/home/tst/Projects/pyrate/src/PyLie/PyLieDB.py", line 530, in get
    ret = self.__getitem__((args, kwargs))
  File "/home/tst/Projects/pyrate/src/PyLie/PyLieDB.py", line 603, in __getitem__
    return self.readBasicInfo(algebra, objType)
  File "/home/tst/Projects/pyrate/src/PyLie/PyLieDB.py", line 685, in readBasicInfo
    return PyLieDB.parse(self.f[algebra.fn][item])
  File "/home/tst/Projects/pyrate/src/PyLie/PyLieDB.py", line 482, in parse
    return PyLieDB.parse(val[()], objType=objType)
  File "/home/tst/Projects/pyrate/src/PyLie/PyLieDB.py", line 496, in parse
    return int(val)
ValueError: invalid literal for int() with base 10: b'A1'

which terminates the computation. The latest version from master is used. Any clues what could go wrong?

cheers,
Tom

Hi Lohan,

I hope you are doing well!
I would like to share an idea for a feature, which however has both possible advantages and drawbacks. I would welcome comments from your side about its merit and feasibility within PyR@TE3 -- I guess this is more a discussion than an issue.

Is it possible to specify fixed gauge indices for fields directly in the model file, by inserting numbers inline?
For instance, one could specify a Yukawa vertex:

Qbar[2,c] H[2] dR[c]

If I am not mistaking, PyR@TE will interpret the 2 as an index to sum over as of the most recent version.

I imagine I should be technically possible to modify this behaviour such that fixed indices are evaluated before the contractions of tensor structures are resolved.

The obvious disadvantage is that it is very easy to violate gauge symmetry with this. I am not sure if and how gauge invariance can be checked if fixed indices are allowed. I would be up to the user to insure that the symmetry is intact, by adding all terms necessary by hand -- similar to ARGES and RGBeta.

The advantage of this would be that some structures could be implemented that are otherwise difficult.
For instance: Take a SU(3) x SU(3) gauge symmetry, with a scalar field in the fundamental representation in both groups. There should be a cubic interaction term, that is just the determinant of this 'matrix scalar'. I have no idea how to implement this other than specifying the indices directly. Or is there another way?

Overall, this is probably an antipattern of specifying a model file. I think in both RGBeta as well as ARGES there is a performance penalty in doing this. However, I am not certain how this impacts PyR@TE, but I suspect the situation is way less severe.

Anyways, let me know what you think, this is certainly not an urgent thing.

cheers,
Tom

The current implementation of the Eps tensor prevents the user to use Levi-Civita tensors of different ranks in a single model file.
For instance, using Eps[i,j] and Eps[a,b,c] in the same model file will generate an error message.

A possible workaround for implementing the rank-3 Levi-Civita tensor independently of e.g. Eps[i,j] consists in using the structure constants of SU(2). For instance, in the Definitions section of the model file, one can write

Definitions: {
    auxEps : t(SU2, 3),
    Eps3[i,j,k] : I * auxEps[i,j,k]
}

to obtain the rank-3 Levi-Civita tensor Eps3. Note that this solution will only work if the option RealBasis : all (default) or RealBasis : adjoint is included in the default.settings file.

Hi,

I am following strictly the manual for introducing the complex triplet model, but I encounter the following parsing error while generating the beta functions. Any suggestions?

Loading the YAML file: /Users/yongdu/Documents/EFT-loop/code/pyrate-2.0.0/pyrate3.0/models/CTHM.model ... Done.

Loading the model ...

Error while parsing the term 'Delta[i,j] : tFund[a,i,j]delta[a]'.

By the way, I also have a question regarding transposing. This is because in the most general case of the potential of the complex triplet model, there is one term goes like $H^T\epsilon\Delta^\dagger H$, where H is the SM Higgs doublet and $\Delta$ is the complex triplet. It seems to me that the transpose operation is currently missing in the definition of pyrate. If true, is there any way to include this term in pyrate?

Thanks and best,
Yong

"ComplexPlot" function in the Mathematica output file conflicts with Mathematica's built-in function "ComplexPlot". This function is newly defined in Mathematica 12. It is an easy fix by changing the function name "ComplexPlot" in "IO/Mathematica.py" into any other ones not conflicted with Mathematica's built-in symbols/function names.

Hi Lohan,

I think I found two typos in the RGEs for the VEV at two loop. I've compared the SM results to SARAH and find discrepancies that vanish in Landau gauge, which would explain why it has evaded your checks. The terms in question are V2_1 and V2_9. If you compare the coefficients to eq. (12c) in [arXiv:1310.7629]{https://arxiv.org/abs/1310.7629} and set ξ'=1 you will find that they should read 35/3 + 3/2*ξ - 3/4*ξ² and -ξ (accounting for the factor 1/2 difference in the definition of Y^2(S)), respectively.