Build neuronmusic

[mdjurfeldt]

@ohm314 Up until NEURON version 8.0, NEURON had a MUSIC interface. However, the new cmake build system in version 8.0 does not yet support installation of the neuronmusic module (which is still in the sources, however).

Please make the cmake build system optionally install the neuronmusic module (with associated Python bindings).

[nrnhines]

Sorry for the oversight. I'll port the autotools support for music to cmake.

[nrnhines]

@ohm314 @mdjurfeldt I started out thinking the ideal cmake option would be -DNRN_ENABLE_MUSIC=ON but I see that the old autotools option was --with-music=/prefix/of/music/installation . The simplest way to proceed is to require that the user supply the music installation location to a cmake option with a name that indicates it should take a installation path to an external installation rather that a mere ON/OFF value. This seems reasonable given that music connects different simulators in a peer to peer style. So it doesn't seem quite right in this case to provide the apparatus for music as a submodule. I'm happy to entertain contrary opinion. So how about something like -DNRN_PATH_TO_MUSIC=/prefix and from there CMake would require success in finding

/prefix/bin/music
/prefix/include/music.hh
/prefix/lib/libmusic.so.*

and also require that MPI and PYTHON be enabled. One aspect I'm not clear on at the moment is whether or how this should interact with the binary neuron installers. It's a bit of an effort to support optional existence of music as we do with MPI, X11 and even Python.

[mdjurfeldt]

@ohm314 @nrnhines I concur that -DNRN_PATH_TO_MUSIC is the better solution.

[ohm314]

Alternatively we can create a FindPackage for Music similar to those here: https://github.com/neuronsimulator/nrn/tree/master/cmake/modules this seems to me like the more natural CMake way of doing this? If the prefix can be found automatically it will just add it into the appropriate variables, otherwise you pass the music prefix in the CMAKE_PREFIX_PATH. But I'm fine with either.

[nrnhines]

I was toying with an addition to https://nrn.readthedocs.io/en/latest/cmake_doc/options.html#mpi-options of the form

NRN_PATH_TO_MUSIC:STRING=
-------------------------
  Enable MUSIC. MUlti SImulation Coordinator. The full /path to the MUSIC
  installation must be specified.

  See https://github.com/INCF/MUSIC/ for installation of MUSIC.

  MPI and Python must be enabled and CMake expects to find 

  .. code-block:: shell

    /path/bin/music  
    /path/include/music.hh  
    /path/lib/libmusic.so.*  

