[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: Axiom + High Energy Physics

From: Bob McElrath
Subject: [Axiom-developer] Re: Axiom + High Energy Physics
Date: Thu, 10 Nov 2005 10:25:41 -0800
User-agent: Mutt/1.5.11

C Y address@hidden wrote:
> --- Bob McElrath <address@hidden> wrote:
> > Cernlib certainly contains mathematical routines.
> > 
> > However it contains a very large number of things which are not
> > mathematical routines, and it is written in fortran.
> I thought it was being ported to C?  Did that not happen?

no...though the majority of it is in root.

> Of course, ideally we'd document and implement all the algorithms in
> Axiom as literate code ;-).  Although I understand BLAS and LAPACK in
> particular do a lot of low level optimization work I for one would not
> care to repeat...

Yes.  Those are in cernlib, but also exist elsewhere.  I agree they
should be incorporated for numerical linaear algebra.

> Bob, being a member of a physics department and a user of cernlib and
> friends, what would you recommend as a way to ensure and demonstrate
> the reliability of such packages?  (I suppose me getting a Phd in High
> Energy Physics would be the best first step, but that's probably not
> really practical...)  The only way I can think of is to make some kind
> of feyncalc_examples.pamphlet which reproduces every published result
> of Feyncalc on Mathematica, which might be good for a paper but may or
> may not convince people.  Would sure make for great bug testing though,
> regardless (/me scribbles note to look for published Feyncalc results
> on todo list...)

Making examples is a good idea.  Evangelizing within the community is
also a good idea.  Giving talks at conferences, etc.  A database of
known "test-case" results would be an excellent idea.

But perhaps the biggest of all is "ease of use".  All these tools are a
big pain and require a lot of specialized knowledge to even use.  The
holy grail of this field is to enter something like:
    p p -> t B j H
proton-proton (LHC) scattering into a top quark, bottom quark, jet and
higgs particle.  (or any other process) and then have it return a result
at next-to-leading order.  Believe it or not, we can't even do this.
There are a few tools that will do it at leading order that should be
compared to.

There are a lot of very smart people working on this, it's a highly
non-trivial problem.  The above example involves a few thousand
feynman diagrams.  At next-to-leading order it will involve perhaps a
few ten thousand.  Then one must consider renormalization, cuts, and
detector effects.  Which, frankly, is a whole lot of technical claptrap
that most users (even in physics) don't want to think about when they
sit down to figure this out, but is absolutely required to get a finite
answer.  I think such a program should choose a reasonable set of such
things, and include them in the output, with enough information in the
output to let the user know how to change them.  So, at tree level it
has been done.  (They are madgraph, comphep, grace, O'Mega/Whizard,
sherpa) See my Software page for more of this:

At one loop the general consensus is that this is possible, and there
are some people actively working on this (see: feyncalc and xloops).
There are technical problems which have not been solved, however, such
as automatic handling of soft, collinear, and overlapping singularities.
Handling of these things has even led to a new theory called SCET (Soft
Collinear Effective Theory) that only a few people understand right now.
The one-loop structure of this theory is only beginning to be explored.

So, one easily begins to encounter problems that no one knows how to
solve.  A significant amount of physics intuition must be applied to any
problem, and that is very difficult to automate.  The above example
contains a hexagon diagram at one loop.  As far as I know this has not
been solved for massive external particles.

I think this particular idea is probably only implementable within the
physics community, unfortunately.  But if anyone is going to take a stab
at it I would be happy to advise.

Many people actually see this as a crisis.  When the LHC turns on we
will quickly be in a situation where the theory error bars are much
larger than the experimental error bars, because next-to-leading order
results have in general not been calculated for many processes.  (and in
many cases, even that is not sufficent accuracy)

> > But of course I think such an effort is still worthwhile.
> Heh - perhaps the chance to avoid spending large fractions of the
> department budget on CAS software will help convince folks to to debug
> and test the new arrival.

That will not be a hard sell, especially with the financial situation
under the current emperor.

But it will be a hard sell, because no one is likely to get a paper out
of it.

> In your estimation, are the mathematical abilities of Axiom as it
> currently exists enough to support Feyncalc, or are we lacking
> something essential?  (Disregard if you don't use Feyncalc, of course
> ;-)

I don't see anything fundamental that is missing.  However, almost all
of it would be "new" code.  For instance one must program in the
analytic solutions to loop integrals (a la the FF library).  One needs
Gamma matrices, tensors, metrics, etc.  Basic functions such as
polylogarithms and hypergeometric functions would make the whole thing
easier.  And, as the loops gets bigger, one really wants some kind of
monte carlo to evaluate them numerically.

I mean, you can look through the feyncalc documentation to see what is

Bob McElrath [Univ. of California at Davis, Department of Physics]

    "In science, 'fact' can only mean 'confirmed to such a degree that it would
    be perverse to withhold provisional assent.' I suppose that apples might
    start to rise tomorrow, but the possibility does not merit equal time in
    physics classrooms." -- Stephen Jay Gould (1941 - 2002)

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]