Release Candidate for v0.0.35

Install support for openEMS

Moderators: thorsten, sebastian

Release Candidate for v0.0.35

Postby thorsten » Sat 07 Jan 2017, 12:22

Hi everybody,

I have uploaded an RC-1 for version v0.0.35 and would ask anyone currently using openEMS to give it a try and report problems (building or using).

Linux:
Code: Select all
cd /tmp
wget http://openems.de/download/src/openEMS-v0.0.35-rc1.tar.bz2
tar jxf openEMS-v0.0.35-rc1.tar.bz2
cd openEMS
./update_openEMS.sh /tmp/testing/openEMS

Note: This version reports itself as being v0.0.34 still (my mistake creating the src tar.)

Alternative:
Code: Select all
git clone --recursive https://github.com/thliebig/openEMS-Project.git
cd openEMS-Project
./update_openEMS.sh /tmp/testing/openEMS


Windows:
- Download openEMS_x64_v0.0.35-rc1.zip
- Unzip
- Use as usual

Changes:
- build fixes
- critical bug fix in waveguide ports
- fix for boxes defined in different coordinate systems
- other smaller fixes

Please go out and test... e.g. by running Tutorials and verifying your own projects...
Report which OS you have tried, Matlab or Octave.

I would like to release v0.0.35 soon.

regards
Thorsten
thorsten
 
Posts: 1053
Joined: Mon 27 Jun 2011, 12:26

Re: Release Candidate for v0.0.35

Postby Hale_812 » Wed 11 Jan 2017, 09:18

Unzip and overwrite. Looks like there are no incompatibilities and broken dependencies.

Will you fix CSXGeomPlot.m with non-locking program call for widows in the release? like below, or something more sophisticated
Code: Select all
if isunix
   command = [AppCSXCAD_bin ' --disableEdit ' args_string ' ' CSX_filename];
else % assume windows
   command = ['start /B /I ' AppCSXCAD_bin ' --disableEdit ' args_string ' ' CSX_filename];
end

...maybe including "try system("taskkill /IM AppCSXCAD.exe"); end_try_catch;"

Again, many thanks for your great project!


......
oh, the computation got slower with more steps until -30 dB decay is reached. Win7x64

Did you reduce the RAM required at operator building step?

welll... I wonder, is it still possible to speed things up with nVidia CUDA-C.
Hale_812
 
Posts: 84
Joined: Fri 13 May 2016, 02:54

Re: Release Candidate for v0.0.35

Postby thorsten » Wed 11 Jan 2017, 18:31

Will you fix CSXGeomPlot.m with non-locking program call for widows in the release? like below, or something more sophisticated

Well I guess I will rather not put this in this release as I'm not sure what it will cause. But remind me to take a look at it for the next one.
For yourself you can of course always patch it like this.

oh, the computation got slower with more steps until -30 dB decay is reached. Win7x64

Did you reduce the RAM required at operator building step?

As I recall I have done no changes concerning the building or iteration engine. Can you be more specific?

welll... I wonder, is it still possible to speed things up with nVidia CUDA-C.

Sure, give it a try ;)
But this would be a major undertaking, as not only the operator and engine, but most of the processing and other surroundings would need to be rewritten too...
I do not see this happen any time soon, at least not from me.

regards
Thorsten
thorsten
 
Posts: 1053
Joined: Mon 27 Jun 2011, 12:26

Re: Release Candidate for v0.0.35

Postby jockeosth » Wed 11 Jan 2017, 20:50

Hi

It compiles and works for me. I compile from source and use Linux Gentoo and Octave.
Used external libraries:
CSXCAD -- Version: v0.6.1-5-g7e25045
hdf5 -- Version: 1.8.18
compiled against: HDF5 library version: 1.8.18
tinyxml -- compiled against: 2.6.2
fparser
boost -- compiled against: 1_62
vtk -- Version: 6.1.0
compiled against: 6.1.0

Thanks for great project.

Best regards
Joakim
jockeosth
 
Posts: 5
Joined: Wed 11 Jan 2017, 20:24

Re: Release Candidate for v0.0.35

Postby thorsten » Wed 11 Jan 2017, 21:33

