Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 13
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
No birthdays today

Next birthdays
05/14 hvguy (41)
05/14 thehappyelectron (14)
05/14 Justin (2024)
Contact
If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.


Special Thanks To:
  • Aaron Holmes
  • Aaron Wheeler
  • Adam Horden
  • Alan Scrimgeour
  • Andre
  • Andrew Haynes
  • Anonymous000
  • asabase
  • Austin Weil
  • barney
  • Barry
  • Bert Hickman
  • Bill Kukowski
  • Blitzorn
  • Brandon Paradelas
  • Bruce Bowling
  • BubeeMike
  • Byong Park
  • Cesiumsponge
  • Chris F.
  • Chris Hooper
  • Corey Worthington
  • Derek Woodroffe
  • Dalus
  • Dan Strother
  • Daniel Davis
  • Daniel Uhrenholt
  • datasheetarchive
  • Dave Billington
  • Dave Marshall
  • David F.
  • Dennis Rogers
  • drelectrix
  • Dr. John Gudenas
  • Dr. Spark
  • E.TexasTesla
  • eastvoltresearch
  • Eirik Taylor
  • Erik Dyakov
  • Erlend^SE
  • Finn Hammer
  • Firebug24k
  • GalliumMan
  • Gary Peterson
  • George Slade
  • GhostNull
  • Gordon Mcknight
  • Graham Armitage
  • Grant
  • GreySoul
  • Henry H
  • IamSmooth
  • In memory of Leo Powning
  • Jacob Cash
  • James Howells
  • James Pawson
  • Jeff Greenfield
  • Jeff Thomas
  • Jesse Frost
  • Jim Mitchell
  • jlr134
  • Joe Mastroianni
  • John Forcina
  • John Oberg
  • John Willcutt
  • Jon Newcomb
  • klugesmith
  • Leslie Wright
  • Lutz Hoffman
  • Mads Barnkob
  • Martin King
  • Mats Karlsson
  • Matt Gibson
  • Matthew Guidry
  • mbd
  • Michael D'Angelo
  • Mikkel
  • mileswaldron
  • mister_rf
  • Neil Foster
  • Nick de Smith
  • Nick Soroka
  • nicklenorp
  • Nik
  • Norman Stanley
  • Patrick Coleman
  • Paul Brodie
  • Paul Jordan
  • Paul Montgomery
  • Ped
  • Peter Krogen
  • Peter Terren
  • PhilGood
  • Richard Feldman
  • Robert Bush
  • Royce Bailey
  • Scott Fusare
  • Scott Newman
  • smiffy
  • Stella
  • Steven Busic
  • Steve Conner
  • Steve Jones
  • Steve Ward
  • Sulaiman
  • Thomas Coyle
  • Thomas A. Wallace
  • Thomas W
  • Timo
  • Torch
  • Ulf Jonsson
  • vasil
  • Vaxian
  • vladi mazzilli
  • wastehl
  • Weston
  • William Kim
  • William N.
  • William Stehl
  • Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Forums
4hv.org :: Forums :: Electromagnetic Projectile Accelerators
« Previous topic | Next topic »   

Odd behavior in FEMM simulations

1 2 
Move Thread LAN_403
Yanom
Fri Jan 18 2013, 03:49PM Print
Yanom Registered Member #4659 Joined: Sun Apr 29 2012, 06:14PM
Location:
Posts: 158
So I was trying to simulate coilguns in FEMM, but I noticed some odd behavior. When I analyze a simulation, then go to the answer page, then use integration to determine the force on the projectile, I determined that the force result changes a lot based on the size and shape of the FEMM problem's boundaries.

When I made the FEMM boundaries tight around the coil and projectile (meaning that FEMM was only computing the field in that small area), the force on the projectile was almost twice as much than when I expanded the problem boundaries to encompass a lot of free space beyond the coil and projectile.

This means that the force integration results are based on one of two things -
1) The amount and shape of free space that the problem encloses
2) The density of mesh triangles in the projectile and coil

I'm thinking that #2 is the likely culprit, and furthermore, that I should make the boundaries tight so that the projectile and coil have more mesh triangles (that makes it more accurate, right?).

Has anyone else experienced this before? What's going on here?
Back to top
BigBad
Sat Jan 19 2013, 12:47AM
BigBad Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600
Yes, I find it's best to not use the default mesh size and make it smaller right around the bits you're analysing.

Also, I usually put a couple of circles around the thing I'm modelling, about twice as big as each other with progressively bigger mesh. Then I make a separate circle, completely away from the modelled area (and set the boundary to be linked to the outside circle around my model), and stick air in it (with quite big mesh).

