NixOS support

[pdg137]

Is anyone interested in helping add this package to NixOS? I don't know much about the software or antenna design in general but I'd like to learn, so I started a branch here to add OpenNEC:

https://github.com/pdg137/nixpkgs/tree/opennec

If you want to try it, here's one way: install nix on any Linux distribution, save the following as shell.nix, and run nix-shell:

let
  # https://github.com/pdg137/nixpkgs/tree/opennec from 2026-03-21
  version = "c686d74cb8b7fff678c2ea4ad1805794b9811f5f";
  nixpkgs = fetchTarball {
    name = "nixpkgs-${version}";
    url = "https://github.com/pdg137/nixpkgs/archive/${version}.tar.gz";
    sha256 = "1ncp8i0aqfmf25qbmim0zw316x4mhkydfgx3g2pixkniymvsarr3";
  };
  pkgs = import nixpkgs {};
in
pkgs.stdenv.mkDerivation {
  name = "shell";
  buildInputs = [
    pkgs.opennec
  ];
}

This will download and build OpenNEC (with OpenBLAS) and drop you into a shell with the onec executable on your path. I installed the tests in the installation directory along with the executable so it's easy to try them out; onec seems to at least run example5.out, generating some kind of output.

What else can I try to test it out? Is there a way to run all the files from the test suite and know that everything worked? Is there an example program that I can try linking to the shared library?

[maurymarkowitz]

Hey pdg!

I think what you're looking for is the -r command line switch. You can use this with a path or a glob and it will recurse down the directory tree looking for all of those files. So for instance:

./onec -r ./necfiles/*.nec

I added this for exactly the use-case you're asking about, it made testing on my machine so much easier.

[pdg137]

Hey, thanks for the quick reply.

I guess you mean onec -r ./necfiles since otherwise it will just expand out to a specific (small) list of files?

I was doing something similar with a find command. Either way, what happens to me is that it seems to get stuck on validation_tests/patch_area.deck, sitting at 100% CPU for at least several minutes. Almost everything else is instantaneous and with that file removed, it gets through the whole set in about a minute on my laptop.

There are various warnings and error messages along the way, like

Processing 264 of 731: test/cocoaNEC examples/NC/OCF sweep.nec...
Error evaluating formula '(w*2)*fraction-w-0.05' at position 14 on card 8
intx: integration did not converge (degenerate geometry?); results may be inaccurate
intx: integration did not converge (degenerate geometry?); results may be inaccurate
intx: integration did not converge (degenerate geometry?); results may be inaccurate
intx: integration did not converge (degenerate geometry?); results may be inaccurate
intx: integration did not converge (degenerate geometry?); results may be inaccurate
...

Is that about what you expect? And is there any automated way to check that the output is good, or is it enough of a test just to know that it made it through all the files?

[maurymarkowitz]

since otherwise it will just expand out to a specific (small) list of files

I should have added quotes. onec -r "./necfiles/*.nec" should do the trick. If it doesn't, let me know.

sitting at 100% CPU for at least several

Ahhh, that is interesting. I'm looking at this now.

UPDATE: this was an error in the deck itself, two of the lines were reversed. I'll check in a fixed version.

'(w*2)*fraction-w-0.05'

This is an NC conversion issue, there's a float fraction in the code that is never set to a value, so it's not being translated into a SY in the nec. So fraction causes an error, the value of the formula goes to zero, and boom. I'll get this fixed shortly.

I do need to improve the warnings in the NC code, a lot of these files can't be directly converted and it should be more verbal about these issues.

[pdg137]

I should have added quotes. onec -r "./necfiles/*.nec" should do the trick. If it doesn't, let me know.

That does seem to work. (With test instead of necfiles of course.) Are you intentionally skipping the .deck files in there?

So after it's done, is there any way to check that the output was good or is just running through them supposed to be a sufficient test?

[maurymarkowitz]

That does seem to work

Ok, good. I didn't notice this before because on my machine the path has spaces and I need to quote every time, so it "just worked" whenever I tried it.

is there any way to check that the output was good

If there was a fatal, you'll get a code. But in a batch the only way to know is to examine the .out file. Generally, if it's zero bytes the file didn't process. Yes, this is the way it worked in previous programs, there was no way to indicate in the file that something went wrong (there are some messages, but you have to parse them out).

I'm going to leave this one open for now, because it seems like you're hitting test cases that don't fail on my machine. I'm particularly interested in those "integration did not converge", because if they are due to zero radius then I can add an explicit error for them instead of those indecipherable ones. Please let me know!

[pdg137]

I'm particularly interested in those "integration did not converge"

Okay, cocoaNEC examples/NC/optimization example.nec and cocoaNEC examples/NC/OCF sweep.nec give hundreds of "integration did not converge" errors.

But there are plenty that just give zero-size output, like simple.nec:

$ onec /nix/store/mkq0ylz3fgycgc97wxnyl9bqxr8dfg7x-OpenNEC-1.2.0/share/doc/onec/test/simple.nec -o /tmp/test.out

Failed to initialize calculation defaults (no valid geometry)

$ ls -l /tmp/test.out

-rw-r--r-- 1 paul paul 0 Mar 23 09:49 /tmp/test.out

[maurymarkowitz]

I've added an additional pre-calculation test to look for zero-length and zero-radius wires, so it will no longer attempt to calculate them and spam the integration error. Now you'll get an explicit error on the line that failed and it will exit.

I also added a test during NC import (which is where the example.nec and sweep.nec came from) to warn if the resulting deck will need work (in this case, manually setting the values of y and fraction, respectively). I'm wondering if I should not output the deck at all in this case.

And I should have been more clear: yes, there are a number of decks in the folders that fail to calculate, but those are in the original files. simple.nec, for instance, really does have no geometry and should fail. I think I should just remove those from test.

I the meantime I have moved the "originals" out to a new examples folder, leaving just the test files I made in test. I removed all the conversion artifacts as well - the .nec files in cocoaNEC, for instance.

Still working on a scoop issue, should have a build for you shortly.

[pdg137]

Okay, if you pick out the ones that are "supposed" to pass that would be a great way to verify that my build works.

It would also be helpful to have an example C program to compile against the shared library, so I can make sure I'm installing that correctly.

[maurymarkowitz]

I have added a first pass at a user manual that includes how to call the library from C programs. Let me know how it looks!

I also changed the way the output works to better match what NEC does. Now it will produce a non-empty OUT file as long as the deck can be properly read. I'm debating whether it should do the same even if there are "bad cards", but for now any deck that can be read should generate something.

I moved all of the example files I found out of test and into examples. I also added a script that will run them all and then search the results for empty files and errors. I also added the two output files from the script when I run it on my machine so you can compare notes.

There was also a rather nasty bug in the reflection that I fixed, but it only appeared on large models so it wasn't something you might have seen.