FeynCalc
Replies: 2 comments 9 replies
-
|
Hi, there are two new routines Something like this should work In your calculation the main bottleneck seems to be the tensor reduction. Even though |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much! That's exactly what I was looking for. I will take a look.
Yeah, I agree. I guess there's not much we can do when Mathematica processes the expressions slowly. Thanks for checking this! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Just want to follow up on the previous example, when I try to finish up the whole workflow with ints = Cases2[AmpPart[7], GLI];
topos = toposFinal;
FolderName = "TestKIRA"
WorkingDirectory = FileNameJoin[NotebookDirectory[], FolderName];
KiraCreateJobFile[topos, ints, WorkingDirectory];
KiraCreateIntegralFile[ints, topos, WorkingDirectory];
KiraCreateConfigFiles[topos, ints, WorkingDirectory,
KiraMassDimensions -> {s -> 2, t -> 2, mc -> 1, qcap -> 1}];
(*Below are my own KIRA and FERMAT path*)
KiraRunReduction[WorkingDirectory, topos,
KiraBinaryPath ->
FileNameJoin[{$HomeDirectory, "bin", "local", "kira", "bin", "kira"}],
KiraFermatPath ->
FileNameJoin[{$HomeDirectory, "bin", "Ferl7", "fer64"}]]I got all false from This is somewhat surprising and confusing to me and when I also tested this new routine with the quark case which was fine with the previous routine without the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, first of all, you absolutely shouldn't run Kira via Mathematica with In real life this is rarely the case, so you need to see what happens during the run and understand possible error messages.
As you see, this is not a meaningful problem description. The only way to understand why it doesn't work is to run Kira directly. |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
Thanks, that great point. I will try working directly with KIRA then. The
Indeed, it wasn't meant to be. I didn't fully realize that |
Beta Was this translation helpful? Give feedback.
-
Hi, after some digging into the KIRA files, I infer that this might be a Thus, when I run KIRA on the 4-leg topologies, it finds a problem with the 'b001' that
whereas on the 3-leg topologies, it has the same problem with 'b0001'. After manually deleting the 3-leg config in the 4-leg topologies and 4-leg config in the 3-leg topologies in the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for investigating. This looks really weird, because normally Could you please provide the lists of |
Beta Was this translation helpful? Give feedback.
-
Oh, apologies for saying it unclearly. I could imagine that each topology was treated separately. But I suppose feeding the same set of GLIs to each of them is the problem (which generates the GLItest = {GLI["fcPFRTopology1", {-2, 1, 1, 1}],
GLI["fcPFRTopology13", {-1, 1, 1}]}
TopoTest = {FCTopology[
"fcPFRTopology1", {FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k, D], 0, 0, {1, 1}]],
FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k + q1, D], 0, 0, {1, 1}]],
FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k - p2 + q1 - 2*q2, D], 0,
0, {1, 1}]],
FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k - p2 + q1 - q2, D],
0, -mc^2, {1, 1}]]}, {k}, {p2, q1, q2}, {}, {}],
FCTopology[
"fcPFRTopology13", {FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k + p2, D], 0, 0, {1, 1}]],
FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k - 2*q2, D], 0, 0, {1, 1}]],
FeynAmpDenominator[
StandardPropagatorDenominator[Momentum[k - q2, D],
0, -mc^2, {1, 1}]]}, {k}, {p2, q2}, {}, {}]}and run the which for both topologies generates the job.yaml file like: The following patch selecting the GLIs for each topology seems to avoid the issue so I suspect it's from the mixed GLIs: Below are the local package versions:
Thanks a lot the investigating this and have a nice weekend~! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Yeah, I could confirm that the latest dev version of FeynHelpers now works well. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
Just a beginner trying to understand the routine of using the GLIs approach of FeynCalc. Based on the provided examples and documentations that I really appreciate, I start with the following routine before I feed all the GLIs in ampPreFinal to KIRA:
where AmpInit is just some FCFAConvert-generated amplitudes. This works flawlessly with some examples on the web that I tested and other simple calculations where I port KIRA with FeynHelpers etc. after this. But once I got into a more complicated one, I run into problem that in the last step of applying FCLoopApplyTopologyMappings with follow messages appear:
I read in the documentation of FCLoopFindTopologies that "Each of the identified topologies … but may lack propagators needed to form a complete basis", but it doesn't guide me to a specific solution when a complete basis is not formed. I imagine that I might need to augment the basis with, e.g., FCLoopAugmentTopology, but it doesn't seem obvious, e.g., if and how the necessity of adding auxiliary vectors like n and p emerges.
I am not sure if I am missing something obvious here, like a one- or two-line command that could fix this. Any directions are appreciated!
Also, this problem only appears in some complicated problems, not simple ones, so there won't be a "minimal" working example, but I did encounter the problem with the following set-up for photo-productions of ccbar off gluon. Running through it might take about 20 minutes when parallelized on a 10-core CPU:
The issue persists after removing kinematics part, though it will be slower then.
Swapping out the gluon (V[5]) in the initial and final states with quark (F[3,{1}]), the issue is gone:
Beta Was this translation helpful? Give feedback.
All reactions