Jason graciously allowed me to use his Jenkins server (which is now working again), and I have set up some nightly build & test runs of Amber on it. You will need to ask Jason for a Jenkins account to see it, but the link to the Jenkins page is
http://www.jasonswails.com:8888/job/Amber/. I am planning to add more test permutations, including static builds, intel & PGI builds, and CUDA, soon. These builds also produce artifacts, so maybe we could set up some sort of nightly release in the future?
As of now, the Amber serial tests report 161 passes, 0 failures; the AmberTools openmp tests report 701 passes, 0 failures; and the AmberTools serial tests report 2065 passes, 9 failures, and 8 errors. However, in the past we have had issues where testing CMake-built Amber would cause test script errors that decreased the "pass" count without increasing the "fail" count, so I wouldn't trust the fail and error counters. I am still trying to figure out how to get mpiexec working on the test machine, so we don't have MPI tests yet.
> On Linux, things are generally better (for AT), but I still get 18 failures that I don't see with the regular make system.
>From a quick examination, it looks like all of the AmberTools comparison failures are coming from FEW. I noticed this issue a while ago, but have not fixed it yet.
> I get tons of failures on macos (esp. with NAB and cpptraj). I've spent sometime debugging, but I think they are related to the fact that CMake builds dynamic libraries everywhere, whereas the
> conventional Make scripts use mostly static libraries (except where dynamic is required, as with python).
The nab wrapper took a lot of work to get working in CMake, and with the latest updates I find that it now works on about 90% of machines. It now uses the -rpath flag on MacOS, so it can properly handle linking to most dynamic libraries. If the CMake nab wrapper is failing for you, you can see the commands it's invoking with the "-v" option, and you can cause it to leave intermediate files with the "--save-intermediates" option.
However, most nab tests are currently failing on MacOS because of a segfault in the readparm() function. I was not able to figure out what was causing it, though I suspect some sort of stack corruption. I posted a backtrace on GitHub here, along with instructions for how to use a debugger on nab programs: https://github.com/Amber-MD/cmake-buildscripts/issues/34#issuecomment-345506284
One of the big reasons for tests reporting failures is that all of the sanderapi tests are crashing with segfaults, this time in Sander's ext_energy_forces() function. Again, I posted a backtrace here: https://github.com/Amber-MD/cmake-buildscripts/issues/101
If people who are more familiar with Sander could take a look at this, that would be great.
Thanks,
Jamie (The CMake guy)
-----Original Message-----
From: David A Case [mailto:david.case.rutgers.edu]
Sent: Saturday, January 20, 2018 7:42 AM
To: amber-developers.ambermd.org
Subject: [AMBER-Developers] is anyone running tests using the CMake option?
I often confirm that CMake will build Amber without build errors. But I've not had time to do much testing of the resulting executables.
Jamie now has a -DINSTALL_TESTS=TRUE option which will put the test cases into the install directory. There is no top-level Makefile (in $AMBERHOME), but you can run tests in the usual way in $AMBERHOME/test and $AMBERHOME/AmberTools/test.
Is anyone doing this? I get tons of failures on macos (esp. with NAB and cpptraj). I've spent sometime debugging, but I think they are related to the fact that CMake builds dynamic libraries everywhere, whereas the conventional Make scripts use mostly static libraries (except where dynamic is required, as with python).
On Linux, things are generally better (for AT), but I still get 18 failures that I don't see with the regular make system.
So: is anyone running tests using CMake? (We really need to install the $AMBERHOME/Makefile to simplify this process.) Does it seem to work better than for me? Anyone looking for something to do is welcome to try to get this better tested. I fear that we may have to continue to support two parallel build systems for a while, but I'd sure like to push the transition to CMake as soon as we can.
...thx...dac
_______________________________________________
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 Sat Jan 20 2018 - 15:30:02 PST
