<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:x = "urn:schemas-microsoft-com:office:excel" xmlns:p = "urn:schemas-microsoft-com:office:powerpoint" xmlns:a = "urn:schemas-microsoft-com:office:access" xmlns:dt = "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s = "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs = "urn:schemas-microsoft-com:rowset" xmlns:z = "#RowsetSchema" xmlns:b = "urn:schemas-microsoft-com:office:publisher" xmlns:ss = "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c = "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc = "urn:schemas-microsoft-com:office:odc" xmlns:oa = "urn:schemas-microsoft-com:office:activation" xmlns:html = "http://www.w3.org/TR/REC-html40" xmlns:q = "http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D = "DAV:" xmlns:x2 = "http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois = "http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir = "http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds = "http://www.w3.org/2000/09/xmldsig#" xmlns:dsp = "http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc = "http://schemas.microsoft.com/data/udc" xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:sub = "http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec = "http://www.w3.org/2001/04/xmlenc#" xmlns:sp = "http://schemas.microsoft.com/sharepoint/" xmlns:sps = "http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf = "http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf = "http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver = "http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m = "http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels = "http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t = "http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m = "http://schemas.microsoft.com/exchange/services/2006/messages" XMLNS:Z = "urn:schemas-microsoft-com:" xmlns:st = ""><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.5694" name=GENERATOR> <STYLE>  </STYLE> </HEAD> <BODY lang=EN-CA vLink=purple link=blue> <DIV dir=ltr align=left> <o:p></o:p><o:p> </o:p></DIV> <DIV class=Section1> I just had a peak in the esp-r src/Readme file and it does say that version 4.1 is recommended.<o:p></o:p> <o:p> </o:p> As nearly all new distributions are past version 4.1 (I think), perhaps a note should be included in the readme that the use of 4.1 also requires:<o:p></o:p> --compiler_version -4.1, and<o:p></o:p> that the argument --gcc4 be passed, which it seems simply trades g77 for gfortran? If this is not declared, make looks for g77-4.1, which does not exist.<o:p></o:p> <o:p> </o:p> This information could simply go in the “Compilers” section of the Readme.<o:p></o:p> <o:p></o:p>  <o:p>These are good suggestions. I will try to fold them into development branch in the comming weeks. Perhaps the install script should default to gcc4, and provide the --gcc3 option for backwards compatability? I might even add functions to query the gcc version number and issue warnings (and possibly enable floating-point exception handling) for gcc4.2+ systems.</o:p> <o:p> </o:p> ----<o:p></o:p> <o:p> </o:p> I do recall some unexplained floating point errors with 4.1 which were of concern for the last year.<o:p></o:p> Have these been resolved?<o:p></o:p> <o:p></o:p>  <o:p>Yes. We found numerous numerical exceptions and other dubious code that introduced all sorts of headaches on the gcc 4.1 and intel toolsets. We've remedied these, and the gcc 4.1, Sun and Intel compilers now agree well throughout the ESP-r test suite. gcc4.2+ compiled-versions still exhibit some instabilities. Detailed results from our last round of testing follow. In the future, I'll circulate these test results more broadly. </o:p> <o:p></o:p>  <o:p>- Alex </o:p><o:p>     ====================== SUMMARY: ======================  - ESP-r compiles correctly on Linux, Cygwin, MinGW, Solaris and OSX.  - Portability testing suggests that GCC 4.1.2 builds are actually more    reliable than GCC3 builds.  - GCC 4.2.3 builds are not as robust.  - Some uncertainty remains in Intel builds, as well as builds on OSX.   Recommendations:  - Proceed with release.  - The ESP-r 'reference' platform should be changed from    Linux / GCC 3.4.6 to Linux / GCC 4.1.2  - Cygwin / GCC 3.4.6  and SUN CC builds should continue to be    designated as stable  - GCC 4.2+ and Intel builds should be used with caution.  - Compiler optimization should be used with caution.  - OSX / GCC 3.4.6 and MinGW / GCC 3.4.6 builds should be used with    caution.   Detailed results follow. ====================== Static Analysis: ====================== The Forcheck static analyzer warns of no additional coding errors in the current version of pre-release-patches. The total number of errors, warnings and informational numbers as declined from the last release. ====================== Regression testing: ====================== Changes since the last revision have introduced significant numerical differences into the results. But for the first time, all the numerical differences were anticipated by developers, and no unintended effects were observed during testing.   Two revisions introduced numerical differences in to the results:    r2838: This commit patched a long-standing bug in the water tank         storage model. Predicted water temperatures in the plant         network may differ by as much as 3oC; predicted casual gains         in the space may differ by as much as 3W.    r3088: This commit corrected an error in the application of relaxation         to the plant network solution scheme. Predicted heat transfer         in the plant may differ by as much as 400W (1%), predicted         temperatures in the plant may differ by as much as 18oC in         extreme cases.   ====================== Portability testing: ====================== The release candidate can be successfully installed on the following platform, compiler and graphics library combinations. We've also added support for the Intel compiler suite on linux. Jon Hand has been experimenting with support for 64-bit architecture, but this work has not yet been generalized for inclusion in the public release.   We've successfully installed ESP-r using the following 32-bit platform, compiler and graphics library combinations:           Support for ESP-r on various compiler, platform                 and graphics library combinations.     =============================================================     Compiler     Library    Linux   Cygwin   MinGW   Sun   OSX     =============================================================     GCC 3.4.X    X11                                  O     O     SUN CC       X11                                  O     GCC 3.4.4    X11                  O                  noX                  O     GCC 3.4.5    noX                           *     GCC 3.4.6    X11          O                  GTK          O                  noX          O     INTEL        noX          O                  X11          O                  GTK          O     GCC 4.1.2    X11          O     GCC 4.2.3    X11          O     -------------------------------------------------------------     Notes:     O: Installs correctly.     *: MinGW only installs correctly to absolute DOS paths     (i.e. C:/ESRU)     ============================================================= We've also undertaken a comprehensive comparison of the numerical results produced by ESP-r on various platforms. Previously, these comparisons were limited to various versions of the GCC compiler suite on Linux and cygwin.  Since the last release, Jon Hand has worked to add support for XML-enabled builds on OSX and Solaris, using both the GCC and Sun compiler suites. Along with new support for the Intel compiler, these new capabilities add important reference points for our ongoing evaluation of GCC4/gFortran   For the last few years, we've designated GCC 3.4.6/Linux builds as the reference version of ESP-r. Most ESP-r development and automated testing is based on this platform, and bps's numerical predictions on this platform receive scrutiny than any other. GCC 3's fortran 77 compiler   (g77) has been obsoleted by gFortran, a fortran 90 compiler released with GCC 4.   Results differ somewhat between g77 and gFortran builds, and we've been wondering if they're caused by bugs in g77 or gFortran, or perhaps poor ESP-r code that one of the compilers is more sensitive to.   For the first time, we have additional reference points (Intel and Sun   CC/f90) to perform these comparisons with.   The following chart summarizes the significant observed differences between the  and other platform and compiler combinations. The "Maximum difference" reflects the maximum observed difference observed in the test cases, excluding exceptional test cases that are discussed in section 'Problematic test cases', below..       Comparison of results from GCC4.1.2-compiled versions       (X11, Linux) with builds from other platform/compilers.     =============================================================     Arch.     Platform    Compiler      Maximum difference (%)     -------------------------------------------------------------     IA-32     CYGWIN      GCC 3.4.4            3.18               LINUX       GCC 3.4.6            3.18                           GCC 4.2.3            0.   (^1)                           Intel -O0            0.75 (^2)                           Intel -O2           38.781     PowerPC   OSX         GCC 3.4             16.1     Sparc     SOLARIS     Sun CC/f90           1.80     -------------------------------------------------------------     NOTES:       1. Some test cases produced numerical exceptions and          floating point errors. See "Problematic Test Cases".       2. One test case produced a larger error (~13%). See below.     =============================================================   Detailed scrutiny of the results revealed:    - gFortran vs Intel iFort / SUN f90    ---------------------------------    With optimization disabled, the results from SUN and Intel compilers    consistently agree more closely with GCC 4.1.2 / gFortran than they    do with GCC 3.4.6 / g77. These results suggest GCC 4.1.2 can be used    with confidence, and indeed, should be recommended in place of g77.    - Stability of gFortran    ---------------------    GCC 4.2.3 builds encounter numerical exceptions in a handful of test    cases that ran correctly in all other compilers (See "problematic    test cases", below). I recommend GCC 4.2+  builds be regarded as 'beta'     until this issue is resolved.     - Intel iFort results: effect of optimization    -------------------------------------------    With optimization deactivated, the Intel compiler consistently produced    results close to the gFortran and Sun f90 builds. But When the default    optimization is activated (using the -O2) option, agreement between    the Intel and GCC 4.1.2 compiler deteriorates considerably. Nearly    all of the models exhibit small, non-trace differences, and in every    case these differences were slightly, or significantly larger than    those observed with optimization deactivated.      Its possible this error is due to bugs in Intel's optimization    algorithm, but poor code in ESP-r is more likely the culprit. For    instance, when -O0 is specified, the compiler ensures that arguement    mismatches in procedure calls are properly converted, but does not    perform these conversions by default.      This problem might occur in GCC builds as well. By default, GCC uses    no optimization. I suspect similar issues might appear if -O2 is    specified for g77/gFortran builds.    For these reasons, application of optimization options with ESP-r    is not presently recommended.    - Intel iFort results: test case bld_hc_ISO15099 /HC    --------------------------------------------------    Newly added for this release, this test case continues to cause    headaches. Intel-compiled versions of bps exhibit significant    differences from g77/gFortran builds:          - MAX error (W)                199.37 W  ( 13.293 %)       - Predicted value - g77        1499.8 W                           Intel      1300.4 W         [ observed in:           building:zone_05:thermal_loads:net_load:month_01 (max) ]       The corresponding test case that does not activate the ISO15099    correlation does not exhibit the same error, suggesting the Intel    compiler is exposing a sensitive compoment of the ISO15099 algorithm,    or vice-versa.      The SUN CC/f90 results we have do not include this test case,    precluding assessment of whether the g77/gFortran or Intel predictions    are more accurate. For this reason, the Intel compiler suite is only    recommended for beta testing for the time being.  - OSX / GCC builds    ----------------    A handful of test cases exhibited suprising sensitivity when run    with GCC 3.4 compiled builds on OSX. The cause of these differences    is not known; OSX builds should be used with caution for the time    being.   =========================== Problematic test cases ===========================    - esru_benchmark_model / bld_basic_af2_summer                         / bld_basic_af2_winter    -------------------------------------------    We've previously observed the that this coarse-timestep air flow    network test case produces significant differences in g77 and    gFortran builds. The long, half-hour timesteps cause small    differences in the numerical computations to be exaggerated in    the aggregated output --- increasing time resolution vastly improves    agreement between the compilers.      The Linux / Intel, Solaris / SUN CC-f90, and OSX / g77 platforms all    exhibit the same sensitivity. They produce differing results at    short-timesteps, but agreement with Linux / g77 improves at higher    time-resolutions.      Since we've observed that each compiler combination produces dissimilar    results and that the high-resolution version is more useful,    this test case has little value. For this reason, I recommend we    delete it.    - plt_boundary_conditions / connected_flow                              connected_temperature                              unconnected_controls                              unconnected_flow                              unconnected_temperature    -------------------------------------------------    While they run correctly in every other compiler (including GCC 4.1.2),    these test cases produce undiagnosed numerical exceptions in GCC 4.2.3.  </o:p></DIV></BODY></HTML>