search

KJ7LNW / xnec2c

Xnec2c is a high-performance multi-threaded electromagnetic simulation package to model antenna near- and far-field radiation patterns for Linux and UNIX operating systems.
https://www.xnec2c.org/
GNU General Public License v3.0
77 stars 16 forks source link

Crashes while saving .nec file #53

Closed morciej closed 1 month ago

morciej commented 1 month ago

I am running version 4.3.4 on Linux Mint 21.3 -- this version is in the Debian packages.

Three Observations:

  1. If "Apply" check mark is on, when I either save the .nec file from Edit window, or cause a Save by closing the main window with unsaved data and accepting the "Discard/Save?" prompt, the program crashes. After killing it, the file does turn out to be saved. Nonetheless, it is annoying because in the middle of a series of changes and runs, I regularly miss clicking the "Apply" check mark, which does come up on by default.
  2. I never yet figured out what is meant by "make changes to .nec file and continue by simulating with applied changes." The changes are ignored as far as I can tell, so I am forced to click "Apply" off, then save the file, close the program, and re-open every time I introduce a change, to see its effect in simulation. Re-running the Frequency Loop does not seem to take changes into account.
  3. Trying to re-open the file while it is already open has the same effect of crashing the program.

Three Questions:

  1. (if I missed something...) How to operate the program to test a series of changes to the .nec file WITHOUT having to close and re-open it repeatedly?
  2. Is it possible at all to keep the in-memory version of .nec file up to date with edits, with or without saving it immediately to disk?
  3. Is it possible to avoid crashing the program by automatically deactivating whatever "apply" check mark is doing, while the updated .nec file is being saved?

Thanks and 73 from VE7EVE

KJ7LNW commented 1 month ago

I am running version 4.3.4 on Linux Mint 21.3 -- this version is in the Debian packages.

That version is very old, and I have asked upstream Ubuntu and Debian to get to the latest version, but they have not back-ported to earlier distribution releases. There are many bug fixes in the latest version, and a few more in the master branch that have not yet been released as an official version. I recommend that you use the master branch and see if the problem persists:

Three Observations:

  1. If "Apply" check mark is on, when I either save the .nec file from Edit window, or cause a Save by closing the main window with unsaved data and accepting the "Discard/Save?" prompt, the program crashes. After killing it, the file does turn out to be saved. Nonetheless, it is annoying because in the middle of a series of changes and runs, I regularly miss clicking the "Apply" check mark, which does come up on by default.

I was able to reproduce the problem in your version, but not the latest version.

  1. I never yet figured out what is meant by "make changes to .nec file and continue by simulating with applied changes." The changes are ignored as far as I can tell, so I am forced to click "Apply" off, then save the file, close the program, and re-open every time I introduce a change, to see its effect in simulation. Re-running the Frequency Loop does not seem to take changes into account.

I am not sure that I understand. Where do you see "make changes to .nec file and continue by simulating with applied changes." ?

  1. Trying to re-open the file while it is already open has the same effect of crashing the program.

I was not able to reproduce this in the latest version.

Three Questions:

  1. (if I missed something...) How to operate the program to test a series of changes to the .nec file WITHOUT having to close and re-open it repeatedly?

upgrade.

  1. Is it possible at all to keep the in-memory version of .nec file up to date with edits, with or without saving it immediately to disk?

I do not believe so (but see below). This program was originally a port written by Neoklis 5B4AZ from the original FORTRAN to C. It follows the original program code to parse files and ininitialize structures, thus it needs to reread the entire file to generate wire segments for any changes.

Of course, modern software would indeed update the state of things in RAM to save later. When the software was developed, however, RAM was at a premium and compute power was meager. Programs were entered as punch cards (!) and "re-compiled" when any changes were made (ie, the cards were fed back into the machine).

The NEC2 software was not designed to have revisions made once the program was loaded. I agree that it would be a great feature to be able to make changes hot and even add some type of modeling interface. If someone were to implement that then I would be very interested in merging it.

However,

In recent versions of xnec2c, you can use the optimization settings to have it automatically reload and render every time you save. This is useful for programmatic external antenna generation, but I also like to use it by editing in a text editor (vim) so that is really loading my changes when I save the file. Navigate to "file->optimization settings" to have it automatically reload when the file is saved by an external program.

see also:

  1. Is it possible to avoid crashing the program by automatically deactivating whatever "apply" check mark is doing, while the updated .nec file is being saved?

yes, you only need to update to the latest release.

-Eric, KJ7LNW

Thanks and 73 from VE7EVE

morciej commented 1 month ago

Yes, I am old enough to remember punch card input :-) although thankfully, I never actually had to use it.

Thank you for your quick answers. I really need to use a second computer to run "latest-greatest-but-still-experimental" software. Thanks a lot, but this time I think I'll take a pass. Are you sure it's too much trouble to compile a .deb for a few common platforms and post it on Github? It's not a great idea to compile from scratch outside of Debian packaging system, but at least people wouldn't need to turn their internet-and-taxes desktops into development systems for software.

I understand that a complete re-write of FORTRAN code is not on the horizon either. I don't mean automatic translation to C - that's what you've done, correct? I mean making it into a modern object-oriented program, perhaps easier done by starting from scratch.

Or is it that no one really knows how NEC2 does its magic?

KJ7LNW commented 1 month ago

Yes, I am old enough to remember punch card input :-) although thankfully, I never actually had to use it.

Thank you for your quick answers. I really need to use a second computer to run "latest-greatest-but-still-experimental" software. Thanks a lot, but this time I think I'll take a pass. Are you sure it's too much trouble to compile a .deb for a few common platforms and post it on Github?

I believe get have had an auto build system, but I have not looked at it. I will see if I can come up with something.

It's not a great idea to compile from scratch outside of Debian packaging system, but at least people wouldn't need to turn their internet-and-taxes desktops into development systems for software.

I understand that a complete re-write of FORTRAN code is not on the horizon either. I don't mean automatic translation to C - that's what you've done, correct?

I am just the maintainer, not the original author. Originally, Neoklis 5B4AZ ported this from FORTRAN to C by hand (!); I am sure it was a huge undertaking. Many of the variable names are the same as from FORTRAN and there are some thread safety issues which is why it forks for parallelism instead of using threads. Ultimately it is the same basic code, but re-implemented in C which performs much better and is easier to maintain.

I mean making it into a modern object-oriented program, perhaps easier done by starting from scratch. Or is it that no one really knows how NEC2 does its magic?

There is a C++ version that someone implemented as a library. It has a command line text interface and could be used to replace front end that still reply rely on old FORTRAN code. However, it is not compatible with xnec2c (without a lot of work) and does not have a front end.

morciej commented 1 month ago

Thanks. Wow! I mean, that was a yeoman's job indeed by Neoklis. The main issue I guess is with Debian being so glacial in adoption of newer versions into Stable, so we can only hope that happens soon. 73

KJ7LNW commented 1 month ago

I believe get have had an auto build system, but I have not looked at it. I will see if I can come up with something.

Well, I gave a shot, but I do not have it working. If you would like to try to get the auto builds working then check out the wf-test branch: https://github.com/KJ7LNW/xnec2c/tree/wf-test

KJ7LNW commented 1 month ago

Also, this is another solution: https://flathub.org/apps/org.xnec2c.Xnec2c

morciej commented 1 month ago

In that case, why not Appimage? Dependencies would be satisfied, so no issue running it on any system. If Debian has issues, that's the way to go. I don't run Flathub because it keeps active all the time, and I fancy having a clean system.

KJ7LNW commented 1 month ago

I agree with that. I started building an appimage using the github tooling in the branch above, but it is not quite working yet.