This greatly reduces the distortions due to having a finite area, the flux will leak out of the model and then connect in the extra circle rather than having to set the boundary to zero potential, which will often give quite bad distortion.
Back to top
Yanom
Sat Jan 19 2013, 03:54AM
Yanom Registered Member #4659 Joined: Sun Apr 29 2012, 06:14PM
Location:
Posts: 158
wrote ...

Yes, I find it's best to not use the default mesh size and make it smaller right around the bits you're analysing.

so it is better to have more triangles? This does slow down the simulation, though.

wrote ...

Also, I usually put a couple of circles around the thing I'm modelling, about twice as big as each other with progressively bigger mesh. Then I make a separate circle, completely away from the modelled area (and set the boundary to be linked to the outside circle around my model), and stick air in it (with quite big mesh).

This greatly reduces the distortions due to having a finite area, the flux will leak out of the model and then connect in the extra circle rather than having to set the boundary to zero potential, which will often give quite bad distortion.


that sounds interesting. Can you upload a FEMM file so I can look at it?
Back to top
BigBad
Sun Jan 20 2013, 01:00AM
BigBad Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600
Yes, only have small triangles where something particularly interesting is happening. It's worth putting extra boundaries in just to be able to make the mesh smaller, even though there's air both sides.

The analysis times are not usually bad at all in fact if you're careful, just a few seconds.

It also helps enormously to avoid using non linear things like iron in the analysis, if you're not saturating, replace it with a linear or hard material with otherwise similar properties.
Back to top
BigBad
Sun Jan 20 2013, 01:09AM
BigBad Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600
For the boundary trick, check out diagrams A.8 and A.9 in the appendices of the FEMM manual, under the heading 'Kelvin transformation'. The general problem you're analysing is an 'open boundary problem'.
Back to top
2Spoons
Sun Jan 20 2013, 09:47PM
2Spoons Registered Member #2939 Joined: Fri Jun 25 2010, 04:25AM
Location:
Posts: 615
You can use an iterative process to refine your mesh.
Run a coarse mesh, then look for those areas with big field gradients - shrink the mesh size in those areas. repeat until you are happy with the results.
For boundaries, I usually just make the boundary about five times the size of the area of interest: ie keep the boundary a long way from the problem to minimize its influence.
Back to top
BigBad
Mon Jan 21 2013, 02:11AM
BigBad Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600
2Spoons wrote ...

For boundaries, I usually just make the boundary about five times the size of the area of interest: ie keep the boundary a long way from the problem to minimize its influence.

Yeah, the manual describes that as 'crude'; if you do the trick in the appendix you can make the calculated area a lot smaller, and it's a lot faster to calculate as well, and more accurate.

If you're about to do more analyses, run, do not walk to the appendix of the manual. Do it now! wink
Back to top
Yanom
Mon Jan 21 2013, 02:26AM
Yanom Registered Member #4659 Joined: Sun Apr 29 2012, 06:14PM
Location:
Posts: 158
for simulating coilguns, I did a test setup with a huge far away boundary. Then I manually set the mesh size for the iron. What i found is that the mesh size in the iron has little effect on the results of force calculations - there was less than half a percent of difference between mesh size .01 meters and .0001 meters.
Back to top
BigBad
Mon Jan 21 2013, 04:01PM
BigBad Registered Member #2529 Joined: Thu Dec 10 2009, 02:43AM
Location:
Posts: 600
Yeah, mainly the air you need to mesh carefully, because that's got a higher reluctance; so you get higher gradients in the air.
Back to top
2Spoons
Mon Jan 21 2013, 09:35PM
2Spoons Registered Member #2939 Joined: Fri Jun 25 2010, 04:25AM
Location:
Posts: 615
BigBad wrote ...


Yeah, the manual describes that as 'crude'; if you do the trick in the appendix you can make the calculated area a lot smaller, and it's a lot faster to calculate as well, and more accurate.


Oh, I agree with you. Its just that I'm usually doing quick sims to check an idea rather than going for super accuracy, and a giant boundary is fast to set up.
What I would really like is full 3D fea - though the axisymmetric mode works pretty well for solenoids. I used to have access to Ansys, boy could that program bring a pc to its knees!

On meshing: rather than setting mesh size by area, you can get more efficient meshing by specifying mesh sizes on edges and/or points. That way you can get a fine mesh on a boundary while the interior of a region is fairly coarse.
Back to top
1 2 

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob

Go to:

Powered by e107 Forum System
 
Legal Information
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.