Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.04%. Comparing base (eef4d9c) to head (5a52b55).
⚠️ Report is 56 commits behind head on master.

@@            Coverage Diff             @@
##           master    #3635      +/-   ##
==========================================
- Coverage   68.55%   68.04%   -0.51%     
==========================================
  Files         686      686              
  Lines      116791   110907    -5884     
==========================================
- Hits        80065    75467    -4598     
+ Misses      36726    35440    -1286     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

✔️ 54ea798 -> artifacts URL

So most of this works, except for Linux wheels on Azure. For some reason, MPI complains with:

======= Testing MPICH ========
+ mpirun.mpich -n 2 /home/vsts/work/1/s/nrn_test_venv_311/bin/python src/parallel/test0.py -mpi --expected-hosts 2
Warning: no DISPLAY environment variable.
--No graphics will be displayed.
Warning: no DISPLAY environment variable.
--No graphics will be displayed.
I am 0 of 1
numprocs=1
MPI Error : #ranks (1) different that the expected (2)
I am 0 of 1
numprocs=1
MPI Error : #ranks (1) different that the expected (2)

Maybe something changed on Azure infra? But then I would expect it to fail on other PRs as well, but it's only failing for this one. Note that mpi4py is always built from source, so I don't think it makes a difference. I also haven't made any changes that have to do with MPI.

@nrnhines any ideas?

✔️ d37716b -> artifacts URL

any ideas

What I'm experiencing is that I can download the wheel artifacts and install for python3.14 and both mpich and openmpi are working with it. i.e. VERSION 9.0.0-25-gd37716bdf jelic/py314 (d37716bdf). But note that the mpi library that is loaded (e.g possibly specified with LD_LIBRARY_PATH) has to be consistent with the mpirun.

~/Downloads$ export LD_LIBRARY_PATH=$HOME/soft/mpich/lib
~/Downloads$ $HOME/soft/mpich/bin/mpirun -n 2 python $HOME/neuron/nrn/src/parallel/test0.py
numprocs=2
I am 0 of 2
I am 1 of 2
~/Downloads$ unset LD_LIBRARY_PATH
~/Downloads$ mpirun.openmpi -n 2 python $HOME/neuron/nrn/src/parallel/test0.py
numprocs=2
I am 1 of 2
I am 0 of 2

So it seems that the CI portion of the problem is the test part.

any ideas

I'm not at all familiar with update-alternatives. To make sure it is working properly, I would print the path of the libmpi that was dynamically loaded and make sure that is consistent with the mpirun. I.e are we certain that in the execution of

mpirun.mpich -n 2 /home/vsts/work/1/s/nrn_test_venv_314/bin/python src/parallel/test0.py -mpi --expected-hosts 2

that the mpich verson of libmpi.so was dynamically loaded. E.g. was that ensured by

sudo update-alternatives --set mpi-x86_64-linux-gnu /usr/include/x86_64-linux-gnu/mpich

I'm looking at the use of load_mpi in src/nrnmpi/nrnmpi_dynam.cpp and on first attempt it appears to dlopen the filename "libmpi.so" without a full path, then, if it exists, the path specified by the environment variable MPI_LIB_NRN_PATH, and finally "libmpich.sh" without a full path. The last is intended as a fallback for cray systems.

Grok says we can use ldconfig -p | grep libmpi.soto list the full path. On my machine.

$ ldconfig -p | grep libmpi.so
	libmpi.so.40 (libc6,x86-64) => /home/hines/soft/openmpi/lib/libmpi.so.40
	libmpi.so.40 (libc6,x86-64) => /lib/x86_64-linux-gnu/libmpi.so.40
	libmpi.so (libc6,x86-64) => /home/hines/soft/openmpi/lib/libmpi.so

which seems ok. Unfortunately, ldconfig -p ignores LD_LIBRARY_PATH

$ export LD_LIBRARY_PATH=$HOME/soft/mpich/lib
$ ldconfig -p | grep libmpi.so
	libmpi.so.40 (libc6,x86-64) => /home/hines/soft/openmpi/lib/libmpi.so.40
	libmpi.so.40 (libc6,x86-64) => /lib/x86_64-linux-gnu/libmpi.so.40
	libmpi.so (libc6,x86-64) => /home/hines/soft/openmpi/lib/libmpi.so

✔️ 7c1a2ba -> Azure artifacts URL

✔️ 7c1a2ba -> artifacts URL

✔️ b30a4bb -> Azure artifacts URL

✔️ b30a4bb -> artifacts URL

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

✔️ 5a52b55 -> Azure artifacts URL

✔️ 5a52b55 -> artifacts URL

I don't have anything else to add here, things look reasonable to me.