[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: Dave Squires <djsquires@plix.com>
- Date: Fri, 04 May 2001 10:08:02 -0700
- References: <EBENLMACNJNEFNGMLGJEMEJHCAAA.adrianw@solid-state-logic.com> <3AF2D5BC.AEC558D5@foster-miller.com>

    David,
    This is all fine and dandy, BUT it seems a small step programming wise
    to put in an increment routing where you select the elements to move.
    Then you can bring up a little window similar to what you have already
    for "moves". In fact it could be the same window with a couple added
    selections for incremental movement either for linear or rotational.
    Once you click incremental then it could ask for how many increments
    over what range. If you select angular you can specify total degrees of
    arc to rotate through and how many steps. The program calculates the
    angle needed and assumes different output file names for results. Just
    tell the user what these were.
    The same goes for linear movement. Select a group of lines and and
    select move and then do the same sort of thing except that the movement
    is over a plus or minus x or y distance with a given number of steps. The
    program
    calculates the stepsize and saves results to different output file names.
    Let the use know what the filenames are and you are done.
    It seems to me that there isn't that much to do and still keep the easy to
    use GUI functions you already have.
    It seems to me that all that is needed an increment loop routine for rotation
    and for linear motion, a run routine to increment and run each run and
    increment
    output filenames. This alone would go a long way to automating the process.
    Other parameters for automated incrementing could be done later...you know
    sort of
    "incrementally". :)

    Dave Squires

    David Meeker wrote:

    > 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.
    >
    >
    >
    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    >
    > ------------------------------------------------------------------------
    > Name: magn4.zip
    > magn4.zip Type: Zip Compressed Data (application/x-zip-compressed)
    > Encoding: base64

- Follow-Ups:
  - Continuing the didcussion on Parametric Analysis / interfacing
    - From: "C.Prem Kumar" <prem@rnd.bhel.co.in>

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

- Prev by Date: Re: [femm] Re: Batch processing / interfacing
- Next by Date: Continuing the didcussion on Parametric Analysis / interfacing
- Previous by thread: Re: [femm] Re: Batch processing / interfacing
- Next by thread: Continuing the didcussion on Parametric Analysis / interfacing
- Index(es):
  - Date
  - Thread