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

[C Y]

--- Bob McElrath <address@hidden> wrote:

> 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.

Hmm.  OK.  So scratch cernlibs, and focus on 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.

Tim, what's the plan for stuff like this?  Is the Lisp level up to
providing the performance for these algorithms that the (presumably)
optimized code already implemented can provide, or at least close
enough so that no one will worry about it?  Typically code for symbolic
algebra systems has been a different animal that that for numerically
optimized systems - is Axiom going to attempt to merge the two worlds?

> > 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.

Well, the first and the last might (with sufficient study) be something
I could attempt, anyway :-).  Other than that, I guess maybe the guys
at my undergrad university might give it a look, if I asked nicely...

> 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.

Ho boy, I've got a long ways to go.  Is leading order the decay
products from t B j H, and next to leading order the products from
those products?

> 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.

Um. (setf *question-mode* 'clueless-dweeb)  How does one display a few
thousand diagrams usably?  Or are the feynman diagrams the means rather
than the end?

> 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.

How much of that can be either pre-entered as a function of the
experimental conditions or algorithmically decided?

> 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.  

Makes sense.

> 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:
>     http://mcelrath.org/Notes/Software

Cool!

> 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.

Fun!  So there's some opportunity for real research here, from the
sound of things.

> 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.

I'll see if I can work my way up there.

> 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)

Wow.  That's kind of a fun time, actually.

> > > 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.

Maybe if they solve some of the difficult questions you mentioned
earlier and happend to do it in Axiom...

> > 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.

Sounds like a challenge!  Maybe Maxima's tensor package would have some
useful hints for that part of the operation - it has been heavily
worked on of late (I noticed you mentioned it in your software page -
last I heard it had been fixed and was working.)

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

I think I'll need some more basic material first...

Cheers, and thanks!

CY


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com