[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Continuing the didcussion on Parametric Analysis / interfacing
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 & hello everyone,
<p> Looks like we are in for a quantum leap ! Hold On
TIGHT !! Fasten the seat belts !!
<br> 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> I would put it a user requirement this way ( for
Say a PLUNGER motion problem):
<ol>
<li>
In the Pre-processor after the the model is ready SELECT
an entity called CONSTRAINT.</li>
<li>
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>
First one would have to select one of the Sub-menu items
say the Point-to-Point distance.</li>
<li>
The Point-to-point distance entity will enable selection
of a ANCHOR point(use Mouse) and a TARGET point.</li>
<li>
Thereafter a menu box suggesting CONSTRAINT name
can appear where one can give a name for the CONSTRAINT and the nominal
distance</li>
<li>
In the Solution phase there should exist a choice -</li>
<ol>
<ol>
<ul>
<li>
Nominal Solution</li>
<li>
Parametric Solution</li>
</ul>
</ol>
</ol>
<li>
The Nominal Solution solves for the nominal distance
specified earlier.</li>
<li>
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.</li>
<li>
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 & Maximum( defining initial &
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>
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 & 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.
<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". 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. If you select angular you can specify total
degrees of</tt>
<br><tt>arc to rotate through and how many steps. The program calculates
the</tt>
<br><tt>angle needed and assumes different output file names for results.
Just</tt>
<br><tt>tell the user what these were.</tt>
<br><tt>The same goes for linear movement. 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. 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. 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. 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. Everything in the stator is in group 0 (where
all entities</tt>
<br><tt>> live by default). I've all entities having to do with the
rotor to be</tt>
<br><tt>> in group 1. 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). Hit "ok".</tt>
<br><tt>></tt>
<br><tt>> That's all there is to it. The rotor should the re-appear,
rotated</tt>
<br><tt>> through the specified angle. 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>> ------------------------------------------------------------------------</tt>
<br><tt>>
Name: magn4.zip</tt>
<br><tt>> magn4.zip Type: Zip Compressed
Data (application/x-zip-compressed)</tt>
<br><tt>>
Encoding: base64</tt>
<br>
<br>
<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@xxxxxxxxxxxxxx>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename=""
--------------AC0CF1B0A573A2CF97FEE689
Content-Type: application/x-unknown-content-type
Content-ID: <part2.3AF38151.10546106@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx
title:Deputy General Manager
x-mozilla-cpt:;8128
fn:C.Prem Kumar
end:vcard