numericaleft / feynmandiagram.jl Goto Github PK

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

Transformations for tree sanitization:

• prune_unary — Prune trivial unary operations, e.g., $(+a) \rightarrow a$ and $(*a) \equiv (1*a) \rightarrow a$.
• inplace_prod — Propagate subgraph factors up multiplicative chains and merge.
• merge_prefactors — Factorize multiplicative graph prefactors, e.g., $a * G + b * G \rightarrow (a + b) * G$.
• merge_chains — Merge operator chains into a single operation, e.g., $a+(+(\cdots+(+b)\cdots)) \rightarrow a+b$ and $G_1 +(+(\cdots+)+)\; G_2 \rightarrow G_1 + G_2$.
• merge_operators — Use the associativity of an operator $\mathcal{O}$ to "deparenthesize" an expression, i.e., join two sub-operations into a single $n$-ary form. Use with $\mathcal{O} = \bigotimes$ requires Base.:*(g1, g2).
• split_operator — Use the associativity of an operator $\mathcal{O}$ to "parenthesize" an expression, i.e., split the $n$-ary form of a node into two sub-operations. Use with $\mathcal{O} = \bigotimes$ requires 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 $(\mathcal{O} = \bigotimes)$ which does not require Base.:/(g1, g2). Extracts a vertex with ghost legs and its connected propagators into a new $\bigotimes$ node, thereby "unghosting" its legs.
• 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: $(G_1 + G_2) * W \mapsto G_1 * W + G_2 * W$. The recursive depth should be specified by an argument depth which is 1 by default.
• factorize — Factorize a graph expression (the inverse of expand): $G_1 * W + G_2 * W \mapsto (G_1 + G_2) * W$. The recursive depth should be specified by an argument 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.

Definitions/Examples

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.

https://github.com/numericalEFT/FeynmanDiagram.jl/blob/81a7fa415eb90454057662f53d9d1ad613cf7cdb/example/vertex4/ver3_l.jl

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:

1. Loop --> K
2. Tau ---> X

1. In general, the variables of the diagram object could be the combination of the following:

• Momentum
• Frequency
• Pair of space
• Pair of time
  The variables could be internal or external.

2. Generic diagram components:

• Propagator
• Vertex with N legs (note that one vertex may have multiple values, e.g., W has an instantaneous interaction and a retarded one)
• Nodes (a sum/product of propagators and vertices).

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:

• An abstract struct called Pool to host an array of unique objects (could be a variable, a propagator, or a vertex). Implement the pool management operations (add an object, remove an object, find an object, ...)
• Pool struct of the propagators.
• Pool struct of the vertices.
• Diagram tree based on the propagator and vertex pools.
• Diagram tree evaluation.

Frontend

A user-extensible interface to the IR.

• Inline parser (deserializer)
• Serializer (tostring method)
• Batch parser for TOML config file(s)
• Generic support for n-particle reducibility

Intermediate Representation (IR)

A computational tree representation for generic Feynman diagram(s).

Tree operations

• Auto-differentiation (e.g., RG flows)
• Auto-integration (e.g., Matsubara summation for Feynman diagrams and/or general IR trees)

Tree transformations

• Leaf replacement (subdiagram expansion)
• Flattening transformation: reduce tree to n layers
• (Un)distribute transformation: move addition (multiplication) to subdiagram root
• Filtering transformation: diagram removal based on reducibility rules / custom filter
• IR to Feynman diagram representation (special case of flatten + distribute transformation)

Backend

Optimization of IR trees and compilation to expression trees. For optimizations, we can either follow or interface with aesara.

Tree optimizations

• Remove duplicate nodes
• Merge (combine redundant operations)
• GEMM optimization for matrix addition/multiplication
• Support for matrix product states for higher-order vertex functions

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.

• Add the following struct
  struct GraphVector{F, W} <: AbstractVector
  graphs::Vector{Graphs{F, W}}
  end
• Implement vector indexing through julia iterator API
• A function to group the graphs with the same external legs with a given index. For example,

For a GraphVector, gv = GraphVector([g(1, 2), g(1, 3), g(2, 3)]). We expect the following:

1. merge(gv, indices = [1, ]) = [GraphVector([g(1, 2), g(1, 3)]), GraphVector([g(2,3), ])]
2. merge(gv, indices = [2, ]) = [GraphVector([g(1, 2), ]), GraphVector([g(2,3), g(1, 3)])]
3. merge(gv, indices = [1, 2]) = [GraphVector([g(1, 2), ]), GraphVector([g(2,3), ]), GraphVector([g(1, 3), ])]

• construct Feynman diagram from a set of GraphVectors.

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.