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

# Re: [femm] Femme-lua (batch processing)

- To: femm@yahoogroups.com
- Subject: Re: [femm] Femme-lua (batch processing)
- From: David Meeker <dmeeker@foster-miller.com>
- Date: Mon, 11 Jun 2001 11:51:40 -0400
- Organization: Foster-Miller, Inc.
- References: <000c01c0f258$af674b40$0200a8c0@.hirstmagnetics>

    Robin Cornelius wrote:

    > Dear group,
    >
    > As promised I have uploaded my modifications to femm to the yahoo group
    > femme page.
    > http://groups.yahoo.com/group/femm/files/
    > [...]

    This is totally, totally cool. The scripting language (vis. your examples)
    seems incredibly intuitive. This approach ought to provide a lot of
    functionality that people have been wanting for a while.

    After experimenting around with it for a bit, there are some things considered
    in the "Known Bugs" section of the documentation that ought to be relatively
    easy to get around. First, there ought to be no problem in getting femme to
    mesh and analyze in a way that is amenable to scripting. Although fkern and
    triangle throw up a dialog so that the user can see what is going on, they are
    really command-line driven applications that ought to work well in the context
    of scripting. The way that the analysis is called now (i.e. pushing the "turn
    the crank" button on the toolbar), the analysis is just spawned and the
    preprocessor contines to run while the analysis is underway. However, it's
    easy to get the preprocessor to wait around until the analysis is done. In
    fact, the program does this when it calls triangle automatically before calling
    fkern--you just have to use the WaitForSingleObject function to get the program
    to hang around until the analysis finishes. (n.b.--no explicit call to the
    mesher is required before an analysis, because calling the start of an analysis
    also calls the mesher automatically to make sure that the mesh is really
    up-to-date.) There's a couple of examples of this technique in the writepoly.cpp
    file, e.g.:

    if (CreateProcess(NULL,CommandLine, NULL, NULL, FALSE,
    0, NULL, NULL, &StartupInfo, &ProcessInfo)){
    // BeginWaitCursor();
    WaitForSingleObject(ProcessInfo.hProcess, INFINITE);
    // EndWaitCursor();
    }
    else
    {
    AfxMessageBox("Couldn't spawn triangle.exe");
    return FALSE;
    }

    We'd probably just want to put in an extra flag so that the program does
    WaitForSingleObject when fkern is used in the context of a lua script and so
    that WaitForSingleObject is not used when the dialog button is pushed.

    Also, here are a couple of extra commands that could be included:

    selectgroup(n) -- This would select the nth group, so that it can be moved,
    rotated, copied, etc. This is good for doing things like turning the rotor on a
    machine without having to select and manipulate each of the component parts
    individually. This is good to have in a scripting implemenation, because I'd
    guess that most of the manipulations from run to run would be this sort of group
    mode operation.

    seteditmode(n) -- This would set the edit mode to points, segements, arc
    segments, or block labels, or groups. This way, the "editaction" parameter in
    the "Editing commands" is just inherited from the preprocessor mode, rather than
    being specified explicitly as a parameter in the lua function call.

    Also, it would be nice to modify particular elements in a property, rather that
    just adding or deleting properties. In fact, it might be nice to be able to add
    a new property by overloading, e.g, add_material with a function that looks
    like:
    add_material("materialname")
    which would just create a material with default attributes. Then, individual
    material properties could be operated on as necessary, perhaps with some command
    like:
    modify_material("materialname",property,value)

    Anyhow, thanks for putting this together Robin, and I hope that you will have a
    continuing interest in developing these lua scripting capabilities for femm.
    Once again, in case I haven't made it clear, this is totally cool.

    Dave.

    begin:vcard
    n:Meeker;David
    tel;fax:781-890-3489
    tel;work:781-684-4070
    x-mozilla-html:TRUE
    url:http://members.aol.com/_ht_a/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] Femme-lua (batch processing)
    - From: "Dragos Popa" <dragospopa@pcnet.ro>

- References:
  - Femme-lua (batch processing)
    - From: "Robin Cornelius" <robin.cornelius@hirst-magnetics.com>

- Prev by Date: solvers and tasks
- Next by Date: Force calculations on magnetostatic problems...
- Previous by thread: Femme-lua (batch processing)
- Next by thread: RE: [femm] Femme-lua (batch processing)
- Index(es):
  - Date
  - Thread