Hi Franz, On Tue, Sep 3, 2013 at 4:02 PM, F. B. <[email protected]> wrote: > I've been asked by Certik to transfer the discussion about the possible > tensor module improvements to this mailing list (instead of github's). The > tensor module is, in my opinion, essential to Quantum Field Theory, > especially if we want to implement an interface to represent any formula of > a QFT textbook inside SymPy.
Yes, we definitely do. In fact, I would love to have a module, that can plot Feynman diagrams in the ipython notebook, that can generate them for the given Lagrangian, that can infer Feynman rules, that can handle QED rules, generate the corresponding expression, do the integrals (e.g. we'll also need regularization and renormalization), simplify the gamma matrices etc etc. For others, here is Franz's PR that implements the gamma matrices simplification and that started this discussion: https://github.com/sympy/sympy/pull/2416 > > I continue this discussion, as I believe that most of its concepts should be > implemented inside the tensor module. > > A brief overview of the tensor module: > > TensorIndexType class, specifies a class of indices (like spinor, lorentz, > qcd_charge, ...) > TensorHead class, to represent a tensor without its indices. > TensMul, TensAdd (TensExpr) to represent expressions of TensorHead with > indices. > some other classes. > > The tensor module is wonderful code, but it has two main problems, as of > now: > > it uses two representations of tensor indices: the visual one (indices with > a + or - sign according to their contravariantness/covariantness), and an > internal representation as lists (this is useful in algorithms, but really > bad to read for a human being). I suggested to split the aforementioned > tensor classes, in order to avoid that code handling the visual index > representation and the internal index representation gets messed up. Here is > my PR: https://github.com/sympy/sympy/pull/2338 > The tensor module does not pass the test_args test, so TensExpr may behave > queerly upon ordinary SymPy actions like .subs( ), .xreplace( ), srepr( ), > .args > This is a serious problem, because if we are to write algorithms performing > QFT tasks on tensors, we have to be able to extract subexpressions of > specific types of tensors. For example, gamma matrix reduction algorithm > should work only on gamma matrix objects inside a tensor expression, not on > (say) light polarization vectors. > To solve this point, I think it's better to first finish point (1), so the > tensor code will be far more clear and readable. > Redundancy: TensorHead requires TensorIndex objects when costructing a > TensMul, but TensorIndex objects are just a TensorIndexType and a string, > and TensorHead already knows which types are supposed to be in which > positions, so an ordinary Symbol could be used in step of a TensorIndex. > Find a way to represent numeric indices. What you write makes sense to me. I would say that the two big applications of the tensor module is differential geometry (general relativity) with things like Riemann tensor, and quantum field theory (on flat background). There are of course many more applications, but these two are probably the main ones. And so it should work really well for these two. If it doesn't, we need to improve it. > > Gamma matrices > > Gamma matrices are a (Lorentz, Spinor, Spinor) type tensor, usually the > two-spinor indices are meant as a matrix multiplication, so they can be > viewed as (Lorentz) tensors. In my opinion a possible gamma matrix object > has to inherit TensorHead and allow both (Lorentz, Spinor, Spinor) and > (Lorentz) representations. In the latter case, spinor indices should be > automatically managed inside expressions containing more than one gamma > matrix with (Lorentz) signature. I am still not very sure on how to proceed > here, especially as there are more urgent issues, but over the time I'll > think how exactly do this. > > Gamma matrices are very important objects in QFT, I have identified two > efficient algorithms to simplify expressions of gamma matrices with > contracted Lorentz-indices: > > Kahane's algorithm, already merged into master > (sympy/physics/hep/gamma_matrices.py), the fastest one, allows reducing > expressions of gamma matrices in 4 dimensions. > Kennedy-Cvitanovic algorithm, slower than Kahane's, but acts independently > of dimension (can be used with dimensional regularization and in 2^n > dimensional gamma matrix Clifford algebra). It basically uses the Fierz > identity to break internal Lorentz lines (i.e. index contractions) in gamma > matrix expressions, then cleans everything up using the completeness > relation of Dirac's Clifford algebra. > > Once both algorithms are implemented, a simplify( ) and a trace( ) call on > the TensExpr should use Kahane's algorithm on 4 dimensions, otherwise drop > on KC. Right. Here is another idea, but maybe it does not work for some reason. Why cannot we represent the gamma matrices as 4x4 symbolic matrices? Then the whole expression is just matrix multiplication and at the end you end up with a 4x4 symbolic matrix (with possibly complicated entries). This means that intermediate expressions will necessarily be complex/unreadable. But the end expression which typically involves a trace might be ok. Though I am aware that many times you end up with contracted vectors like momentum, and we might get a messy formula instead. > > It would be nice to be able to use simplify( ) and trace( ) and a TensExpr, > and have these actions propagate on specific objects, so as to trigger the > proper algorithms. TensExpr has therefore to implement _eval_simplify( ) and > _eval_trace( ), and create a mechanism to propagate this on subexpressions > (remember: gamma matrices must stay in the physics module, the tensor module > must not know anything about that, it is a deeper abstraction layer in this > API, therefore its triggering mechanism has to be generic, not specific for > gamma matrices). Yes. > > Later work > > Sorry for stressing much on gamma matrices, but it is a first step towards a > more general API for QFT. I would start with them. I would start with them too ---- it would be very very useful. > > In any case, some possibilities for a later work include: > > mixed operators and tensors. > partial derivative of tensors, indexed derivatives. Yes. > > > What should be done now > > Make the tensor module SymPy-compliant, and have the test_args work. If this > step is not completed, it is hard to create algorithms to handle expressions > of mixed tensor types. It sounds good to me. Do you know how to get it done, or did you get stuck at some issue in your PR? Btw, I am thinking of contributing my code generation / contraction of scalar diagrams. I was hesitant, because it doesn't use much of sympy and there is danger of having bunch of non-interoperable modules. But the advantage is that at least we can have something, while necessarily specialized, it can still be used later for this specialized case. I also have code for generating diagrams/expressions for non-relativistic perturbation theory (e.g. just Schroedinger equation). It's much simpler than QFT. It might be useful to provide nice interface to the ipython notebook. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
