Hi Scott,
Thanks for the info from your OSC experience; I have gotten so fed up with
intel that I have not renewed my license (I can still access whatever unc
puts on their machines, but that of course does not give me access to every
release). I guess I will have to check out PGI again. I would suggest that
we up-front, on the web page, recommend versions of the intel compiler and
mkl known to work well, and somehow tactfully make it clear to the user
community that we are not in the business of being able to compile every
version of intel and link to every version of mkl that has ever been or ever
will be produced, and don't want to squander the human resources that would
be required.
Regards - Bob
----- Original Message -----
From: "Scott Brozell" <sbrozell.rci.rutgers.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, March 09, 2010 11:47 PM
Subject: Re: [AMBER-Developers] PMEMD missing type?
> Hi,
>
> Intel's C++ compilers also have poor (nonexistent?) quality assurance.
> I'm not sure how much Intel's poor engineering (interface changes,
> goofy directory structure etc) affects the C++ crowd, but
> Ive figured since around version 6 that their poor practices would
> catch up with them; they dont seem to have; and intel doesnt seem to
> be improving their practices:
> http://software.intel.com/en-us/forums/showthread.php?t=62095
>
> I'll plan to submit a bug report to them with as little effort on
> my part as possible.
>
> As far as other compilers, we've had good luck with PGI at OSC
> although there have been several amber bug reports related to pgi
> compilers and at least one of them (117) is a compiler preprocessor bug.
> In addition we recommend ACML.
> The OSC system admins are very conservative on installing Intel
> products; here's what we have:
> intel-compilers-9.1-20070320
> intel-compilers-10.0.023
> intel-compilers-11.1.056
> mkl-10.0.3.020
>
> Scott
>
> On Tue, Mar 09, 2010 at 04:40:48PM -0500, Robert Duke wrote:
>> I agree with you in principle; the problem here is that about every third
>> release of the intel compiler is broken or the interfaces are changed, or
>> mkl is screwed up, etc. etc. I see no hope of staying ahead of them with
>> workarounds, so as long as we are using that compiler, I think we are
>> going
>> to be stuck recommending versions that work. We went through this
>> bigtime
>> with them on itanium; they apparently now have hit a point in their own
>> complexity or have lost a vision of a solid product, or something. What
>> I
>> would recommend against is funky workarounds, just to get some bloody
>> version to work; formally more correct f90-f95, well I can see that, as
>> long as you don't then break other compilers.
>> Regards - Bob
>
>> ----- Original Message -----
>> From: "Ross Walker" <ross.rosswalker.co.uk>
>> >>As a workaround, I would revert to a bloody release of ifort that
>> >>works...
>> >>There is no requirement for our code to function with broken compilers,
>> >>in
>> >>my opinion, at least...
>> >
>> >Agreed. Except teaching that to some users who may have trouble
>> >understanding exactly what a compiler is let alone which version it is
>> >is
>> >about as much fun as pulling teeth so if we can find a simple (and
>> >benign)
>> >workaround this is easier than trying to explain how to obtain older
>> >versions of the compilers and/or file a bug report with Intel etc.
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 10 2010 - 06:00:16 PST
