[esp-r] Re: Esp-r linux install

[Ferguson, Alex]

Both Duncan and Lukas made some valuable observations about the
compilation and installation of ESP-r. Like the rest of ESP-r, the
installation script remains a work in progress; comments, criticisms and
especially contributions are all very welcome.  I think I can help
explain why things are the way they are, and provide an overview of
where we hope ESP-r will go in the coming months. 

The ESP-r README file contains instructions for updating your path
variable on bash and csh shells. This step is left to you for these
reasons:

- Modifying a system or user profile without their knowlege 
   would be incosistent with generally accepted UNIX 
   conventions, and cause grey-haired gurus to send angry 
   emails in my direction.
 
- Many users install versions of ESP-r that differ from the 
  system-wide installation, and some may have multiple 
  copies of ESP-r in their home directory. If the script 
  automatically updated the paths after each install, these 
  users might mistakenly invoke the wrong ESP-r binary.  

- We could not guarantee the path variables will be updated
  correctly in all circumstances. If things went awry, an 
  error in ~/.bash_profile or /etc/profile will cause all 
  sorts of grief, particularly for novice users.

Lukas suggested installing ESP-r binaries in standard locations that are
already included in the system path definitions---system-wide installs
might be stuffed into /usr/local/bin, and local installs could
optionally be placed in $HOME/bin (provided it exists). The install
script might even test the path variable for these locations, and advise
the user if the path needs updating. These are good ideas, and may soon
find their way into the install script if we can reach a consensus on
how to implement them.

Lukas also mentioned ESP-r's incompatibility with recent linux releases.
The cause of this incompatibility is a seemingly innocuous version bump
in the gcc compiler; gcc has been updated from 3.4 to 4.1 in most
distributions. But gcc4 replaces the long-standing g77 fortran compiler
with the newer, fortran-90 compliant gFortran. While ESP-r does compile
with gFortran (as of gcc4.1.1), the numerical results from g77 and
gFortran builds differ by as much as 4%. At present, we don't know if
these differences stem from dubious syntax in ESP-r or a problem with
gFortran itself. For this reason, we are cautiously calling gFortran
builds 'beta' for the time being, and we recommend against their use in
any project where ESP-r's accuracy is critical.

We fully appreciate incompatibility with gcc4 will severely limit
ESP-r's utility in the near future, and we're working to diagnose the
source of these differences. But finding them among the 250,000 some-odd
lines of code comprising bps is no easy task. We hope to resolve this
issue in the comming months; Weimin Wang---one of our smartest
colleagues---is leading the charge. If you wish to lend a hand, let me
know and I'll put you in touch with him.

64-bit computing with ESP-r remains uncharted territory simply because
the primary development groups (that is, ESRU and NRCan) don't have
access to 64-bit hardware. We're as impatient as the rest of you when
waiting for simulation results. But we can't test on platforms we don't
have access to. Contributions in this area from other users with 64-bit
machines would be very welcome.

Large parts of ESP-r comprise legacy code written nearly 30 years ago.
These procedures have proven extremely robust, and modernization of
these codes to support multiple threads would also require a very
extensive verification and validation effort. Neither ESRU nor NRCan
presently has the resources for this work, but we heartily encourage any
other users who wish to contribute.

Again, comments and criticisms are always welcome. ESRU, NRCan, and
other contributors from around the world have invested an enormous
amount of effort in ESP-r, and we want the software to be as functional
as possible and broadly used in the community. Still, most of our
efforts are guided by funding programs with specific research goals, and
we have only limited resources for general improvements.

If you wish to join these efforts, I'd be happy to set up a developer's
account for you. That's the beauty of free software---if we're taking
too long, you're always welcome to pitch in and fix things yourself.

Best regards,

Alex Ferguson
Building simulation R&D
CANMET Energy Technology Centre
Natural Resources Canada
P:+1 613 995 3294
F:+1 613 996 9909
Alex.Ferguson at nrcan.gc.ca