but I have to agree with Omar that its probably best to go with the "more natural CMake way" so that -DNRN_ENABLE_MUSIC=ON if not successful will emit enough diagnostic information to allow the user to try again successfully (I'll likely ask for some help with FindPackage(MUSIC) :) but for now can proceed with the use of CMAKE_PREFIX_PATH.)

[mdjurfeldt]

I'm not knowledgeable wrt CMake. Of course, if there is a way that is natural to CMake, then that is a good option. I also agree that a FindPackage for MUSIC seems best.

[nrnhines]

I started a branch hines/enable-music. The nrn/cmake/FindMusic.cmake is mostly nonsense at this point as it contains the hardwired prefix for the music installation. Ie. on my machine:

set(MUSIC_PREFIX "/home/hines/soft/MUSIC/install")

which comes from

cd $HOME/soft
git clone git@github.com:INCF/MUSIC.git
cd MUSIC
./autogen.sh
./configure --prefix=`pwd`/install
make
make install

I'm working on the needed extension to nrn/src/nrniv/CMakeList.txt but am stuck on a bad compile of netpar.cpp

hines@hines-t7500:~/neuron/music/build$ cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=install -DPYTHON_EXECUTABLE=`which python3` -DNRN_ENABLE_RX3D=OFF -DNRN_ENABLE_INTERVIEWS=ON -DNRN_ENABLE_MUSIC=ON
ninja

which stops with

[439/744] Building CXX object src/nrniv/CMakeFiles/nrniv_lib.dir/netpar.cpp.o
FAILED: src/nrniv/CMakeFiles/nrniv_lib.dir/netpar.cpp.o 
/usr/bin/c++ -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX=1 -DMPI_NO_CPPBIND=1 -DNRN_ENABLE_THREADS -DOMPI_SKIP_MPICXX=1 -Dnrniv_lib_EXPORTS -DCABLE=1 -DOOP=1 -DUSEBBS=1 -DUSECVODE=1 -DUSEMATRIX=1 -I/home/hines/soft/MUSIC/install/include -I../src/ivoc -I../src/nrncvode -I../src/nrniv -I../src/nrnoc -I../src/oc -I. -Isrc/nrncvode -Isrc/nrnjava -Isrc/nrnoc -Isrc/nrnpython -Isrc/oc -Isrc/parallel -Isrc/sundials -Isrc/sundials/shared -I../external/Random123/include -I../src -I../src/gnu -I../src/mesch -I../src/nrnmpi -I../src/nrnpython -I../src/parallel -I../src/scopmath -I../src/sparse -I../src/sparse13 -I../src/sundials -I../src/sundials/cvodes -I../src/sundials/ida -I../src/sundials/shared -I/home/hines/.pyenv/versions/3.10.4/include/python3.10 -Isrc/nrniv/oc_generated -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem ../external/iv/src/include -g  -O2 -Wno-write-strings -fPIC -std=c++14 -MD -MT src/nrniv/CMakeFiles/nrniv_lib.dir/netpar.cpp.o -MF src/nrniv/CMakeFiles/nrniv_lib.dir/netpar.cpp.o.d -o src/nrniv/CMakeFiles/nrniv_lib.dir/netpar.cpp.o -c ../src/nrniv/netpar.cpp
In file included from /home/hines/soft/MUSIC/install/include/music/port.hh:26,
                 from /home/hines/soft/MUSIC/install/include/music/setup.hh:27,
                 from /home/hines/soft/MUSIC/install/include/music/runtime.hh:26,
                 from /home/hines/soft/MUSIC/install/include/music.hh:21,
                 from ../src/ivoc/../neuronmusic/nrnmusic.h:8,
                 from ../src/nrniv/nrnmusic.cpp:2,
                 from ../src/nrniv/netpar.cpp:217:
/home/hines/soft/MUSIC/install/include/music/data_map.hh:46:13: error: ‘MPI’ does not name a type; did you mean ‘M_PI’?
   46 |     virtual MPI::Datatype type () = 0;
      |             ^~~
      |             M_PI

Feel free to push to the branch! After compiling is fixed, the nrniv/CMakeLists.txt file will need a line to link the music library and a section that creates the python module.

[ohm314]

Hi @nrnhines @mdjurfeldt : I'll take a look today and try to make some progress! Will post the relevant PR once I have something workable.

[mdjurfeldt]

The error which @nrnhines observed is that the C++ interface, which MUSIC uses, is missing in the MPI implementation. The C++ interface is deprecated in the standard so MUSIC should switch to the C interface. I'll resolve this and get back to you. If it is easy for you to use an MPI version with C++ interface meanwhile, we can work in parallel. @ohm314

[ohm314]

Yeap, the mpich package on macos still has it available so I managed to build with that

[nrnhines]

I realize putting the tests for MPI, Python, and Cython into FindMusic.cmake is a mistake. I guess those requirements should be moved into the top level CMakeLists.txt in the body of the if(NRN_ENABLE_MUSIC)

[ohm314]

Hi @mdjurfeldt , I think I have a version now that builds (see @nrnhines 's branch, or the PR mentioned above). I still have to figure out the python part, though and see if there are some tests to make sure this is functional. The main question is the MPI C++ API though. In NEURON we explicitly disable them, because many MPI implementations don't ship them anymore and they generally cause issues. I've set a condition to not disable them when MUSIC support is enabled, but I think it would be better to remove the C++ APIs, do you think this could be done relatively easily on the MUSIC side? It would make things much simpler and probably spare us a lot of trouble!

[mdjurfeldt]

Yes, I'm currently preparing a new MUSIC release with MPI C bindings only. I'll let you know when this is done.

[nrnhines]

I've replaced the <OS/table.h> with in src/nrniv/nrnmusic.cpp. Don't know if I got it transformed correctly as I was unable to get my mpich-3.3 to build music and so am stuck with openmpi. I'll hold off on committing it til the new MUSIC release is ready (unless, @ohm314 , you want to continue without having to build InterViews.).

[ohm314]

Ah great, @nrnhines ! I was wondering if OS/table.h could be easily replaced or not. Thanks for fixing this! I think we can probably wait a moment for the MPI C++ requirement to fall away from music and take it from there.

[mdjurfeldt]

Just FYI: I had other duties during the weekend, but have resumed work on the new MUSIC release. It is some work, but believe that it will be finished in a couple of days.

[mdjurfeldt]

@nrnhines @ohm314 Hi,

This took longer than expected, partly due to other duties. Before I make a new MUSIC release, could I ask you to checkout and try to use the feature branch switch-to-MPI-C-interface at git@github.com:INCF/MUSIC.git, i.e.:

git clone -b switch-to-MPI-C-interface git@github.com:INCF/MUSIC.git

?

[nrnhines]

Great! looking forward to trying it out. I'm away from my linux desktop til next Tuesday. Will be able to resume work on this then.

[ohm314]

Hi @mdjurfeldt I was on leave the last couple of weeks but I'll be happy to try next week and report back.

[nrnhines]

edit: Nevermind. Starting with a fresh clone solved the issue.

I'm having trouble building music 8ac4052a on my ubuntu 22.4

hines@hines-t7500:~/soft/MUSIC$ git status
On branch switch-to-MPI-C-interface
hines@hines-t7500:~/soft/MUSIC$ ./configure --prefix=`pwd`/install CXXFLAGS=-fPIC CFLAGS=-fPIC
make
...
libtool: link: g++ -I../src -I../src -I.. -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -pedantic -Wall -Wno-long-long -g -O3 -std=c++11 -o .libs/music music-music.o  ../src/.libs/libmusic.so ../mpidep/.libs/libmpidep.a -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_cxx -lmpi -Wl,-rpath -Wl,/home/hines/soft/MUSIC/install/lib
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_rank(ompi_communicator_t*)'
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_size(ompi_group_t*)'
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_group(ompi_communicator_t*)'
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_size(ompi_communicator_t*)'
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_is_initialized()'
/usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_size(ompi_datatype_t*)'

I did a make clean; make distclean. Do I need to start with a fresh clone?

[nrnhines]

@mdjurfeldt Please try the latest change to #1896 aee0a29 . It should build with

$ cmake .. -G Ninja -DCMAKE_INSTALL_PREFIX=install -DPYTHON_EXECUTABLE=`which python3` -DNRN_ENABLE_RX3D=OFF -DNRN_ENABLE_INTERVIEWS=OFF -DNRN_ENABLE_MUSIC=ON -DCMAKE_PREFIX_PATH=$HOME/soft/MUSIC/install

with interviews ON or OFF (just use the CMAKE_PREFIX_PATH for your installation location of the MUSIC switch-to-MPI-C-interface branch)

[ohm314]

Hi @mdjurfeldt , I finally started looking into this, this morning but I've noticed some issues.

I pulled your new branch, did a fresh build+install, then went to NEURON and tried rebuilding to see what happens. Unfortunately the build fails with multiple issues. Looking a bit into the MUSIC code I found a few possible problems (apologies, if it's actually just me being ignorant about how to build MUSIC and/or hook up the two pieces of software).

First of all I found here that you are still including a header that doesn't exist anymore (I guess your deprecated C++ interface?).

Second I found several instances, here is one for example, where you refer to functions that are not part of MPI's API.

    bool isFlushed () { return flushed; }
    int localRank () const { return mpi_get_rank (intercomm); }
    int remoteRank () const { return remoteRank_; }

Finally, at least multibuffer.hh seems to have similar problems. Am I missing something?

cheers

Omar

[mdjurfeldt]

Hi @ohm314,

I think you might have run into the same problem has @nrnhines did in his next but last comment: There are probably lingering automake generated files. Please do ./autogen.sh in the source tree and configure and make to correct this.

mpi_utils.hh is a new header that should exist in the new branch. It provides utility functions like mpi_get_rank which replace some short idioms which the MPI C++ interface previusly provided.

Please tell me if this solves the problem for you.

Best regards, Mikael

[ohm314]

Dang, I had done a clean and distclean, thought that would suffice. Just to be sure, I recloned the repo now and built from scratch. When building I see currently this error:

/bin/sh ../libtool  --tag=CXX   --mode=compile mpic++ -DHAVE_CONFIG_H -I. -I..    -I.. -std=c++17 -g -O2 -g -O3 -std=c++11 -MT libmusic_la-mpi_utils.lo -MD -MP -MF .deps/libmusic_la-mpi_utils.Tpo -c -o libmusic_la-mpi_utils.lo `test -f 'mpi_utils.cc' || echo './'`mpi_utils.cc
libtool: compile:  mpic++ -DHAVE_CONFIG_H -I. -I.. -I.. -std=c++17 -g -O2 -g -O3 -std=c++11 -MT libmusic_la-mpi_utils.lo -MD -MP -MF .deps/libmusic_la-mpi_utils.Tpo -c mpi_utils.cc  -fno-common -DPIC -o .libs/libmusic_la-mpi_utils.o
mpi_utils.cc:48:3: error: redefinition of 'mpi_get_size'
  mpi_get_size (MPI_Group group)
  ^
mpi_utils.cc:40:3: note: previous definition is here
  mpi_get_size (MPI_Comm comm)
  ^

(MPI_Group and MPI_Comm are actually typedefs for int, so it makes sense, but why am I the only one seeing this error?)

[mdjurfeldt]

@ohm314 OK, it was overly optimistic of me to rely on overloading there. Apparently MPI_Group and MPI_Comm boils down to the same basic type in your MPI implementation. I'll update the new MUSIC branch to use two distinct names for the calls on a group and the calls on a communicator.

[ohm314]

Yes, I'm using mpich on mac, maybe your MPI distribution does it slightly different.

[mdjurfeldt]

Hi @ohm314, I've now updated the branch. Please try again!

[ohm314]

Now, all builds perfectly.

[nrnhines]

@mdjurfeldt I was thinking about a CI test for this functionality and @ohm314 raised the same issue. It does not need to be run on every PR change but should certainly run before a release. Do you have a test already which exercises the NEURON functionality? Otherwise, if I were to start from 0, I guess the minimal test I'd prepare would be just a NEURON model with a single artificial cell with gid=10. I.e.

from neuron import h
pc = h.ParallelContext()
cell = IntFire1()
pc.set_gid2node(10, pc.id())
pc.cell(10, h.NetCon(cell, None))

Then, somehow MUSIC would run two instances of this NEURON model and connect them in a ping-pong net. Perhaps I'm mistaken in thinking that each NEURON instance thinks it is isolated in its own communicator with pc.id() == 0 and pc.nhost()==1. Note that the "NEURON" gid of the artificial cell is 10, but MUSIC would have to "alias" them to 0 and 1 so that on the 0th NEURON instance

nc = pc.gid_connect(music_gid_for_gid10_of_neuron_instance1, cell)

and on the 1th NEURON instance

nc = pc.gid_connect(music_gid_for_gid10_of_neuron_instance0, cell)

The nc.delay and nc.weight[0] of both nc could be set to 4 (ms) and 2 respectively And finally MUSIC would have to send a spike from the source music_gid_for_gid10_of_neuron_instance0 to get the ping-pong bouncing every 4 ms. (my apologies for having forgotten everything I knew about preparing MUSIC models.)

[mdjurfeldt]

The likely reason is lingering automake generated files. I suggest that you do:

./autogen.sh

in the source tree and then run configure and make again

Best regards, Mikael

Den ons 24 aug. 2022 14:42nrnhines @.***> skrev:

I'm having trouble building music 8ac4052a on my ubuntu 22.4

@.:~/soft/MUSIC$ git status On branch switch-to-MPI-C-interface @.:~/soft/MUSIC$ ./configure --prefix=pwd/install CXXFLAGS=-fPIC CFLAGS=-fPIC make ... libtool: link: g++ -I../src -I../src -I.. -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -pedantic -Wall -Wno-long-long -g -O3 -std=c++11 -o .libs/music music-music.o ../src/.libs/libmusic.so ../mpidep/.libs/libmpidep.a -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi_cxx -lmpi -Wl,-rpath -Wl,/home/hines/soft/MUSIC/install/lib /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to MUSIC::mpi_get_rank(ompi_communicator_t*)' /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference toMUSIC::mpi_get_size(ompi_group_t)' /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_group(ompi_communicator_t)' /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to MUSIC::mpi_get_size(ompi_communicator_t*)' /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference toMUSIC::mpi_is_initialized()' /usr/bin/ld: ../src/.libs/libmusic.so: undefined reference to `MUSIC::mpi_get_size(ompi_datatype_t*)'

I did a make clean; make distclean. Do I need to start with a fresh clone?

— Reply to this email directly, view it on GitHub https://github.com/neuronsimulator/nrn/issues/1894#issuecomment-1225670372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3R6CIFYD3BBHYHZ2RDFITV2YKBXANCNFSM52JCFZ4Q . You are receiving this because you were mentioned.Message ID: @.***>

[mdjurfeldt]

Dear @nrnhines and @ohm314,

Sorry for being absent from this discussion for so long.

I will still need to think about suitable tests, but here are two examples which seem to work for me:

testnrnmusic.tar.gz

Note that the build system still needs to be augmented to install the neuronmusic.so file along with the neuron python module.

Also, please take a look at some commits that I've pushed onto the branch github.com/mdjurfeldt/nrn/hines/enable-music.

In particular, there are two issues that we might need to discuss:

First, in commit b09872b6, I made sure that nrnmpi_undernrncontrol was not reset if nrnmusic is enabled. The reason for this is that I want NEURON to call nrnmusic_terminate in order to properly MUSIC-finalize the simulation when exiting.

Then, in commit 2d3f4a85, I made it possible for incoming spikes on a particular MUSIC index to be propagated to multiple neurons. I did this, by letting the PreSyn be involved in multiple NetCon:s. Is this sensible? Does it work together with all aspects of parallelization? (The motivation for this is that the user typically sets up complex connectivity from the MUSIC input port to populations on the receiving end.)

Do these changes look OK? Should I create a pull request?

Best regards, Mikael

[nrnhines]

Looks good to me. Go ahead and commit to the hines/enable-music branch or make a pull request from your fork.

[mdjurfeldt]

I've created PR #2084.

[nrnhines]

I'm getting correct results for

hines@michaels-macbook-pro testnrnmusic % mpirun -np 2 music test2.music
numprocs=1
Rank 0: Event (0, 0.001175) detected at 0
Rank 0: Event (0, 0.013825) detected at 0

but maybe you have an idea about what is wrong with

hines@michaels-macbook-pro testnrnmusic % mpirun -np 2 music test3.music
...
group= 1  rank= 0
1 0  call stdinit
group= 2  rank= 0
2 0  call stdinit
Error in MUSIC library: LOCAL Indices are not supported with MUSIC_ANYSOURCE
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

By the way, I am using an extensively hacked version of src/neuronmusic/setup.py.in which, with python3.11, generates a neuronmusic.cpython-311-darwin.so. Also note these tentative build instructions.

hines@michaels-macbook-pro-2 nrnmusic % git diff docs/cmake_doc/options.rst
diff --git a/docs/cmake_doc/options.rst b/docs/cmake_doc/options.rst
index a7e232a07..0c836387f 100644
--- a/docs/cmake_doc/options.rst
+++ b/docs/cmake_doc/options.rst
@@ -218,6 +218,9 @@ NRN_ENABLE_MUSIC:BOOL=OFF
   Enable MUSIC. MUlti SImulation Coordinator.

   MUSIC must already be installed. See https://github.com/INCF/MUSIC.
+  Hints for MUSIC installation: use the switch-to-MPI-C-interface branch.
+  Python3 must have mpi4py and cython modules. I needed a PYTHON_PREFIX, so
+  on my Apple M1 used: ``./configure --prefix=`pwd`/musicinstall PYTHON_PREFIX=/Library/Frameworks/Python.framework/Versions/3.11``

   MPI and Python must be enabled.

@@ -231,6 +234,9 @@ NRN_ENABLE_MUSIC:BOOL=OFF
     /path/include/music.hh
     /path/lib/libmusic.so

+  With the music installed above, cmake configuration example is
+  ``build % cmake .. -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=install -DPYTHON_EXECUTABLE=`which python3.11` -DNRN_ENABLE_RX3D=OFF -DCMAKE_BUILD_TYPE=Debug -DNRN_CLANG_FORMAT=ON -DNRN_ENABLE_TESTS=ON -DNRN_ENABLE_MUSIC=ON -DCMAKE_PREFIX_PATH=$HOME/neuron/MUSIC/musicinstall``
+
 Python options:
 ===============

[mdjurfeldt]

Yes, sorry, there's an MPI optimization which is enabled by default. This is a bit stupid since local indices (= an enumeration of neurons on the local rank), which NEURON uses to identify neurons in the MUSIC interface rather than global indices (= an enumeration of all neurons over all ranks), are not supported by that optimization.

You can give --disable-anysource to the MUSIC configure script to disable the optimization.

I have been planned to fix this by implementing support for local indices for this optimization.

[nrnhines]

Yep. That was the problem. Everything working well now.

[nrnhines]

At this point, there is chance that, a successful build of #1896 after configuring with

-DNRN_ENABLE_TESTS=ON -DNRN_ENABLE_MUSIC=ON

will allow a successful

hines@michaels-macbook-pro build % ctest -R nrnmusic::music_tests
Test project /Users/hines/neuron/nrnmusic/build
    Start 62: nrnmusic::music_tests
1/1 Test #62: nrnmusic::music_tests ............   Passed    0.91 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.92 sec

[nrnhines]

From nm libnrniv.dylib|grep -i music | grep ' U ' it may be possible to dynamically load libmusic.so at run time. Just need to have pointer slots in libnrniv.dylib for

hines@michaels-macbook-pro-2 lib % nm libnrniv.dylib|grep -i music | grep ' U '
                 U __ZN5MUSIC10OutputPort7mapImplEPNS_8IndexMapENS_5Index4TypeEii
                 U __ZN5MUSIC14EventInputPort13makeConnectorENS_13ConnectorInfoE
                 U __ZN5MUSIC14EventInputPort3mapEPNS_8IndexMapEPNS_22EventHandlerLocalIndexEd
                 U __ZN5MUSIC14EventInputPortC2EPNS_5SetupENSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE
                 U __ZN5MUSIC15EventOutputPort10buildTableEv
                 U __ZN5MUSIC15EventOutputPort11insertEventEdNS_11GlobalIndexE
                 U __ZN5MUSIC15EventOutputPort13makeConnectorENS_13ConnectorInfoE
                 U __ZN5MUSIC15EventOutputPort3mapEPNS_8IndexMapENS_5Index4TypeE
                 U __ZN5MUSIC15EventOutputPortC2EPNS_5SetupENSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE
                 U __ZN5MUSIC15EventOutputPortD0Ev
                 U __ZN5MUSIC15EventOutputPortD1Ev
                 U __ZN5MUSIC15EventOutputPortD2Ev
                 U __ZN5MUSIC16PermutationIndexC1EPNS_11GlobalIndexEi
                 U __ZN5MUSIC4PortC2EPNS_5SetupENSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE
                 U __ZN5MUSIC5Setup12communicatorEv
                 U __ZN5MUSIC5SetupC1ERiRPPc
                 U __ZN5MUSIC7Runtime4tickEv
                 U __ZN5MUSIC7Runtime8finalizeEv
                 U __ZN5MUSIC7RuntimeC1EPNS_5SetupEd
                 U __ZN5MUSIC7RuntimeD1Ev
                 U __ZTIN5MUSIC10OutputPortE
                 U __ZTIN5MUSIC14EventInputPortE
                 U __ZTIN5MUSIC15EventOutputPortE
                 U __ZTTN5MUSIC14EventInputPortE
                 U __ZTVN5MUSIC16PermutationIndexE
                 U __ZTv0_n24_N5MUSIC15EventOutputPort10buildTableEv
                 U __ZTv0_n40_N5MUSIC14EventInputPort13makeConnectorENS_13ConnectorInfoE
                 U __ZTv0_n40_N5MUSIC15EventOutputPort13makeConnectorENS_13ConnectorInfoE
                 U __ZTv0_n48_N5MUSIC15EventOutputPortD0Ev
                 U __ZTv0_n48_N5MUSIC15EventOutputPortD1Ev

[nrnhines]

@mdjurfeldt I was unable to ping you from #2091. My question is whether it is possible to run nrniv -music from the terminal and interact with MUSIC.

[nrnhines]

@ohm314 @mdjurfeldt maybe it is time to approve #1896 as it does work when built on the machine in which it is to be used. Dynamic loading is a work in progress and associated with PR #2092

[nrnhines]

@mdjurfeldt Please see https://github.com/neuronsimulator/nrn/issues/2091#issuecomment-1319680592 I don't know how to link you to that issue so that you are notified about new content there.