[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [femm] Re: Batch processing / interfacing



Thanks for the pointer.  I hadn’t realised what Groups were.

 

 

Adrian

 

-----Original Message-----
From: sentto-1333690-371-988994505-adrianwadey=compuserve.com@xxxxxxxxxxxxxxxxxxx [mailto:sentto-1333690-371-988994505-adrianwadey=compuserve.com@xxxxxxxxxxxxxxxxxxx]On Behalf Of David Meeker
Sent: 04 May 2001 17:16
To: femm@xxxxxxxxxxxxxxx
Subject: Re: [femm] Re: Batch processing / interfacing

 



Adrian wrote:

> Dave,
>
> My batch processing needs are for multiple positions of one part
> relative to another. Petr Krc solved the problem for rotating points
> within (or outside) a given circle, but I have been thinking abouta
> more generalised approach.
>
> Manipulation of the points outside of femme can take the approach Petr
> did, but defining the region to move may not be very simple. My idea
> was to split the model into two femm files, process one to create the
> movement, and then merge them back. I downloaded the Femm source code
> to take a look at the file structures, and it looks like 90% of what I
> need is already there.I can see several routes I can take, but am not
> sure of the implications.
>
> 1) I can write everything from scratch.
>
> 2) I can rip the code I need from Femme and create a separate program
> just to merge Fem files.
>
> 3) I can add a File->Merge facility to Femme
>
> 4) You can add a File->Merge facility to Femme
>
> Which are acceptable options?
>
> Adrian.
>

Well, this sort of problem is why I put the "group" mode into femm 3.0.
This way, if you want to move an entire part that's composed of a lot of
points, lines, arcs, and block labels, you just define all of the
elements to be elements of the same group number.  Then, you can select
the entire part with one click and move all of the elements of the group
with one move command.  Unless you have dozens of instances to run, it's
easier to just do it this way, rather than to write a separate code.

If I were going to automate it externally (similar to the way that Petr
did), I'd still use the group designations to denote what should be
moved and what shouldn't--it's a lot easier than trying to do it on the
basis of what physical region things are in.

Just for kicks, I've attached a knock-off of Quickfield's Magn4 PM motor
problem.  Everything in the stator is in group 0 (where all entities
live by default).  I've all entities having to do with the rotor to be
in group 1.  Since this is a motor, the sort of thing that you might be
interested in is to see how the field changes when you turn the rotor.
You can turn the rotor as follows:

1) Go to "groups" mode by clicking the toolbar button that concidentally
looks just like the rotor of this particular machine (fifth one from the
left on the top).
2) Select the rotor by moving the mouse pointer to anywhere within the
rotor and clicking on the right mouse button. The rotor should turn red
to denote that it is selected.
3) Push the "move" toolbar button (third one from the top on the left
toolbar).
4) Hit the "rotation" radio button in the dialog button that pops up,
and specify some rotation (say 10 degrees).  Hit "ok".

That's all there is to it.  The rotor should the re-appear, rotated
through the specified angle.  It is interesting to note that the
magnetization directions of the permanent magnets have also been rotated
along with the rest of the geometry to maintain consistency.

Dave.



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.