Re: [femm] Batch processing / interfacing

[Keith Gregory <k.gregory@xxxxxxxxxxx>]

David,

It sounds good to me. I have never used DDE myself but I'm a quick
learner! I believe that even the cut down Visual Basics used as macro
languages in things like Excel can handle DDE to a certain extent so it
may open up all sorts of possibilities. Personally, being an old FORTRAN
programmer (yes I know but it's still the best for many applications) I
find Visual Basic much easier to deal with than C++ and would welcome
anything that would make a straightforward link between Basic and FEMM
possible.

Keith.

   At 13:32 30/04/01 -0400, you wrote:
> 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. 
>   
> Yahoo! Groups
> Sponsor
>
> Your use of Yahoo! Groups is subject to the
> Yahoo! Terms of
> Service.