Verification (make check) stuck in rt-NeigbourlistInitializationError (version 2.10.0)

[ivr900]

Hello to everyone!

I am trying to build Plumed 2.10.0 from source code on linux amd64 platform, as it is required dependency for some other packages. Mostly all went fine, but verification using 'make check' always stuck on test /regtest/basic/rt-NeigbourlistInitializationError which seems may run infinitely.

I have noticed that the latest master development version of plumed does not contain this test, therefore I wonder if it is safe to skip this test for plumed-2.10.0. Could plumed developers explain the situation with the test? Are there any tricks to make it pass, maybe?

Another note for PLUMED developers:

tests binaries compilation with latest gfortran versions may require extra Fortran compiler option "-fallow-argument-mismatch". I passed it to compiler through environemnt variable FFLAGS, because file ./link/Makefile contains:

$(FC) -c $(FFLAGS) $< -o $@

It would be nice if the FCFLAGS variable from the './configure' script could be used for these purposes. Currently (at least in plumed- 2.10.0) FCFLAGS not passed to Makefile.conf, neither as itself, nor as FFLAGS, therefore not used when test binaries are compiled. It would be nice if this unsettled situation with FCFLAGS anf FFLAGS could be resolved. Also, to make things neater these two variables could be reduced to one, imho.

Kind regards,
Ivan Rostov, NCI Australia

[Iximiel]

Hi Ivan

regtest/basic/rt-NeigbourlistInitializationError

Thanks for the report, we already addressed the problem:
the fix is already present in the v2.10 branch and will be in the next minor version release for v2.10.

The quickest workaround, if you do not want to patch the NeighborList file, is to kill the plumed process that it is filling up the RAM during the tests.

Some of the test that you are not finding have been moved to the tools category

-fallow-argument-mismatch

the flag is already present in the test compilation routine, you can grep it:

regtest/scripts/run:228:      export PLUMED_FORTRAN_FLAGS=-fallow-argument-mismatch

The test script tests if the compiler is compatible before setting it up.
Do you get some error there?

[ivr900]

Hi Daniel

thank you for explanations. I saw compiler messages about argument mismatch and did not think it was part of the test script to add the needed argument. Now I see.

Talking about Fortran flags setup, I still think it would be optimal for overall integrity to bring Fortran settings to a single variable. I see FCFLAGS in configure, which don't seems being used anywhere, FFLAGS in test/link/Makefile and PLUMED_FORTRAN_FLAGS in regtest/ makefiles. Optimally it could be reduced to one variable.

Also, I would like to report the latest results after skipping rt-NeigbourlistInitializationError test.

Now I have got errors in 4 tests when testing plumed-2.10.0:

basic/rt-average/
gridtools/rt-dens-average/
gridtools/rt-rdf/
landmarks/rt-reweight-temp-press/

In all these test reference files contain 'nan' values, which seems suspicious in general sense for test integrity. My 'make check' run results in plumed-2.10.0 directory have 0.0000 instead of nan.

Also, I have tried to build to build plumed2-master development brnach with the same environment, and all test pass including the four above, i.e. producing nan as in references. So I am puzzled. Are the 'nan' values, as in reference files, expected in those tests?

Kind regards,
Ivan

[Iximiel]

The "make" tests that compiles to C and Fortran or the Plumed interface in the regtests directory usually aim at testing a different compiler environment than the build one.
The "test" directory is quite legacy code, I never put my hands there, so I can't help you there.

In all these test reference files contain 'nan' values, which seems suspicious in general sense for test integrity. My 'make check' run results in plumed-2.10.0 directory have 0.0000 instead of nan.

I do not know your machine and your software configuration, here I can't help: but it should be nan and not 0.0.

By looking at the code, the first step is doing a 0/0 (hence nan), and I think it is an expected behavior, since the action accumulate does not store values on step 0. In 2.9 the average it will return 0.0 on step 0. IMO nan is more clear for making the user ignore that value. And yes, I am not sure this is clear in the manual.