Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Broken topologies_ #474

Open
Tracked by #475
tueda opened this issue Feb 23, 2024 · 6 comments · May be fixed by #604
Open
Tracked by #475

Broken topologies_ #474

tueda opened this issue Feb 23, 2024 · 6 comments · May be fixed by #604
Labels
bug Something isn't working

Comments

@tueda
Copy link
Collaborator

tueda commented Feb 23, 2024

The 5.0.0-beta reference manual says

In version 4.3 there existed also the topologies_ and the phi_ functions to just generate topologies. This was before a complete implementation was made. For backward compatibility we have kept these functions, ...

but this is not the case and the test cases Diagrams_1, ..., Diagrams_4 in check/example.frm fail. For example, Diagrams_1 is

Vectors Q1,Q2,p1,...,p8;
Set QQ:Q1,Q2;
Set PP:p1,...,p8;
#define LOOPS "2"
Local F = topologies_(`LOOPS',2,{3,},QQ,PP);
Print +f +s;
.end

and should give, as in the manual,

   F =
       + node_(0,-Q1)*node_(1,-Q2)*node_(2,Q1,-p1,-p2)*node_(3,Q2,p1,-p3)*
      node_(4,p2,-p4,-p5)*node_(5,p3,p4,p5)
       + node_(0,-Q1)*node_(1,-Q2)*node_(2,Q1,-p1,-p2)*node_(3,p1,-p3,-p4)*
      node_(4,p2,p3,-p5)*node_(5,Q2,p4,p5)
      ;

but it suffers from memory bugs:

==465138== Conditional jump or move depends on uninitialised value(s)
==465138==    at 0x142CDF: ProcessTopology(EGraph*, void*) (diawrap.cc:537)
==465138==    by 0x174419: MGraph::newGraph(MNodeClass*) (grcc.cc:4883)
==465138==    by 0x174575: MGraph::connectClass(MNodeClass*) (grcc.cc:4524)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x174B3D: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4715)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1745A7: MGraph::connectClass(MNodeClass*) (grcc.cc:4528)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==
==465138== Use of uninitialised value of size 8
==465138==    at 0x142D2C: ProcessTopology(EGraph*, void*) (diawrap.cc:543)
==465138==    by 0x174419: MGraph::newGraph(MNodeClass*) (grcc.cc:4883)
==465138==    by 0x174575: MGraph::connectClass(MNodeClass*) (grcc.cc:4524)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x174B3D: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4715)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1745A7: MGraph::connectClass(MNodeClass*) (grcc.cc:4528)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==
==465138== Invalid read of size 4
==465138==    at 0x142D30: ProcessTopology(EGraph*, void*) (diawrap.cc:543)
==465138==    by 0x174419: MGraph::newGraph(MNodeClass*) (grcc.cc:4883)
==465138==    by 0x174575: MGraph::connectClass(MNodeClass*) (grcc.cc:4524)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==    by 0x174B3D: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4715)
==465138==    by 0x17475E: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4552)
==465138==    by 0x1745A7: MGraph::connectClass(MNodeClass*) (grcc.cc:4528)
==465138==    by 0x17476B: MGraph::connectNode(int, int, MNodeClass*) (grcc.cc:4543)
==465138==    by 0x1747F8: MGraph::connectLeg(int, int, int, int, MNodeClass*) (grcc.cc:4591)
==465138==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==465138==
@tueda tueda added the bug Something isn't working label Feb 23, 2024
@tueda tueda mentioned this issue Feb 23, 2024
Open
1 task
@jodavies
Copy link
Collaborator

jodavies commented Mar 4, 2024

jodavies@b356d5f

This sorts out the valgrind error, but that is not the cause of the test errors.

To me that looks like a change of convention (adding topo_ functions for enumeration) but also a bug: I would not expect the factor of 1/4.

@jodavies
Copy link
Collaborator

jodavies commented Mar 4, 2024

To remove the coefficients, you only need to comment out the symmetry factor code at the end of ProcessTopology. Probably this was just a copy-and-paste from ProcessDiagram and this bit was not removed. Commenting the "Topology counter" lines removes the topo_ tags (but here someone needs to decide if this should stay, and lose true backward compatibility with 4.3.1).

Then the only difference with the test output I think, is the node numbers start at 1 instead of 0.

@jodavies
Copy link
Collaborator

jodavies commented Mar 4, 2024

Diagrams_3 fails for a different reason. There it crashes in the print routine because it gets bad input:

#0  0x0000555555591c89 in FindVector (num=800000213) at dict.c:293
#1  0x0000555555668ac7 in WriteArgument (t=t@entry=0x7fffede60130) at sch.c:1485
#2  0x000055555566b309 in WriteSubTerm (sterm=sterm@entry=0x7fffede6010c, first=<optimised out>, first@entry=0) at sch.c:1941
#3  0x000055555566b7c6 in WriteInnerTerm (term=<optimised out>, first=0) at sch.c:2130

In the failing term, there is a -10 (MINVECTOR) followed by 3, so FindVector tries to access the names array at 3-AM.OffsetVector which is 800000213.

@jodavies
Copy link
Collaborator

jodavies commented Mar 6, 2024

Diagrams_3 fails for a different reason. There it crashes in the print routine because it gets bad input:

#0  0x0000555555591c89 in FindVector (num=800000213) at dict.c:293
#1  0x0000555555668ac7 in WriteArgument (t=t@entry=0x7fffede60130) at sch.c:1485
#2  0x000055555566b309 in WriteSubTerm (sterm=sterm@entry=0x7fffede6010c, first=<optimised out>, first@entry=0) at sch.c:1941
#3  0x000055555566b7c6 in WriteInnerTerm (term=<optimised out>, first=0) at sch.c:2130

In the failing term, there is a -10 (MINVECTOR) followed by 3, so FindVector tries to access the names array at 3-AM.OffsetVector which is 800000213.

The problem here is that not enough external vectors are defined. Here

form/sources/diawrap.cc

Line 568 in 9637b9a

*fill++ = SetElements[Sets[info->internalset].first+(vect-info->numextern)];

it tries to access (for "Diagrams_3") the 9th element (at index 8) of the set, which only has 8 elements. So it lands on the "3" of the implicitly declared {3,4} set (if you swap this to {4,3} you get 4 back).

So somewhere needs to be a proper check of the number of internal lines, against the size of the set.

But the more major issue is that the number of topologies returned doesn't agree with the manual. There it claims there should be 9 topologies (or 8 in the case of external line symmetry). Now we get 6 in both cases.

@jodavies
Copy link
Collaborator

Even if the plan is to now remove the topologies_ function, we still need a good set of tests for diagrams_. To that end I started with something simple: comparing the number of diagrams generated by qgraf and FORM for a simple phi3 model. Already for a 1-loop propagator, there is a difference that I don't understand: qgraf generates two diagrams with its "default" options: the 1l propagator, and a tadpole. FORM does not generate the tadpole, though I do not specify NoTadpoles_.

If I tell both qgraf and form not to generate tadpoles, then the diagram counts agree.

@tueda tueda linked a pull request Dec 27, 2024 that will close this issue
Draft
@tueda
Copy link
Collaborator Author

tueda commented Feb 1, 2025 •
edited
Loading

Even if the plan is to now remove the topologies_ function, we still need a good set of tests for diagrams_.

In the test-qgraf branch, I have started creating tests for diagram generation with QGRAF, which can be run by:

check/check.rb build/sources/tform -C qgraf

or, without the check script:

build/sources/tform -I check/qgraf -D TEST=qgraf_qcd_quaqua1 qgraf.frm

You can also try nontrivial examples like

#include - qgraf.frm # qgraf_include
#call SetupPhi3Model()
#call DoComparison(in=phi,phi,out=phi,phi,loops=3,form_options=`ONEPI_',qgraf_options=onepi,nosnail)

This generates 3 expressions:

  • F0: common diagrams generated by FORM and QGRAF.
  • F1: diagrams generated only by FORM.
  • F2: diagrams generated only by QGRAF.

Note that the current version of the diagram generator always sets GRCC_OPT_NoSelfLoop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix the topology_ function tueda/form
2 participants
@tueda @jodavies