numericaleft / feynmandiagram.jl Goto Github PK
View Code? Open in Web Editor NEWComputational graph representation of multiloop Feynman diagrams
Home Page: https://numericaleft.github.io/FeynmanDiagram.jl/
License: MIT License
Computational graph representation of multiloop Feynman diagrams
Home Page: https://numericaleft.github.io/FeynmanDiagram.jl/
License: MIT License
The current implementation of DiagramID duplicates with DIagPara.type.
DiagramID should have larger scope than DiagPara.type. To be more specific,
DiagPara.type --> Ver4, Ver3, Green, Interaction, Sigma, ...
DiagramID --> N-body Vertex/Green/connected-Green in momentum-time representation, spacetime-representation, ...
So it is probably better to call it Representation. An example is the following,
#generic Veretx function in KX representation
struct VerKX
para::DiagPara #DiagPara don't need weightType
spin::Vector{Int} #[Up, Up], [Up, Down], ...
channel::Channel # particle-hole, particle-hole exchange, particle-particle, irreducible, and their counterterms
extK::Vector{Vector{Float64}}
extT::Vector{Int}
order::Vector{Int} #[2, 0, 1] means loop-order 2, and one derivative of the second type.
end
it should come with some help functions (for example, a function to check if the vertex is instant or not).
The Diagram struct should be defined as,
struct Diagram{W, ID<:DiagramId}
hash::Int
name::Symbol
id::ID
operator::Operator
factor::W
subdiagram::Vector{Diagram{W, ID}}
weight::W
Need some help functions (for example, isbare(diag) = (length(diag.subdiagram)==0))
in the Feynman rule docs, https://numericaleft.github.io/FeynmanDiagram.jl/dev/manual/feynman_rule/, we are currently using G^{-1}=g^{-1}+\Sigma. However, in many books, it should be G^{-1}=g^{-1}-\Sigma in books.
This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml
to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix
on this issue.
I'll open a PR within a few hours, please be patient!
implement a function to generate a feynman_diagram from a vector of graphs with the following signature.
function feynman_diagram(vertices::Vector{Graph}, topology::Vector{Vector{Int}};
external=[], factor=one(_dtype.factor), weight=zero(_dtype.weight), name="", type=:generic)
Implement a struct QuantumOperator for creation/annihilation operators. Further use this struct to define composite operators and operator pairings via an algebra for QuantumOperator instances.
The aims are (1) to rigorously define generic internal/external vertices and (2) to support derivation of ExternalVertex types for a diagram given user-supplied Feynman rules (a list of valid internal vertices for the problem).
[ ] relabel(g::Graph, map::DIct{Int, Int}):
this function maps the labels of the quantum operators in g and its subgraphs to other labels. For example, map = {1=>2, 3=>2} will find all quantum operators with labels 1 and 3, and then map them to 2.
[ ] standarize_labels(g::Graph):
this function first finds all labels involved in g and its subgraphs (for example, 1, 4, 5, 7, ...), then relabel them in the order 1, 2, 3, 4, ....
Write unit tests and functions for essential tree transformations in the intermediate (computational graph) representation:
Transformations for tree sanitization:
prune_unary
— Prune trivial unary operations, e.g., inplace_prod
— Propagate subgraph factors up multiplicative chains and merge.merge_prefactors
— Factorize multiplicative graph prefactors, e.g., merge_chains
— Merge operator chains into a single operation, e.g., merge_operators
— Use the associativity of an operator Base.:*(g1, g2)
.split_operator
— Use the associativity of an operator Base.:/(g1, g2)
.High-priority transformations for the Parquet front-end:
relabel
— Update the label(s) of quantum operators in a graph and its subgraphs, e.g., {{1,2}=>3, 3=>4}.standarize_labels
— Finds all labels in a graph and its subgraphs (e.g., 1,4,5,7...) and then relabels them in standard order 1,2,3,4,...unghost_legs
— A special case of split_operator
for graph decomposition Base.:/(g1, g2)
. Extracts a vertex with ghost legs and its connected propagators into a new replace_subgraph
— Replace one subgraph of a graph g with another one of possibly different topology.Low-priority transformations requiring associative graph (de)composition to be defined via Base.:*(g1, g2)
and Base.:/(g1, g2)
:
expand
— Expand a factorized graph expression: depth
which is 1 by default.factorize
— Factorize a graph expression (the inverse of expand
): depth
which is 1 by default. Requires Base.:/(g1, g2)
.tofeynmanrep
— Convert a general graph to the Feynman representation by chaining expand
and merge_chains
.fromfeynmanrep
— Optimize a graph in the Feynman representation by chaining factorize
and merge_chains
.using ElectronLiquid, FeynmanDiagram
para = UEG.ParaMC(rs=0.5, beta=25.0, Fs=-0.0, order=4, mass2=3.0, isDynamic=false, dim=2);
diagram = Ver4.diagram(para, [(3,0,0)]; channel=[PHr, PHEr, PPr], filter=[NoHartree, Proper])
ERROR: DimensionMismatch: dimensions must match: a has dims (Base.OneTo(5),), b has dims (Base.OneTo(16),), mismatch at 1
Many transformations in transform.jl
and related optimizations in optimize.jl
apply only to expression trees, i.e., they assume each node has only one parent. Functions relabel / relabel!
and standardize_labels / standardize_labels!
are already sufficiently general. All other functions must be corrected to support generic computational graphs, which may include nodes with multiple parents.
The one-loop vertex3 calculated from the following source code gives F = -0.5123(18). Since z factor is expected to be 0.662, so that we expect F = 1/z-1=0.51057. It indicates an additional sign is needed for the fermionic vertex correction.
In the src/diagramBuilder/fromFile, add code to compile the user-defined Feynman diagram into a diagram tree.
The diagram file could be generated from the external package or manually created by the user. The code reads the file and compiles it into a diagram tree.
After I visualized the computational graph through the compile_dot
function, by inspecting the simplest graph (1,0,0) for GV and parquet algorithm, I found some optimizations don't work. As the graph show below:
For the parquet graph:
It's obvious to see that there are still trivial unary chains,
The same situation happen for the GV graph
The reason may be that the factor of some nodes is not 1
.
Some suggestions:
Note that when evaluating a node, one may need to evaluate an additional weight factor based on the property of a node.
One may implement the above codes in the following roadmap:
A user-extensible interface to the IR.
A computational tree representation for generic Feynman diagram(s).
Optimization of IR trees and compilation to expression trees. For optimizations, we can either follow or interface with aesara.
Implement a data structure to handle vector graphs:
NOTE: All graphs in the vector should have the same number of external legs, but the labels of the external legs can be different.
For a GraphVector, gv = GraphVector([g(1, 2), g(1, 3), g(2, 3)]). We expect the following:
function feynman_diagram(vertices::Vector{GraphVector}, topology::Vector{Vector{Int}};
external=[], factor=one(_dtype.factor), weight=zero(_dtype.weight), name="", type=:generic)
In the naive algorithm, the entire diagram tree is recalculated. In a more advanced algorithm, one should only evaluate part of the tree in each MC update.
I found that the function merge_prefactor
(in #58) has to confronted the different cases below and it seems a little messy, for g=propagator(𝑓⁺(1)𝑓⁻(2), factor=1)
:
(a)k1=(1*g+2*g)
(b)k2= linear_combination(g,g,1,2)
The structures of them are different:
(1) For k1
:
(2) For k2
:
I suggest these two cases should be unified to the second one in the Base.+
function.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.