Hi,
This problem is I think related to the underlying GNU headers and a
potential fix has been reported by Tyler Luchko. Try changing
'libpme_standalone.h' in the following manner:
```
diff --git a/AmberTools/src/cpptraj/src/libpme_standalone.h
b/AmberTools/src/cpptraj/src/libpme_standalone.h
index 795d297561..7b3aa709ee 100644
--- a/AmberTools/src/cpptraj/src/libpme_standalone.h
+++ b/AmberTools/src/cpptraj/src/libpme_standalone.h
.. -33,6 +33,7 ..
#include <tuple>
#include <vector>
#include <functional>
+#include <stdexcept>
// original file: ../src/fftw_wrapper.h
.. -3065,7 +3066,7 .. class PMEInstance {
std::string msg("Bad rPower requested. To fix this,
add the appropriate entry in");
msg += __FILE__;
msg += ", line number ";
- msg += std::to_string(__LINE__ - 5);
+ msg += std::to_string((long long) (__LINE__ - 5));
throw std::runtime_error(msg.c_str());
break;
}
```
Let me know if that works for you. This will end up in a bugfix
hopefully soon. Thanks for the report.
-Dan
On Fri, Apr 20, 2018 at 7:58 AM, David A Case <david.case.rutgers.edu> wrote:
> On Thu, Apr 19, 2018, Niel Henriksen wrote:
>>
>> I'm seeing an error (attached) for compiling AmberTool18 cpptraj with Intel
>> 16.0.4 on RHEL 6.9.
>>
>> The problem seems confined to Ewald_ParticleMesh.cpp and appears to be
>> related to C++11. If I configure cpptraj with "-noc++11", it completes
>> without an error.
>
> Thanks for the note. I'm somewhat surprised, since we checked Intel16
> compilers before the release, although most testing was on Intel17 and
> Intel18 varieties.
>
> That said, the Ewald_ParticleMesh code in cpptraj is pretty new. We'll
> work on getting an update prepared to address the issue you raise.
>
> Generally speaking, Intel compilers cause Amber developers to lose sleep
> and get many new grey hairs. The working environment, optimization
> problems and lack of compatibility seem to change with each version.
> Most users (and I understand that you, Niel, don't fall into this
> category) should stick with gnu compilers, unless they know they will
> be running lots of long CPU computations where the (modest) speed gains from
> commercial compilers will add up to be worth the pain.
>
> ...thx...dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
-------------------------
Daniel R. Roe
Laboratory of Computational Biology
National Institutes of Health, NHLBI
5635 Fishers Ln, Rm T900
Rockville MD, 20852
https://www.lobos.nih.gov/lcb
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Apr 20 2018 - 06:00:05 PDT
