test_connect_after_simulate.sli fails with assertion 'source_lid < MAX_LID' when compiled with boost=ON in NEST 2.18.0

[niltonlk]

After successfully building with boost=ON by explicitly specifying the boost include path (see #1238)

make installcheck fails with:

<NEST_SOURCE_DIR>/nestkernel/target_data.h:264: void nest::TargetData::set_source_lid(unsigned long): Assertion 'source_lid < MAX_LID' failed.

when executing:

mpirun -np 1 <NEST_INSTALL_PATH>/bin/nest <NEST_INSTALL_PATH>/share/doc/nest/unittests/test_connect_after_simulate.sli

Note:
All installcheck pass when configured without boost

[terhorstd]

This should definitely be covered by the travis testing.

[niltonlk]

Dear all,

I have also tested this in the master branch, and the error persists. Apparently, there are many other errors, so I am attaching the logs and describing the system configuration. (Something I should have done before).

Configuration:
OS: CentOS 7.6
Compiler: GCC 8.3.0
MPI: OpenMPI 3.1.4
GSL: 2.6
Python: 3.6.6
CMake: 3.15.4
Boost: 1.71.0

cmake command:
cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/ohpc/pub/libs/gnu8/openmpi3/nest/3.0-dev -Dwith-mpi=ON -Dwith-python=3 -DPYTHON_EXECUTABLE=which python3.6 -DNOSETESTS=which nosetests -DCYTHON_EXECUTABLE=which cython -Dwith-boost=ON ../nest-master-niltonlk

I attach the reports directory as tar.gz:
reports.tar.gz

[niltonlk]

Digging a little on the error message, one of the cases where this error was seen is
on line 70 of test_connect_after_simulate.sli code:

/connections_before << >> GetConnections def

This is the second time GetConnections is called, and I remember seen some related comment on the nest users mailing list by Håkon Mørk on Feb 28, 2020, 9:10 AM.

With NEST 2.16 and onward, connection infrastructure requires connections to be sorted. Sorting is triggered when calling for example Simulate() or GetConnections(). Therefore, if you have stored your connections with GetConnections(), then create more connections, and the connections are sorted again (e.g. calling GetConnections(), then Connect(), then GetConnections() again), the connections you have stored are no longer valid.

Could this error be somehow related to that?

Have not looked any further, but just sharing info so that if someone has any clues could also help.

[hakonsbm]

@niltonlk Unfortunately I can't seem to be able to reproduce your error. My guess is that it could be an installation problem with CMake still not setting the Boost paths correctly, or a problem with the Boost installation.

The comment on the mailing list is not relevant to this issue however. Calling GetConnections both before and after connecting is only a problem when using the stored connection handles after connecting the second time.

[niltonlk]

This problem seems to appear with BOOST >= 1.69.0.
I have tested using BOOST from 1.71.0 down to 1.68.0 where the error did not show up.
It may sound a BOOST issue, but adapting the NEST code to newer versions of BOOST may be of future interest.

[heplesser]

Ah, library dependencies ... This may force a decision on how to handle this, if we need to support different Boost versions. @hakonsbm Could you investigate?

[ikitayama]

Have you tested with the latest 1.72.0?

…

On Fri, Mar 13, 2020 at 16:28 Hans Ekkehard Plesser < ***@***.***> wrote: Ah, library dependencies ... This may force a decision on how to handle this, if we need to support different Boost versions. @hakonsbm <https://github.com/hakonsbm> Could you investigate? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLBZ54EL24QCT3KQZHJOTRHHOC5ANCNFSM4H4CD6FQ> .

[niltonlk]

To answer to @ikitayama question, I have just tested and the error still persists with version 1.72.0.

[ikitayama]

Thank you for checking!

…

On Mon, Mar 16, 2020 at 14:08 Nilton Liuji KAMIJI ***@***.***> wrote: To answer to @ikitayama <https://github.com/ikitayama> question, I have just tested and the error still persists with version 1.72.0. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLBZ65RD3WH6RLOPX5243RHWX4DANCNFSM4H4CD6FQ> .

[heplesser]

See #1489 for further analysis. Please discuss all further work on this problem there.