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

# Re: [femm] Re: Batch processing / interfacing

- To: femm@yahoogroups.com
- Subject: Re: [femm] Re: Batch processing / interfacing
- From: David Meeker <dmeeker@foster-miller.com>
- Date: Fri, 04 May 2001 12:15:56 -0400
- Organization: Foster-Miller, Inc.
- References: <EBENLMACNJNEFNGMLGJEMEJHCAAA.adrianw@solid-state-logic.com>

    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 about a
    > 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.

Attachment: `zip00009.zip`
Description: Zip compressed data

    begin:vcard
    n:Meeker;David
    tel;fax:781-890-3489
    tel;work:781-684-4070
    x-mozilla-html:TRUE
    url:http://members.aol.com/dcm3c
    org:Foster-Miller, Inc.;Electrical and Electronic Systems Group
    version:2.1
    email;internet:dmeeker@foster-miller.com
    title:Senior Engineer
    adr;quoted-printable:;;350 Second Avenue=0D=0A;Waltham;MA;02451-1196;USA
    fn:David Meeker, Ph.D.
    end:vcard

- Follow-Ups:
  - Re: [femm] Re: Batch processing / interfacing
    - From: Dave Squires <djsquires@plix.com>
  - RE: [femm] Re: Batch processing / interfacing
    - From: "Adrian" <adrianw@solid-state-logic.com>

- References:
  - RE: [femm] Re: Batch processing / interfacing
    - From: "Adrian" <adrianw@solid-state-logic.com>

- Prev by Date: RE: [femm] Re: Batch processing / interfacing
- Next by Date: Re: [femm] Re: Batch processing / interfacing
- Previous by thread: RE: [femm] Re: Batch processing / interfacing
- Next by thread: Re: [femm] Re: Batch processing / interfacing
- Index(es):
  - Date
  - Thread