It compiles and works for me. I compile from source and use Linux Gentoo and Octave.

I think that is the first feedback for Gentoo, good to know. Thanks for testing!
thorsten
 
Posts: 1053
Joined: Mon 27 Jun 2011, 12:26

Re: Release Candidate for v0.0.35

Postby Hale_812 » Thu 12 Jan 2017, 09:25

thorsten wrote:As I recall I have done no changes concerning the building or iteration engine. Can you be more specific?

Well, it is possible the current problem was too small and the operator building did not commit RAM enough to jump above the general OS used RAM "noise". (when monitoring with Win7 task manager).
This week I will combine all the parts I am working on, and see how it handles the large-scale problem. Last time we were discussing it, the operator building step was taking around 2x of the RAM, necessary for the following computation.

I'm not sure what it will cause

technically, it is a standard way to start a non-blocking process from any windows console/batch-script.
It just starts independent "/I" (parallel) commandline task (with or without "/B" console window), where the command is executed immediately. The general disadvantage is that it does not return any handle or process identifier for the started process. So, you have to monitor change in procIDs manually, if needed. Of course, there can always be better ways.
Hale_812
 
Posts: 84
Joined: Fri 13 May 2016, 02:54

Re: Release Candidate for v0.0.35

Postby Henkel » Sun 22 Jan 2017, 22:54

No problems thus far on windows - drop in replacement.

Might have found a bug, though. I've found that I can never have more than 14 items of a particular type of primitive. Adding any more than that results in a 'Warning: Unused primitive (type: Box) detected in property: patch!'. Not sure if it's only related to type Box (I'm doing a microstrip yagi, so lots of patches).

I have confirmed that:
a) it doesn't matter what 'Box' instance I remove - removing any of them silences the warning.
b) the warning does not appear to relate to the location/size of any of the boxes
c) simulation output is garbage with 15 items, but just fine with 14 items. Had a friend confirm my output with 14 items against CST.

Not sure if that rings of a bell...

And no, this didn't start with v0.35...saw it on 0.34 as well.

-j
Henkel
 
Posts: 4
Joined: Sun 22 Jan 2017, 22:39

Re: Release Candidate for v0.0.35

Postby thorsten » Sun 22 Jan 2017, 23:37

Might have found a bug, though. I've found that I can never have more than 14 items of a particular type of primitive.

That sounds very odd and I would have no idea how that should be happening. Can you create a simple example showing the problem and attach the m-file?

regards
Thorsten
thorsten
 
Posts: 1053
Joined: Mon 27 Jun 2011, 12:26

Re: Release Candidate for v0.0.35

Postby thorsten » Sun 22 Jan 2017, 23:43

I just gave this a quick test by replacing the stub from the MSL_NotchFilter tutorial by 20 pieces (boxes).
Code: Select all
%% Filter-stub
for n=1:20
  start = [-MSL_width/2,  MSL_width/2+(n-1)/20*stub_length, substrate_thickness];
  stop  = [ MSL_width/2,  MSL_width/2+(n)/20*stub_length, substrate_thickness];
  CSX = AddBox( CSX, 'PEC', 999, start, stop );
endfor

I get no warning and the same result as with one solid box.
It must have something to do with your setup. I do not see how this could be a general bug...

regards
Thorsten
thorsten
 
Posts: 1053
Joined: Mon 27 Jun 2011, 12:26

Re: Release Candidate for v0.0.35

Postby Henkel » Mon 23 Jan 2017, 04:26

Well, it certainly wouldn't surprise me if the problem is in my meshing....

Will post the files in a day or two if I don't figure it out. Unfortunately, my scripts and structure creation depends on quite a few helper functions. Perhaps I should comment & clean before inflicting them on someone else...

BTW, you've created quite a wonderful package. I've showed openems to a few of my antenna engineer friends who use CST and HFSS, and they were quite impressed. Though my wife is not thrilled the consequent plethora of old laptops now serving as remote SSH nodes downstairs... :)

-j
Henkel
 
Posts: 4
Joined: Sun 22 Jan 2017, 22:39

Next

Return to Install

Who is online

Users browsing this forum: No registered users and 1 guest

MediaWiki Appliance - Powered by TurnKey Linux