Boost/PCMSolver/LSDalton

[taylor]

I had originally posted the problem here in another topic that seemed closely related: in retrospect that was a bad move because my issue has diverged from the one in the original topic.

I am not able to build LSDalton with PCMSolver. Originally this appeared to be a problem with the local Boost installation, but the original errors disappeared when I followed Roberto's suggestion, forwarded by Magnus, to include
-DENABLE_CXX11_SUPPORT=ON in the file src/pcm/CMakeLists.txt. However, I then got the error
cd /home/taylor/src/2018/lsdalton/build_solv/external/pcmsolver-build/src/green && /apps/intelmpi/5.1/compilers_and_libraries_2016.0.109/linux/mpi/intel64/bin/mpiicpc -DHAS_CXX11 -DHAS_CXX11_AUTO -DHAS_CXX11_AUTO_RET_TYPE -DHAS_CXX11_CLASS_OVERRIDE -DHAS_CXX11_CONSTEXPR -DHAS_CXX11_CSTDINT_H -DHAS_CXX11_DECLTYPE -DHAS_CXX11_FUNC -DHAS_CXX11_INITIALIZER_LIST -DHAS_CXX11_LAMBDA -DHAS_CXX11_LONG_LONG -DHAS_CXX11_NOEXCEPT -DHAS_CXX11_NORETURN -DHAS_CXX11_NULLPTR -DHAS_CXX11_RVALUE_REFERENCES -DHAS_CXX11_SIZEOF_MEMBER -DHAS_CXX11_STATIC_ASSERT -DHAS_CXX11_VARIADIC_TEMPLATES -DPCMSolver_EXPORTS -DTAYLOR_CXXIO -DVAR_IFORT -I/home/taylor/src/2018/lsdalton/build_solv/external/pcmsolver-build/modules -I/home/taylor/src/2018/lsdalton/external/pcmsolver/api -isystem /home/taylor/src/2018/lsdalton/external/pcmsolver/external/eigen3/include/eigen3 -isystem /home/taylor/src/2018/lsdalton/external/pcmsolver/external/libtaylor -I/home/taylor/src/2018/lsdalton/external/pcmsolver/src -I/home/taylor/src/2018/lsdalton/build_solv/external/pcmsolver-build/include -I/home/taylor/src/2018/lsdalton/external/pcmsolver/include -isystem /home/taylor/src/2018/lsdalton/external/pcmsolver/src/utils/getkw -I/home/taylor/src/2018/lsdalton/external/pcmsolver/src/dielectric_profile -std=c++11 -O3 -DNDEBUG -fPIC -fvisibility=hidden -o CMakeFiles/green.dir/SphericalDiffuse.cpp.o -c /home/taylor/src/2018/lsdalton/external/pcmsolver/src/green/SphericalDiffuse.cpp
In file included from /usr/local/include/boost/noncopyable.hpp(15),
from /usr/local/include/boost/numeric/ublas/detail/config.hpp(23),
from /usr/local/include/boost/numeric/ublas/exception.hpp(19),
from /usr/local/include/boost/numeric/ublas/storage.hpp(25),
from /usr/local/include/boost/numeric/ublas/vector.hpp(21),
from /usr/local/include/boost/numeric/odeint/util/ublas_wrapper.hpp(23),
from /usr/local/include/boost/numeric/odeint.hpp(25),
from /home/taylor/src/2018/lsdalton/external/pcmsolver/src/green/InterfacesImpl.hpp(38),
from /home/taylor/src/2018/lsdalton/external/pcmsolver/src/green/SphericalDiffuse.hpp(42),
from /home/taylor/src/2018/lsdalton/external/pcmsolver/src/green/SphericalDiffuse.cpp(24):
/usr/local/include/boost/core/noncopyable.hpp(42): error: defaulted default constructor cannot be constexpr because the corresponding implicitly declared default constructor would not be constexpr
BOOST_CONSTEXPR noncopyable() = default;
^

compilation aborted for /home/taylor/src/2018/lsdalton/external/pcmsolver/src/green/SphericalDiffuse.cpp (code 2)


Magnus found that using my setup command
# setup command was executed 25-June-2019 14:22:01
./setup --fc=mpiifort --cc=mpiicc --cxx=mpiicpc --type=release --omp --scalapack --blacs intelmpi --explicit-libs=-lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -liomp5 -lpthread -lm -ldl --mkl=parallel -D ENABLE_DEC=ON -D ENABLE_PCMSOLVER=ON -DENABLE_CXX11_SUPPORT=ON build_solv
he could build the code, but his build detected no boost library and thus generated the necessary files itself. He speculated that including -DBUILD_CUSTOM_BOOST=ON in the PCM CMakeLists.txt file might force such a boost build, but it does not. Is there a way to force it? I cannot ask our sysadmins to uninstall Boost (v1.70, incidentally) because others may need it.

