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

# Continuing the didcussion on Parametric Analysis / interfacing

- To: femm@yahoogroups.com
- Subject: Continuing the didcussion on Parametric Analysis / interfacing
- From: "C.Prem Kumar" <prem@rnd.bhel.co.in>
- Date: Sat, 05 May 2001 09:58:12 +0530
- References: <EBENLMACNJNEFNGMLGJEMEJHCAAA.adrianw@solid-state-logic.com> <3AF2D5BC.AEC558D5@foster-miller.com> <3AF2E1F2.F7E89FEB@plix.com>

    Hello David Meeker & hello everyone,

    Looks like we are in for a quantum leap ! Hold On TIGHT !! Fasten
    the seat belts !!
    I have been closely following the communications on "Batch
    Processing" and very much appreciate the active participation of femm
    members. I apologise for my laziness. I had, for a long time wanted to
    add to the discussions on the approach. Now, in a way, close to that
    Dave Squires has said it.

    I would put it a user requirement this way ( for Say a PLUNGER
    motion problem):

    1. In the Pre-processor after the the model is ready SELECT an
    entity called CONSTRAINT.
    2. Sub-menu under CONSTRAINT could be -
    + Point-to-point-distance
    + Angular rotation
    + etc
    3. First one would have to select one of the Sub-menu items say
    the Point-to-Point distance.
    4. The Point-to-point distance entity will enable selection of a
    ANCHOR point(use Mouse) and a TARGET point.
    5. Thereafter a menu box suggesting CONSTRAINT name can appear
    where one can give a name for the CONSTRAINT and the nominal
    distance
    6. In the Solution phase there should exist a choice -
    + Nominal Solution
    + Parametric Solution
    7. The Nominal Solution solves for the nominal distance specified
    earlier.
    8. One could access the Nominal Solution in the POST-PROCESSOR and
    define Macro's for computation of (a)Inductance (b)Integral B
    (along some line not disturbed by the Parametric sweep) etc .
    Several Macro's defining user requirements can be put down.
    9. Next invoke Variables Table (feature) -
    + Include all Variables defined ( could be excitations
    also coming from excn)
    + Have a feature to define Minimum & Maximum( defining
    initial & final valuesgap distances).
    + Have a PARAMETRIC SWEEP - defined in terms of number
    of steps
    + Have a feature for animation to see if
    implementation is correct(Boolean)
    + Include Macro's defined in Nominal Solution
    10. Click on Parametric Solution.

    On Clicking "Parametric Solution" the Solver looks at the "Parametric
    Sweep table" and they will be executed in a loop. Incidentally, all the
    steps detailed above are done in the Pre-processor resulting in Batch
    Files called by the solver in a sequence.

    Before I forget to mention, we could have -

    o in the variables table a feature to
    delete/or retain solution files after the
    macro's are done with.
    o the variables table can include other
    issues coming from excitations, B'ndry
    Condn's, Matl. Props(linear) etc.

    Probably as we grow we can add to the features. But it certainly is a
    nice idea to pool resources and put up something efficient & accurate. I
    also shun the idea of COMMERCIAL thoughts. Thats when one sees only
    MONEY and not the worth & effort. Sorry for the rather long message.
    Its weekend for us now in India. Have a nice time. Bye

    Prem Kumar, Chittajallu

    Dave Squires wrote:

    > 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
    >
    >
    >
    > Yahoo! Groups Sponsor
    [www.debticated.com]

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

    --------------2DB46D485C28B1972F35B22B
    Content-Type: multipart/related;
    boundary="------------AC0CF1B0A573A2CF97FEE689"

    --------------AC0CF1B0A573A2CF97FEE689
    Content-Type: text/html; charset=us-ascii
    Content-Transfer-Encoding: 7bit

    <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
    <html>
    Hello David Meeker &amp; hello everyone,
    <p>&nbsp;&nbsp;&nbsp; Looks like we are in for a quantum leap ! Hold On
    TIGHT !! Fasten the seat belts !!
    <br>&nbsp;&nbsp;&nbsp; I have been closely following the communications
    on "Batch Processing" and very much appreciate the active participation
    of femm members. I apologise for my laziness. I had, for a long time wanted
    to add to the discussions on the approach. Now, in a way, close to that
    Dave Squires has said it.
    <p>&nbsp;&nbsp;&nbsp; I would put it a user requirement this way ( for
    Say a PLUNGER motion problem):
    <ol>
    <li>
    &nbsp;&nbsp;&nbsp; In the Pre-processor after the the model is ready SELECT
    an entity called CONSTRAINT.</li>

    <li>
    &nbsp;&nbsp;&nbsp; Sub-menu under CONSTRAINT could be -</li>

    <ol>
    <ol>
    <ul>
    <li>
    Point-to-point-distance</li>

    <li>
    Angular rotation</li>

    <li>
    etc</li>
    </ul>
    </ol>
    </ol>

    <li>
    &nbsp;&nbsp;&nbsp; First one would have to select one of the Sub-menu items
    say the Point-to-Point distance.</li>

    <li>
    &nbsp;&nbsp;&nbsp; The Point-to-point distance entity will enable selection
    of a ANCHOR point(use Mouse) and a TARGET point.</li>

    <li>
    &nbsp;&nbsp;&nbsp; Thereafter a menu box suggesting&nbsp; CONSTRAINT name
    can appear where one can give a name for the CONSTRAINT and the nominal
    distance</li>

    <li>
    &nbsp;&nbsp;&nbsp; In the Solution phase there should exist a choice -</li>

    <ol>
    <ol>
    <ul>
    <li>
    &nbsp;&nbsp; Nominal Solution</li>

    <li>
    &nbsp;&nbsp; Parametric Solution</li>
    </ul>
    </ol>
    </ol>

    <li>
    &nbsp;&nbsp;&nbsp; The Nominal Solution solves for the nominal distance
    specified earlier.</li>

    <li>
    &nbsp;&nbsp;&nbsp; One could access the Nominal Solution in the POST-PROCESSOR
    and define Macro's for computation of&nbsp; (a)Inductance (b)Integral B
    (along some line not disturbed by the Parametric&nbsp; sweep) etc . Several
    Macro's defining user requirements can be put down.</li>

    <li>
    &nbsp;&nbsp;&nbsp; Next invoke Variables Table (feature) -</li>

    <ol>
    <ol>
    <ul>
    <li>
    Include all Variables defined ( could be excitations also coming from excn)</li>

    <li>
    Have a feature to define Minimum &amp; Maximum( defining initial &amp;
    final values<strike>gap distances</strike>).</li>

    <li>
    Have a PARAMETRIC SWEEP - defined in terms of number of steps</li>

    <li>
    Have a feature for animation to see if implementation is correct(Boolean)</li>

    <li>
    Include Macro's defined in Nominal Solution</li>
    </ul>
    </ol>
    </ol>

    <li>
    &nbsp;&nbsp;&nbsp; Click on Parametric Solution.</li>
    </ol>
    On Clicking "Parametric Solution" the Solver looks at the "Parametric Sweep
    table" and they will be executed in a loop. Incidentally, all the steps
    detailed above are done in the Pre-processor resulting in Batch Files called
    by the solver in a sequence.
    <p>Before I forget to mention, we could have -
    <ul>
    <blockquote>
    <blockquote>
    <ul>
    <li>
    in the variables table a feature to delete/or retain solution files after
    the macro's are done with.</li>

    <li>
    the variables table can include other issues coming from excitations, B'ndry
    Condn's, Matl. Props(linear) etc.</li>
    </ul>
    </blockquote>
    </blockquote>
    </ul>
    Probably as we grow we can add to the features. But it certainly is a nice
    idea to pool resources and put up something efficient &amp; accurate. I
    also shun the idea of COMMERCIAL thoughts. Thats when one sees only MONEY
    and not the worth &amp; effort. Sorry for the rather long message.
    <br>Its weekend for us now in India. Have a nice time. Bye
    <p>Prem Kumar, Chittajallu
    <p>Dave Squires wrote:
    <blockquote TYPE=CITE><tt>David,</tt>
    <br><tt>This is all fine and dandy, BUT it seems a small step programming
    wise</tt>
    <br><tt>to put in an increment routing where you select the elements to
    move.</tt>
    <br><tt>Then you can bring up a little window similar to what you have
    already</tt>
    <br><tt>for "moves".&nbsp; In fact it could be the same window with a couple
    added</tt>
    <br><tt>selections for incremental movement either for linear or rotational.</tt>
    <br><tt>Once you click incremental then it could ask for how many increments</tt>
    <br><tt>over what range.&nbsp; If you select angular you can specify total
    degrees of</tt>
    <br><tt>arc to rotate through and how many steps.&nbsp; The program calculates
    the</tt>
    <br><tt>angle needed and assumes different output file names for results.&nbsp;
    Just</tt>
    <br><tt>tell the user what these were.</tt>
    <br><tt>The same goes for linear movement.&nbsp; Select a group of lines
    and and</tt>
    <br><tt>select move and then do the same sort of thing except that the
    movement</tt>
    <br><tt>is over a plus or minus x or y distance with a given number of
    steps. The</tt>
    <br><tt>program</tt>
    <br><tt>calculates the stepsize and saves results to different output file
    names.</tt>
    <br><tt>Let the use know what the filenames are and you are done.</tt>
    <br><tt>It seems to me that there isn't that much to do and still keep
    the easy to</tt>
    <br><tt>use GUI functions you already have.</tt>
    <br><tt>It seems to me that all that is needed an increment loop routine
    for rotation</tt>
    <br><tt>and for linear motion, a run routine to increment and run each
    run and</tt>
    <br><tt>increment</tt>
    <br><tt>output filenames.&nbsp; This alone would go a long way to automating
    the process.</tt>
    <br><tt>Other parameters for automated incrementing could be done later...you
    know</tt>
    <br><tt>sort of</tt>
    <br><tt>"incrementally". :)</tt>
    <p><tt>Dave Squires</tt>
    <p><tt>David Meeker wrote:</tt>
    <p><tt>> Adrian wrote:</tt>
    <br><tt>></tt>
    <br><tt>> > Dave,</tt>
    <br><tt>> ></tt>
    <br><tt>> > My batch processing needs are for multiple positions of one
    part</tt>
    <br><tt>> > relative to another. Petr Krc solved the problem for rotating
    points</tt>
    <br><tt>> > within (or outside) a given circle, but I have been thinking
    about a</tt>
    <br><tt>> > more generalised approach.</tt>
    <br><tt>> ></tt>
    <br><tt>> > Manipulation of the points outside of femme can take the approach
    Petr</tt>
    <br><tt>> > did, but defining the region to move may not be very simple.
    My idea</tt>
    <br><tt>> > was to split the model into two femm files, process one to
    create the</tt>
    <br><tt>> > movement, and then merge them back. I downloaded the Femm source
    code</tt>
    <br><tt>> > to take a look at the file structures, and it looks like 90%
    of what I</tt>
    <br><tt>> > need is already there.I can see several routes I can take,
    but am not</tt>
    <br><tt>> > sure of the implications.</tt>
    <br><tt>> ></tt>
    <br><tt>> > 1) I can write everything from scratch.</tt>
    <br><tt>> ></tt>
    <br><tt>> > 2) I can rip the code I need from Femme and create a separate
    program</tt>
    <br><tt>> > just to merge Fem files.</tt>
    <br><tt>> ></tt>
    <br><tt>> > 3) I can add a File->Merge facility to Femme</tt>
    <br><tt>> ></tt>
    <br><tt>> > 4) You can add a File->Merge facility to Femme</tt>
    <br><tt>> ></tt>
    <br><tt>> > Which are acceptable options?</tt>
    <br><tt>> ></tt>
    <br><tt>> > Adrian.</tt>
    <br><tt>> ></tt>
    <br><tt>></tt>
    <br><tt>> Well, this sort of problem is why I put the "group" mode into
    femm 3.0.</tt>
    <br><tt>> This way, if you want to move an entire part that's composed
    of a lot of</tt>
    <br><tt>> points, lines, arcs, and block labels, you just define all of
    the</tt>
    <br><tt>> elements to be elements of the same group number.&nbsp; Then,
    you can select</tt>
    <br><tt>> the entire part with one click and move all of the elements of
    the group</tt>
    <br><tt>> with one move command.&nbsp; Unless you have dozens of instances
    to run, it's</tt>
    <br><tt>> easier to just do it this way, rather than to write a separate
    code.</tt>
    <br><tt>></tt>
    <br><tt>> If I were going to automate it externally (similar to the way
    that Petr</tt>
    <br><tt>> did), I'd still use the group designations to denote what should
    be</tt>
    <br><tt>> moved and what shouldn't--it's a lot easier than trying to do
    it on the</tt>
    <br><tt>> basis of what physical region things are in.</tt>
    <br><tt>></tt>
    <br><tt>> Just for kicks, I've attached a knock-off of Quickfield's Magn4
    PM motor</tt>
    <br><tt>> problem.&nbsp; Everything in the stator is in group 0 (where
    all entities</tt>
    <br><tt>> live by default).&nbsp; I've all entities having to do with the
    rotor to be</tt>
    <br><tt>> in group 1.&nbsp; Since this is a motor, the sort of thing that
    you might be</tt>
    <br><tt>> interested in is to see how the field changes when you turn the
    rotor.</tt>
    <br><tt>> You can turn the rotor as follows:</tt>
    <br><tt>></tt>
    <br><tt>> 1) Go to "groups" mode by clicking the toolbar button that concidentally</tt>
    <br><tt>> looks just like the rotor of this particular machine (fifth one
    from the</tt>
    <br><tt>> left on the top).</tt>
    <br><tt>> 2) Select the rotor by moving the mouse pointer to anywhere within
    the</tt>
    <br><tt>> rotor and clicking on the right mouse button. The rotor should
    turn red</tt>
    <br><tt>> to denote that it is selected.</tt>
    <br><tt>> 3) Push the "move" toolbar button (third one from the top on
    the left</tt>
    <br><tt>> toolbar).</tt>
    <br><tt>> 4) Hit the "rotation" radio button in the dialog button that
    pops up,</tt>
    <br><tt>> and specify some rotation (say 10 degrees).&nbsp; Hit "ok".</tt>
    <br><tt>></tt>
    <br><tt>> That's all there is to it.&nbsp; The rotor should the re-appear,
    rotated</tt>
    <br><tt>> through the specified angle.&nbsp; It is interesting to note
    that the</tt>
    <br><tt>> magnetization directions of the permanent magnets have also been
    rotated</tt>
    <br><tt>> along with the rest of the geometry to maintain consistency.</tt>
    <br><tt>></tt>
    <br><tt>> Dave.</tt>
    <br><tt>></tt>
    <br><tt>></tt>
    <br><tt>></tt>
    <br><tt>> Your use of Yahoo! Groups is subject to <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a></tt>
    <br><tt>></tt>
    <br><tt>>&nbsp;&nbsp; ------------------------------------------------------------------------</tt>
    <br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Name: magn4.zip</tt>
    <br><tt>>&nbsp;&nbsp;&nbsp; magn4.zip&nbsp;&nbsp;&nbsp; Type: Zip Compressed
    Data (application/x-zip-compressed)</tt>
    <br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Encoding: base64</tt>
    <br>&nbsp;
    <br>&nbsp;
    <p>
    <br><tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/";>Yahoo!
    Terms of Service</a>.</tt></blockquote>
    </html>

    --------------AC0CF1B0A573A2CF97FEE689
    Content-Type: image/gif
    Content-ID: <part1.3AF38151.10546106@rnd.bhel.co.in>
    Content-Transfer-Encoding: base64
    Content-Disposition: inline; filename=""

    --------------AC0CF1B0A573A2CF97FEE689
    Content-Type: application/x-unknown-content-type
    Content-ID: <part2.3AF38151.10546106@rnd.bhel.co.in>
    Content-Transfer-Encoding: base64
    Content-Disposition: inline; filename=""

    --------------AC0CF1B0A573A2CF97FEE689--

    --------------2DB46D485C28B1972F35B22B--

    begin:vcard
    n:Kumar;C.Prem Kumar
    tel;fax:+91 40 3073820
    tel;home:+91 40 7751195
    tel;work:+91 40 388 2347
    x-mozilla-html:FALSE
    org:Electromagnetics Group;BHEL Corp.R&D Division
    adr:;;;Vikasnagar P.O, ;Hyderabad;500 093;India
    version:2.1
    email;internet:prem@rnd.bhel.co.in
    title:Deputy General Manager
    x-mozilla-cpt:;8128
    fn:C.Prem Kumar
    end:vcard

- 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>
  - Re: [femm] Re: Batch processing / interfacing
    - From: Dave Squires <djsquires@plix.com>

- Prev by Date: Re: [femm] Re: Batch processing / interfacing
- Next by Date: Re: [femm] Solenoid Design Handbook - A Moron's Guide, Please Help
- Previous by thread: Re: [femm] Re: Batch processing / interfacing
- Next by thread: RE: [femm] Re: Batch processing / interfacing
- Index(es):
  - Date
  - Thread