xnec2c v4.4.16 is now available in MacPorts

[vk1kcm]

Just a FYI,
I've submitted a port for xnec2c to MacPorts and it's now in the ports tree.

This means, on macOS with MacPorts installed and up-to-date, you can do:

sudo port install xnec2c

I would recommend switching gtk3 to use the Quartz backend rather than X11, see the port notes for details via

port notes xnec2c

Carl,
vk1kcm.

[KJ7LNW]

Awesome, thank you for putting that together! I do not have an OSX system, so I have no way to test switching to Quartz, however I will add these instructions to the documentation next time I do a release.

Will it automatically update when a new release comes out? If not how does the update get triggered?

[KJ7LNW]

@vk1kcm, will it automatically update when a new release comes out? If not how does the update get triggered?

[KJ7LNW]

I just released 4.4.17. Are you able to update that in MacPorts?

If you can tell me how to update it in the future, that would be great also.

[vk1kcm]

Hi, Apologies for not getting back to you. Updates are done manually. Anyone can submit a PR to the MacPorts repo with the update and once it gets through the approval process it will be applied.

I've had a hell of a few months here, but I'll get the port updated to 4.4.17 ASAP.

Carl.

[KJ7LNW]

Awesome, thank you for taking care of that. I only have Linux, so I do not have a good way to test on OSX.

Let me know if you have any trouble with the build. I am curious to know how it works!

[vk1kcm]

The port has been updated to 4.4.17. There were no showstopper problems with the build. There's one build warning that appears against a number of source files from including common.c.

In file included from ./shared.h:23:
./common.h:1515:25: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
 1515 | void xnec2c_set_omp_cpus();
      |                         ^
      |                          void
1 warning generated.

But otherwise it builds cleanly on Apple Silicon (ARM Aarch64) with Clang. You can see the build logs at https://ports.macports.org/all_builds/?port_name=xnec2c

It does generate some Gtk warnings when running, for example;

(xnec2c:83099): Gtk-WARNING **: 18:34:34.721: Can't set a parent on widget which has a parent
[warn] ATLAS, Threaded was not detected: Unable to set the mathlib index to 0

But they don't seem to have any bad effect on what's displayed.

I'll attach some screenshots of it running below.

Carl,
vk1kcm.

[KJ7LNW]

Awesome. If you run it with xnec2c at a terminal, does it detect the number of processors on your system?

[info] Detected 32 CPUs

[warn] ATLAS, Threaded was not detected: Unable to set the mathlib index to 0

If you like to experiment, you could see if OpenBLAS or Atlas or Intel MKL is available for your platform. If it can find the libraries, it will use them. See File->Math Libs

[vk1kcm]

Awesome. If you run it with xnec2c at a terminal, does it detect the number of processors on your system?

No, not when compiled with clang, but I tried recompiling it with gcc 14 and it does detect 10 threads.
Apparently OpenMP is not supported with native clang so I'm going to switch the port over to using gcc instead.

If you like to experiment, you could see if OpenBLAS or Atlas or Intel MKL is available for your platform. If it can find the libraries, it will use them. See File->Math Libs

I have OpenBLAS installed but by default it doesn't find the .dylib libraries. Here's a patch to mathlib.c to fix that.

mathlib.patch

Testing with OpenBlas is interesting. It's certainly hitting contention so using OPENBLAS_NUM_THREADS=1 and the parallel benchmark against 10-80m_windom.nec gets the following;

Selected LAPACK+BLAS:
   0.433460 seconds (-j 10)
   0.662529 seconds (-j  5)
   1.613666 seconds (-j  2)
   3.161898 seconds (-j  1)
NEC2 Gaussian Elimination:
   0.457183 seconds (-j 10)
   0.718879 seconds (-j  5)
   1.750651 seconds (-j  2)
   3.411538 seconds (-j  1)

Best Mathlib: Selected LAPACK+BLAS (-j 10): 0.433460 seconds

The MacPorts port creates an application bundle, and running it via double clicking on the application means you can't specify environment variables (at least not without some terminal trickery) so in the current state, I'm not sure it's worth adding OpenBLAS to the port given the problems with congestion. However;
Taking a quick look at the OpenBLAS documentation, they recommend that if your application is multithreaded, then you programatically set OpenBLAS number of threads to 1 via openblas_set_num_threads(1) (See http://www.openmathlib.org/OpenBLAS/docs/faq/#how-can-i-use-openblas-in-multi-threaded-applications) Given how problematic OpenBLAS threading vs xnec2c multiprocessing is, can I recommend that instead?

Carl.

[vk1kcm]

Actually, I just stuck
setenv("OPENBLAS_NUM_THREADS", "1", 0);
at line 149 of main.c and that worked.

[KJ7LNW]

I'm looking into adding the environment variable since we're dynamic loading the modules, I don't want to have to add additional structure to reach out to the function that is not necessarily linked to the application.

I'm creating command line options to integrate those, I will push them in the next day or two.

[KJ7LNW]

The following commits wrap this up. Please test it from the master commit and see if it works the way you expect it to, including the optional arguments to set the number of threads if you wish to.

Increasing openblas threads above 1 is useful if you have more processors than frequencies. So if you have 120 CPUs and 30 frequencies, then you could set --openblas-threads 4.

• 3ea6ad9 mathlib: add MacOS MacPorts OpenBLAS detection
• 8d3bc03 mathlib: convert from index-based to ID-based configuration
• 64c95bc main/utils: add thread count control options

[vk1kcm]

Apologies for the delay, life gets in the way.

I've done some basic tests on the new code and it all seems to work nicely here. It finds the MacPorts OpenBLAS library, even if configure doesn't find the headers and seems to work fine. Setting --openblas-threads above 1 works as I can see the contention. MacPorts doesn't have a working ATLAS port and Intel MKL is x86/Intel GPUs only so I can't test the other options.

One other thing, the benchmarks help doesn't mention the new options.

These patches address everything I noted above. Thanks!

[KJ7LNW]

Thank you for testing that, I really appreciate your help! Perhaps I can get this all buttoned up and do another release before the end of the year.