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

# Re: [femm] Batch processing / interfacing

- To: femm@yahoogroups.com
- Subject: Re: [femm] Batch processing / interfacing
- From: David Meeker <dmeeker@foster-miller.com>
- Date: Mon, 30 Apr 2001 13:32:56 -0400
- Organization: Foster-Miller, Inc.
- References: <4.3.2.7.2.20010427081628.00b3e950@staff-mailin.lboro.ac.uk>

Thanks to everyone for all of the comments on batch processing over the last few days. The way that Keith and his students use the program is sort of what I had pictured in my mind's eye when I first started working on femm, so sort of take the view that Keith has suggested that I don't want to make changes to the program which muck up the ease of use. (Besides, it would be too much work to change around the way things work too much).

It would be possible to redo things so that all of the routines that compose femm were in a library that could be used from other programs, as Hang has suggested. However, this would be a lot of work--one would have to either fundamentally redo the way that femm works internally to support a form that would be amenable to compilation as a library. Alternatively, there could be a separate "library" version of femm, but then again, it would be irritating to maintain two different versions simultaneously. In addition, the community is already pretty well served by open source C++ finite element libraries (see http://www.engr.usask.ca/~macphed/finite/fe_resources/node124.html). I'm not so inclined to go this route, but someone else (Hang?) is certainly welcome to take a crack at making a library--I'd probably find it pretty useful.

I though that the approach that Peter Omand Rasmussen tried of sending key commands to femm was pretty interesting--I hadn't thought of trying that before. (I'm not sure that I even know how to do that....). It probably would be possible to put in a command line, but that would be a real change in the way that things are structured. Currently, none of the entities (points, lines, arcs, block labels) have any unique names or numbers, so it would be pretty difficult to implement a lot of the femme functionality from a command line. I think that a lot of the programs that do have command lines sort of "grew" that way out of older dos or unix console applications to which graphics capabilites were added.

Graham has suggested that "I'd rather see a restricted set of batch run options that is too simple, instead of something wildly flexible that is too complex." Probably the sort of thing he has in mind is like the batch run capabilities in IES Amperes, where you sort of guide the program through a set of steps in the pre- and post-processor that define what you'd like to do, which the program then replays over a certain number of steps. Although this seems like it would be an easy thing to implement because it is fairly intuitive use, a lot of the aspects of duplicating something like this functionality are quite subtle and difficult when you really get to the nuts and bolts of it. Again, I don't know if I have the time to do this.

I've been thinking for a while about everyone's messages and what might be a good way to go about adding some sort of batch processing capability. Although Peter had warned against DDE, this is probably the path of least resistance to add in batch capabilities. DDE stands for Dynamic Data Exchange, which is really just a way for two programs that are running concurrently to talk to one another. They do this by communicating through shared memory. Using DDE, commands could be sent to femm "under the radar," in a way that wouldn't affect the present look-and-feel of the user interface. Internal modifications to femm might be fairly minimial to accommodate the DDE functionality. The idea is conceptually similar to the way that Peter was sending characters to femme, except that more elaborate messages could be sent to femm and results received back from femm. Many scripting languages (perl and python) apparently can support DDE interfaces under windows (at least, there are some references to people doing so on the web), and this functionality is supported under Visual-whatever so that femm functionality could be called from within C++ or Basic programs. One could envision making a command line interface like the one that Peter described that communicated with the various femm modules through the use of DDE, or a very structured, simple batch run interface like Graham was talking about. In any case, the low-level details of the DDE could be made transparent to the end user.

Most importantly, these various approaches would not be mutually exclusive, since they'd all just be different incarnations of talking to femm throught the same DDE interface. Different people would be able to work essentially independently on developing different batch/scripting front ends without me being a bottleneck in the development process. With this sort of functionality, a wide range of front ends from very simple to quite complicated could be fashioned. As an example of the more complicated behaviors that would be possible, Matlab has a set of functions that support DDE interactions with other programs. It would then be possible to create a Simulink model in which femm interacts with a rather detailed model of an electromechanical system in a full transient simulation.

The way that I would envision things working is that the geometry could only be remotely manipulated in the "groups" mode. While individual entities do not have unique names or numbers, each group is identified by a unique number. Commands then sent to the femme preprocessor would then be along the lines of Petr Krc's "femm_rot". For example, if you wanted to turn the rotor in a model, you'd put everything associated with the rotor into one group and then send a single command to rotate that group however many degrees you want. All aspects of the "properties" could be modified by text commands, for example if one wants to vary coil currents with rotor position to model a motor under load through an entire revolution). One "master" program could be communicating with femme and femmview simultaneously so that both pre- and post-processing functions could be controlled from within a single front-end. Again, regions for integrals might be specified by the definition of groups in the geometry (e.g. all elements associated with the block labels in a specified group could be the domain for a block integral).

Sound ok so far?

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/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: Batch processing / interfacing
    - From: frank.e.lenning@boeing.com
  - RE: [femm] Batch processing / interfacing
    - From: "Adrian" <adrianw@solid-state-logic.com>
  - Re: [femm] Batch processing / interfacing
    - From: Keith Gregory <k.gregory@lboro.ac.uk>
  - Re: Batch processing / interfacing
    - From: frank.e.lenning@boeing.com

- References:
  - Re: [femm] Batch processing / interfacing
    - From: Keith Gregory <k.gregory@lboro.ac.uk>

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