Best regards
Pete

[taylor]

By getting our sysadmin to delete the installed boost (no idea whose work that might screw up, so it's not a permanent solution...) I can get the code to build using the above setup command. However, an attempt to use PCM functionality produces an error
Error: Error: Getkw::Getkw, line 34 in /home/taylor/src/upd2018/lsdalton/external/pcmsolver/src/utils/getkw/Getkw.cpp: Open failed: @pcmsolver.inp

I'm no C++ programmer, but looking at the code I am unsure where the "@" comes into the filename above. We do not delete scratch directories by default on our system, and a look in the scratch directory shows a file called "pcmsolver.inp" which has the correct contents.

Best regards
Pete

[bast]

hi Pete,

(I am catching up on this forum after being under water for a long time with other tasks)

This error rings a bell. I suspect a problem with copying to scratch disk. I need to run a PCM calc to refresh my memory on how the input file copying was set up and will report back as soon as I know more.

best greetings,
radovan

[bast]

I can reproduce the error with Python 3 but the calculation runs fine with Python 2. This error comes from the depths of libgetkw, the library parsing input to the PCMSolver. Unfortunately libgetkw is not really supported anymore. With Roberto and Stig we are in the process of implementing a next generation input parsing library (https://github.com/dev-cafe/parselglossy). Anyway, in the short term it would be good to fix this inside libgetkw/PCMSolver but a workaround is to run in a Python 2 environment.

Please let me know whether this "solved" it.

[taylor]

Thanks, Radovan, but our installed version of python is 2.7.6, i.e.,
which python
points to /usr/bin/python, which is version 2.7.6.

We do have python3
which python3
points to /usr/bin/python3, which is version 3.4.3.

Are you saying that somewhere in some script(s) python3 is explicitly invoked and this needs to be changed? As you see above, just invoking python would get 2.7.6.

Best regards
Pete

[bast]

dear Pete,

in this case Python 2/3 is probably not the problem. I don't think the code explicitly invokes Python 3 - rather that it assumes Python 2.

In my case I got this error with Python 3:

Code: Select all

Traceback (most recent call last):
  File "/home/bast/tmp/dalton/build/external/pcmsolver/install/bin/pcmsolver.py", line 37, in <module>
    import getkw
  File "/home/bast/tmp/dalton/build/external/pcmsolver/install/bin/getkw.py", line 68
    raise TypeError, 'Not a Section or Keyword'
                   ^
SyntaxError: invalid syntax

 DALTON: default work memory size used.            64000000

 Work memory size (LMWORK+2):    64000002 =  488.28 megabytes; node   0

   0: Directories for basis set searches:
     /home/bast/tmp/pcm-example:/home/bast/tmp/dalton/build/basis
Error: Error: Getkw,  line 33 in  /home/bast/tmp/dalton/build/external/pcmsolver/src/pcmsolver/src/utils/getkw/Getkw.cpp: Open failed: @pcmsolver.inp

In other words the "Open failed" was only a side-effect in my case but not the problem. Is there any error message further up in your stdout/stderr?

[taylor]

I did not see another error but please note I am only using LSDalton here, not Dalton. I have not tried with Dalton (for the problem we want to study only LSDalton makes sense).

Best regards
Pete

[bast]

Oops - my bad. Wrong code I will have a look at LSDalton whether I can reproduce it and whether I see something there.

[bast]

I tried now with LSDalton and with Python 2 got indeed:

Code: Select all

Error: Error: Getkw,  line 34 in  /home/bast/tmp/lsdalton/external/pcmsolver/src/utils/getkw/Getkw.cpp: Open failed: @pcmsolver.inp

A bit further up I got:

Code: Select all

Traceback (most recent call last):
  File "/home/bast/tmp/lsdalton/build/external/bin/go_pcm.py", line 32, in <module>
    import docopt
ImportError: No module named docopt

So it seems the code has an undocumented dependency (from the LSDalton user perspective) on docopt.
Once I pip install docopt into a Python virtual environment, it worked for me.

But I might have hit a different problem with the same symptom.

[taylor]

Thanks for this! I did a pip install docopt to my pythonmodules directory and at least a modest-sized test case (a substituted phenol) runs successfully. I'll get the student to try it for her molecule later today (she has an exam to deal with first...).

I did find the docopt error (eventually) in the stderr file from the jobs that failed, but there's so much stuff in there it's not easy to look through, and since this was a parallel run things of course may get written in a confusing order.

Best regards
Pete

[bast]

Cool! Glad it works - I created an issue: https://gitlab.com/dalton/lsdalton/issues/58