Reason for nan energy levels?
Moderator: thorsten
-
- Posts: 31
- Joined: Thu 02 Sep 2021, 18:29
Reason for nan energy levels?
Hi All,
Trying to simulate a normal mode helix which looks good with addcurve but the antenna impedance is only 2 ohms compared with 36 ohms in practice.
I want to try simulating the helix as a copper to see if the copper restance would increase the antenna impedance. I use small cyclinders to build the helix.
I have tried copper material and PEC material but I always get -nan as the energy level.
Checking the forum I can not see any reason. Any thought on why I get -nan energy levels??
Script file, PEC-dump, CSX dump
Trying to simulate a normal mode helix which looks good with addcurve but the antenna impedance is only 2 ohms compared with 36 ohms in practice.
I want to try simulating the helix as a copper to see if the copper restance would increase the antenna impedance. I use small cyclinders to build the helix.
I have tried copper material and PEC material but I always get -nan as the energy level.
Checking the forum I can not see any reason. Any thought on why I get -nan energy levels??
Script file, PEC-dump, CSX dump
- Attachments
-
- Helix cylinders.png (96.25 KiB) Viewed 4282 times
-
- Helix Cylinders PEC_dump.png (154.84 KiB) Viewed 4282 times
-
helixMono.m
- (8.8 KiB) Downloaded 232 times
-
- Posts: 31
- Joined: Thu 02 Sep 2021, 18:29
Re: Reason for nan energy levels?
Has anyone used AddCylinder successfully? When constructing a helix using AddCylinder it seems to affect RunOpenEMS such that the reported energy levels are always 'nan'
If I change from AddCylinder to AddWire when constructing the helix then I do not get the 'nan' Energy Level and the simulation completes.
Does anyone know why using AddCylinder should cause RunOpenEMS to report 'nan' energy levels??
This is the output I get from RunOpenEMS when using AddCylinder with PEC material.
[@ 21s] Timestep: 2425 || Speed: 103.0 MC/s (8.998e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 42s] Timestep: 4850 || Speed: 106.8 MC/s (8.679e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m04s] Timestep: 7275 || Speed: 104.3 MC/s (8.890e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m27s] Timestep: 9700 || Speed: 98.3 MC/s (9.434e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m49s] Timestep: 12125 || Speed: 103.4 MC/s (8.971e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m12s] Timestep: 14550 || Speed: 95.9 MC/s (9.666e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m34s] Timestep: 16975 || Speed: 101.5 MC/s (9.131e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m56s] Timestep: 19400 || Speed: 102.9 MC/s (9.013e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 3m18s] Timestep: 21825 || Speed: 102.8 MC/s (9.016e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 3m40s] Timestep: 24250 || Speed: 102.1 MC/s (9.081e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
.
.
.
.
.
Thanks,
MPC.
If I change from AddCylinder to AddWire when constructing the helix then I do not get the 'nan' Energy Level and the simulation completes.
Does anyone know why using AddCylinder should cause RunOpenEMS to report 'nan' energy levels??
This is the output I get from RunOpenEMS when using AddCylinder with PEC material.
[@ 21s] Timestep: 2425 || Speed: 103.0 MC/s (8.998e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 42s] Timestep: 4850 || Speed: 106.8 MC/s (8.679e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m04s] Timestep: 7275 || Speed: 104.3 MC/s (8.890e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m27s] Timestep: 9700 || Speed: 98.3 MC/s (9.434e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 1m49s] Timestep: 12125 || Speed: 103.4 MC/s (8.971e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m12s] Timestep: 14550 || Speed: 95.9 MC/s (9.666e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m34s] Timestep: 16975 || Speed: 101.5 MC/s (9.131e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 2m56s] Timestep: 19400 || Speed: 102.9 MC/s (9.013e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 3m18s] Timestep: 21825 || Speed: 102.8 MC/s (9.016e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
[@ 3m40s] Timestep: 24250 || Speed: 102.1 MC/s (9.081e-03 s/TS) || Energy: ~ -nan (- 0.00dB)
.
.
.
.
.
Thanks,
MPC.
-
- Posts: 31
- Joined: Thu 02 Sep 2021, 18:29
Re: Reason for nan energy levels?
I tried running the script in win10 and Linux but the AddCylinder helix still provides 'nan' as the energy level?
Re: Reason for nan energy levels?
Well I can reproduce the problem and no, the cylinder should not do this. I will have to investigate deeper, this is indeed very strange...
Re: Reason for nan energy levels?
First finding, the cylinder number 50 (and maybe every 50th) is flat like a circle and somehow openEMS does not like this...
So you should make sure to avoid this at the moment, but I have to find out why, because a circle like this should not do anything!
Edit: Doing this makes it run as expected:
Finding out why will be the challenge, but not for tonight anymore ...
So you should make sure to avoid this at the moment, but I have to find out why, because a circle like this should not do anything!
Edit: Doing this makes it run as expected:
Code: Select all
if (Segment_number==(PerTurn_segments+1))
Segment_number=1;
turn_number=turn_number+1;
continue # <--
end;
Re: Reason for nan energy levels?
Okay openEMS is not directly responsible, your mesh is broken:
That is a bad mesh in y-direction that the simple float accuracy could not handle...
I'm a bit angry at myself that this was not the first thing I checked as the mesh is usually the first suspect...
Code: Select all
>> min(diff(mesh.x))
ans = 0.050000
>> min(diff(mesh.y))
ans = 6.8580e-16
>> min(diff(mesh.z))
ans = 0.094186
I'm a bit angry at myself that this was not the first thing I checked as the mesh is usually the first suspect...
-
- Posts: 31
- Joined: Thu 02 Sep 2021, 18:29
Re: Reason for nan energy levels?
Thorsten, big thanks,
It now works by removing DetectEdges.
You idea of checking the mesh minimum distances is very useful check!
min(diff(mesh.x))
min(diff(mesh.y))
min(diff(mesh.z))
I would recommend using it in any scripts.
Unfortunately using a copper material does not make a big difference in the impedance of the helix. I get Zin of 2.9R at resonance where as a physical sample is 36R. Amazingly the tuned frequency now matches physical results really well.
Thanks,
MPC.
It now works by removing DetectEdges.
You idea of checking the mesh minimum distances is very useful check!
min(diff(mesh.x))
min(diff(mesh.y))
min(diff(mesh.z))
I would recommend using it in any scripts.
Unfortunately using a copper material does not make a big difference in the impedance of the helix. I get Zin of 2.9R at resonance where as a physical sample is 36R. Amazingly the tuned frequency now matches physical results really well.
Thanks,
MPC.