Re: Problem with source.f

From: Joseph Comfort (Joseph.Comfort@asu.edu)
Date: Fri Nov 03 2006 - 20:22:59 CET

  • Next message: Ercan Pilicer: "need to activate other entries in mgdraw"

    Hi Alberto,

    Thank you for your response. I understood and appreciated it. My
    irritation with Alfredo's message was more one of tone. It was a long
    lecture detailing many complaints on minute issues (my opinion).
    Whether Wang had the nicest looking programming style or not, in looking
    at his code I do not think a cleaner version would have made much if any
    difference. Requirements such as the emphasized 'MUST' use double
    precision did not pertain to the problems raised by Wang. The same
    message could have been much shorter and in the form of mild
    suggestions. (Only the first paragraph really mattered.)

    I fully agree with you about the effects of truncation and roundoff
    errors on digital computers. I have taught numerical methods to
    students, and made such issues clear to them. I also had a peculiar
    case many years ago with a nuclear reaction code, where the least
    significant bit out to ~60 made orders of magnitude difference in the
    cross sections -- and that was for an 'arbitrary' number that would be
    normalized out at the end. (An issue with irregular functions
    dominating the results of integrations.) I worked with many such
    reaction codes. At the time, double precision was slow, and memory use
    and run times cost real money. So the codes were mostly single
    precision, but I was careful to identify the parts that needed double
    precision to obtain sensible accuracy for most of the range of
    applications. Putting the entire code in double precision might have
    been easier, but not needed and costly.

    With regards to MC codes, Geant3 was mostly in SP, with some DP coding.
    It generally worked well. (In fact, in some limited test calculations
    between 32-bit and 64-bit compilations, there were no significant
    differences.) In a recent paper we published (NIMB 246, 309 (2006)),
    the G3 results were generally second best to Fluka in reproducing data,
    with G4 results often quite different. I am currently studying other
    situations of differences between Fluka and G4, where Fluka 'looks' fine
    and G4 looks definitely wrong. The difference between Fluka and G4 (or
    G3 and G4) is not one of double precision (and certainly not for some
    limited coding in user routines), for the cases of interest to me, but
    one of models and their implementation. Fluka seems the best to me at
    the moment, but I often think it is very slow in comparison to other
    codes. I am sure that there are cases where double precision is
    essential to get sensible results (and maybe double precision on 64-bit
    machines might be better). But pride in one's code should not be
    overextended. Just let people appreciate the results.

    Best regards,
    Joe

    -- 
    Joseph Comfort                      Phone: (480)-965-6377
    Department of Physics & Astronomy   Dept.: (480)-965-3561
    Arizona State University            Fax:   (480)-965-7954
    Tempe, AZ  85287-1504               Email: Joseph.Comfort@asu.edu
    

  • Next message: Ercan Pilicer: "need to activate other entries in mgdraw"

    This archive was generated by hypermail 2.1.6 : Sat Nov 04 2006 - 12:59:43 CET