The Numerical Electromagnetics code (NEC-2) is a computer code for analyzing the electromagnetic response of an arbitrary structure consisting of wires and surfaces in free space or over a ground plane. The analysis is accomplished by the numerical solution of integral equations for induced currents. The excitation may be an incident plane wave or a voltage source on a wire, while the output may include current and charge density, electric or magnetic field in the vicinity of the structure, and radiated fields. NEC-2 includes several features not contained in NEC-1, including an accurate method for modeling grounds, based on the Sommerfeld integrals, and an option to modify a structure without repeating the complete solution.
Created attachment 88369 [details] ebuild for nec2++
Created attachment 88370 [details, diff] patch for src/Makefile.in remove the -llapck_atlas gcc flag. Not needed on gentoo 2005-1, -latlas is enough when sci-libs/atlas is installed.
I put the ebuil
I put the ebuiléd in sci-misc/nec2++/
Hi Dominique. Thanks for the interest and your contributions! A few notes on the ebuild after a quick glance I had: patch src/Makefile.in ${FILESDIR}/Makefile.in.diff.. 1. this line should absolutely be in src_unpack 2. you should use epatch (and inherit eutils) 3. As I understand that patch removes linking to atlas implementation as provided by lapack? Why in such case you have lapack in DEPEND? Also, this patch should probably be made optional, on whether user wants lapack or proper atlas.. 4. Along the same lines: are any of the deps optional? If yes, they should depend on useflags (there are two for blas and lapack). make || die is there a problem with parallel make? If yes, you should try "emake MAKEOPTS=-j1", if not, a simple emake would do. Better yet, in the second case what's left of src_compile should be removed, as it is just the default function.. Minor things: pkg_postinst: "For full documentation.. you can utilize the "doc" use flag and install these docs if user sets it. Are there any download restriction on these docs, or is there stopping you form doing it this way? src_install - just like with dohtml you do not have to be in the dir from which you install with doins. doins example/* would have been fine - would save you a line or two :). George
Oh, regarding that patch: I suspect you can just use sed in this case. If this is indeed the case, then you really should - it is much easier that way: no extra files to produce and maintain, no need to reissue the patch if the code changes (or at least unlikely to require a change, in practice that pretty much never happens, save for the fix becoming unnecessary). In any case, sed or patch - it should be in src_unpack, as anything modifying the source. Otherwise you cannot unpack once and then run compile many times.. George
Gcc was issuing an error message with this flag. As I understand it, it is enough for gcc to have the -atlas flag and it will automatiquely link to the atlas in lapack. It was necessary to remove it because of the error message I get when it is 2 consecutive flags: -latlas -llapack_atlas. "gcc cannot find -llapack-atlas" (or something like that) even when it is installed. I think at the linking is automatiquely done in lapack and atlas when installing lapack-atlas. > 4. Along the same lines: are any of the deps optional? If yes, they should > depend on useflags (there are two for blas and lapack). Blas and lapack-atlas are needed. (I have not try to remove it from Makefile.in, and it is nothing about the dependencies in the doc, but it was necessary to me to install all the blas, lapack and lapack-atlas packages in order to get the program to compile.) I am looking the dependency now and -lapack-atlas have a ~sci-libs/blas-atlas dependency. As I understand it, it mean as, when blas in installed, portage will install blas-atlas. So it is enough with blas and lapack-atlas as dependency in this ebuild. But, both lapack-atlas and blas-atlas have libtool as dependency, so we can remove the libtool dependency from this ebuild. For doxygen, I think at it is needed to make the html files. I can see the doxygen logo when I look at those file with my navigator. > > make || die > is there a problem with parallel make? If yes, you should try "emake > MAKEOPTS=-j1", if not, a simple emake would do. Better yet, in the second case > what's left of src_compile should be removed, as it is just the default > function.. > I don't remember. But I beleive at it was no problem with it. Maybe a problem with the sandbox (sandbox violation) when installing the files, but I think at those sandbox problems in my box have a lot more to do with me that doesn't undertand the way portage is working with it, as something else. > Minor things: > > pkg_postinst: "For full documentation.. > you can utilize the "doc" use flag and install these docs if user sets it. Are > there any download restriction on these docs, or is there stopping you form > doing it this way? No, it is no download restriction and I don't try to do it with portage as they are not a part of the tarball. > > src_install - > just like with dohtml you do not have to be in the dir from which you install > with doins. doins example/* would have been fine - would save you a line or two > :). Don't remember, maybe some sanbox violation and I find at it was working that way, but if it is possible to simplify, it is just fine with me. Best, Dominique
(In reply to comment #5) > Oh, regarding that patch: I suspect you can just use sed in this case. If this > is indeed the case, then you really should - it is much easier that way: no > extra files to produce and maintain, no need to reissue the patch if the code > changes (or at least unlikely to require a change, in practice that pretty much > never happens, save for the fix becoming unnecessary). > In any case, sed or patch - it should be in src_unpack, as anything modifying > the source. Otherwise you cannot unpack once and then run compile many times.. > > George > I agree with you, but I was not aware of sed possibility when I made this ebuild. Dominique
(In reply to comment #6) > Gcc was issuing an error message with this flag. As I understand it, it is > enough for gcc to have the -atlas flag and it will automatiquely link to the > atlas in lapack. It was necessary to remove it because of the error message I > get when it is 2 consecutive flags: -latlas -llapack_atlas. "gcc cannot find > -llapack-atlas" (or something like that) even when it is installed. I think at > the linking is automatiquely done in lapack and atlas when installing > lapack-atlas. Ah, Ok, that makes sense. I guess this will have to be looked into in more details at the point when this ebuilds is to be processed for inclusion. At the very least it may need to be made aware of what bals or lapack profiles are activated. May be some patching/seding will be necessary, although it is possible that it may pick them up automatically.. > > 4. Along the same lines: are any of the deps optional? If yes, they should [skipped] Same as above - we just need to keep this in mind, - unfortunately I cannot do much at the moment with sci reorg underway, unfinished stuff with Ada and going on a vacation soon.., may be afterwards, if we can get somebody to maintain this ;). > But, both lapack-atlas and blas-atlas have libtool as dependency, so we can > remove the libtool dependency from this ebuild. libtool is in system (a list of packages considered necessary for a given profile) anyway, so, strictly speaking this dependency is not needed. However, as one might use (or setup his own) minimalistic profile not containing libtool or in case some replacement for portage comes around that treats packages in system somewhat differently, it is better to keep this in. The general (safe) rule is: if something is specifically using some package it should directly depend on it. If that package is only needed by its dependencies, than it should be in DEPEND of the concerned dependencies, not in the package in question.. > For doxygen, I think at it is needed to make the html files. I can see the > doxygen logo when I look at those file with my navigator. Yes, it is usually used like that. The question is - are these docs "mandatory" or optional? Also, are they big? If they are big or optional there may be use in stripping them off - this way you make user download less and not require an extra dependency. However for the package like this having docs is probably quite essential, so don't worry too much about them, unless there is a specific switch to configure or a make target disabling them.. The rest is similar to what I said in the other bug. I am just going to repeat my suggestion: please update these ebuilds incorporating the suggested fixes ;) And, thanks for your effort! George
(In reply to comment #8) > (In reply to comment #6) > on a vacation soon.., may be afterwards, if we can get somebody to maintain > this ;). Have nice vacation. > > > For doxygen, I think at it is needed to make the html files. I can see the > > doxygen logo when I look at those file with my navigator. > Yes, it is usually used like that. The question is - are these docs "mandatory" > or optional? Also, are they big? If they are big or optional there may be use > in stripping them off - this way you make user download less and not require an > extra dependency. However for the package like this having docs is probably > quite essential, so don't worry too much about them, unless there is a specific > switch to configure or a make target disabling them.. > No, they are not essential. It is the reference documentation for the classes in the nec2 library. They are for a programmer that want to link a program against this library. The user documentation is the 3 files I write about with the ewarn function. So, I am not sure. It is no configure option for the doxygen doc, but I think at it is good to have a use flag for the user doc, because it is 3 pdf files between 400kb and 1.7Mb each, and it is always the 3 same files with all the nec2 packages, so it is enough to install those files one time. Maybe at I must write a ewarn about that in each of those ebuilds. Those 3 files are the original nec2 documentation, and they are mandatory in order to be able to write some input files for the program. (They explain the math used in the program too.) The format of those input files is always the same, at least for the free nec2 programs as those ebuilds. It can be a few differences with commercial nec2 based softwares. > > And, thanks for your effort! > > George > You are welcome ! Dominique
(In reply to comment #9) > So, I am not sure. It is no configure option for the doxygen doc, but I think Then it is likely not worth trying to rip doxygen out, lets leave it as a "hard" dependency, plus produced html files should not be that big I understand? As for the pdf's: > at it is good to have a use flag for the user doc, because it is 3 pdf files > between 400kb and 1.7Mb each, and it is always the 3 same files with all the > nec2 packages, so it is enough to install those files one time. Hm, so, there are some docs that are common to all the packages and they have a significant size? Then they should be removed from all and provided as a separated package, perhaps nec2++-docs? Its installation may be made optional on doc use flag in other packages (whose dependency it should become). This way these docs are provided cleanly and only once.. What about the generated html files? Are they specific for each package or also common? In the latter case it makes sense to combine them together with pdf's in that separate package, otherwise they should be generated distinctly every time of course. > Those 3 files are the original nec2 documentation, and they are mandatory in > order to be able to write some input files for the program. (They explain the Ok then, looks like that docs package will have to be a hard dependency rather then optional, depending on doc use flag.. George PS BTW, if you will need to contact me on irc.freenode.net, my nick there is georges - I lost george some time ago and had to change it :(.
(In reply to comment #10) > (In reply to comment #9) > What about the generated html files? Are they specific for each package or also > common? In the latter case it makes sense to combine them together with pdf's > in that separate package, otherwise they should be generated distinctly every > time of course. > They are specific, nec2pp have 44 html files for 453kb in all. For xnec2c, it is the user manual of the interface, with 1 html file and a few pics, less as 600kb in all. Cassbeam have 2 files, one pdf and one ps. They are the same beside the format and the size. I think at it is enough to install only one, the pdf is more as 2 time smaller, so I would preffer to install it. But maybe as other user preffer the ps format. antennavis have one html file, 33.7 kb, and it is the programmer's documentation of togl, a tk open gl toolkit that is included with the program and not in gentoo. > > Those 3 files are the original nec2 documentation, and they are mandatory in > > order to be able to write some input files for the program. (They explain the > Ok then, looks like that docs package will have to be a hard dependency rather > then optional, depending on doc use flag.. > Which name for the ebuild. Something as nec2doc-1.0.ebuild ? Must i put some dependency in this ebuild? The nec2 packages will depend on it, but for this doc, it is just to download the files and copy them into /usr/share/doc/nec2doc Best, Dominique
I see at it is maybe another problem. I have amoung other the -O3 flag in portage, and this ebuild use it during the compilation. It is another ebuild for that program and I just checked it. http://bugs.gentoo.org/show_bug.cgi?id=136993 We can call it nr2. It is no configure in nr2, just a Makefile. In it is the following comment: # NOTE: Optimization flags will produce incorrect code on -O3. # Optimization -02 now appears to work fine. I run the 2 versions on the same input files, and I get some very small differences in the output files. So I must investigate it. The differences are so small, at I see no differences with the graphical viewers, but the date in the output files are not always exactly the same. In nr2, the flags are: g++ -Wall -g -DNEC_ERROR_CHECK -c -o With this ebuild, I get: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -O3 -march=pentium4 -pipe -msse -msse2 -mmmx -pipe -fomit-frame-pointer -fno-ident -fforce-addr -ftracer -fweb -fvisibility-inlines-hidden
> In nr2, the flags are: > g++ -Wall -g -DNEC_ERROR_CHECK -c -o > I am looking in gcc documentation, but I don't find -DNEC_ERROR_CHECK and I have no id
> In nr2, the flags are: > g++ -Wall -g -DNEC_ERROR_CHECK -c -o > I am looking in gcc documentation, but I don't find -DNEC_ERROR_CHECK and I have no idée what it mean...
(In reply to comment #11) I done a script to test the different versions. In the makefile of n2 are options to do the same nec2 as the one in this ebuild, it mean with atlas. I get exactly the same result with it, and with my ebuild and -O3 option (with atlas in both case, so I think at the diferences have to do with the use or not of Atlas). So I believe at it will be sure to use the -O3 option, but can be 100% sure because I have other optimisation flags as just -O3. No matter, the nec2 program is quite old now (1981), and the different versions have changed anything to the theory behind the internal of the program. They just have different error's marging. I think at incorporate the last advances in the field of antenna theory (by example in Ballanis, C.A., Antenna Theory
(In reply to comment #11) I done a script to test the different versions. In the makefile of n2 are options to do the same nec2 as the one in this ebuild, it mean with atlas. I get exactly the same result with it, and with my ebuild and -O3 option (with atlas in both case, so I think at the diferences have to do with the use or not of Atlas). So I believe at it will be sure to use the -O3 option, but can be 100% sure because I have other optimisation flags as just -O3. No matter, the nec2 program is quite old now (1981), and the different versions have changed anything to the theory behind the internal of the program. They just have different error's marging. I think at incorporate the last advances in the field of antenna theory (by example in Ballanis, C.A., Antenna Theory Analysis and Design, 2nd ed., John Wiley.) will introduce more differences in the result of some calculations. So we must focus on the -O3 issue.
(In reply to comment #13) > I am looking in gcc documentation, but I don't find -DNEC_ERROR_CHECK > and I have no id
(In reply to comment #13) > I am looking in gcc documentation, but I don't find -DNEC_ERROR_CHECK > and I have no idée what it mean... > It is in man gcc, just look for "-D" :) In a nutshell, this flag is directed toward the preprocessor; e.g. -DNEC_ERROR_CHECK will predefine the macro NEC_ERROR_CHECK as 1, hence if the source contains code such as #ifdef NEC_ERROR_CHECK .... stuff ... #endif "stuff" will be compiled and ignored otherwise. cheers, Markus
(In reply to comment #14) So, when I compile this ebuild with -O3 and -fforce-addr, the program give exactly the same results as with -O2, so the question is: Is it sure to test for -O3 and add -fforce-addr if needed, or is it best to force -O2? The speed difference between the 2 codes when running the program is very little, about 8% for -O3 with -fforce-addr, but the same when I have all my flags.
Created attachment 90764 [details] simplified ebuild for nec2++-1.1.1 Simplified the ebuild. Removed doxygen from the dependancies as the html files are allready compiled in the tarball and made those files (programmer's doc) dependent of the doc use flag. I choose the safe way for the optimisation. The ebuild will replace -O3 by -O2 if -O3 is present in the user configuration.
Created attachment 93055 [details] New ebuild for nec2++-1.1.1 Correction of -O<n> flag Some syntax improvments.
No releases since 2005
