Here are the results of the checks you suggested:
1) mpicc -show shows the correct gcc (4.8.2) that I used for serial compile
2) serial config output has two outputs not found in mpi:
Configuring XBLAS (may be time-consuming)...
XBLAS configure succeeded.
Configuring MTK++ (may be time-consuming)...
MTK++-0.2.0 configure succeeded.
3) mpi config output has the expected difference:
testing [C++ / fortran] cross-compile with MPI libs
However, there is no "OK" or other success message after this call, simply:
"The configuration file, config.h, was successfully created."
immediately after the above call.
Otherwise, the two outputs are identical.
I am going to try to keep building amber14, but the idea of switching to 16
is a possibility for the future.
On Sun, Jan 15, 2017 at 1:42 PM, David Case <david.case.rutgers.edu> wrote:
> On Sat, Jan 14, 2017, Ada Sedova wrote:
> >
> > My colleagues at the NCCS Scientific Computing group also were wondering
> > why you would HAVE to build in serial first (it is not a common
> procedure).
>
> The reasoning is this: Amber users potentially need all the programs
> in the suite, but only a few are configured for parallel operation.
> Furthermore, the parallel programs need to be compiled with mpicc/mpif90,
> whereas the other codes don't need this. So it makes sense to ask
> parallel users to compile both serial and parallel versions (the latter
> only creates a few executables.)
>
> But since there are some users who need only parallel programs for a
> particular computer (cluster), we will try to allow for parallel-only
> builds
> in the next release of AmberTools.
>
> > Also, it is strange that after advising me to do this, they are also
> > telling me that there is a common problem with residual files from the
> > serial build interfering with the parallel build, and I should use <make
> > distclean>; furthermore there is no rule for distclean, only for clean,
> in
> > the top Makefile. Very confusing.
>
> This is more or less inevitable in a mailing list. The Amber16
> distribution's
> Makefile has a "distclean" target, whereas that from Amber14 apparently
> does
> not.
>
> And no, these problems are not "common". Since it is often hard to debug
> problems that do arise remotely, a reasonable suggestion is to try to make
> sure that we understand the environment at the remote site, hence the
> suggestion to try to start from a clean environment.
>
> >
> > While I have your attention, I was wonder what it would take to get an
> > upgrade of our site license to amber16/AmberTools16.
>
> Please visit http://ambermd.org/#obtain. (Note: be sure to check your
> mpicc
> command as I suggested earlier, or you may find the same problem with
> Amber16:
> I'm not sure that the root cause of your problem has really been
> identified.
> Also note that you can see if things work just with AmberTools16, since the
> problem you report was with the AmberTools parallel build.)
>
> ....dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Jan 15 2017 - 11:30:03 PST
