[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [femm] 3D Code (was Re: Linux and 3D)
Yes, I think that Gid is a good pre-processor. But it's not free and its file format does not open(like the dxf), one can not extract the geometric data of the model from it. If I knew the file format of Gid, I would write a program to convert it to the .poly file format of Tetgen, and the pre-processor and mesh problem for a 3D code would be largely solved.
Si Hang
----- Original Message -----
From: Mark Smith <mark.smith@xxxxxxxxxx>
To: <femm@xxxxxxxxxxxxxxx>
Sent: Friday, February 01, 2002 6:09 PM
Subject: RE: [femm] 3D Code (was Re: Linux and 3D)
> Hi there,
> Just a thought. I developed an electrostatic BEM solver which I built on the
> back of GID ( http://gid.cimne.upc.es/index.html
> <http://gid.cimne.upc.es/index.html> ) a pre & post processor, I know it's
> not free but it isn't expensive has a passable modeler, good mesher and
> postprocessor with a TCL-TK extension. it allowed me to concentrate on the
> solver code rather than the user interface.
> This is a great user group. Thanks for FEMM.
> Regards
> Mark
>
>
>
> -----Original Message-----
> From: David Meeker [mailto:dcm3c@xxxxxxxxxxxxx]
> Sent: 01 February 2002 05:45
> To: femm@xxxxxxxxxxxxxxx
> Subject: [femm] 3D Code (was Re: Linux and 3D)
>
>
> sihang wrote:
>
> I would like to join the developing work on 3D version. I got some
> experience in 2D finite element calculation, but no experience in 3D. As I
> have encountered several problems that need a 3D solver. Now, I will
> continue to work on the Tetgen program, make it more easy to use and more
> robust.
>
>
> Well, it looks like we could be approaching a critical mass that is big
> enough to kick off a 3D code. Here are some thoughts about making a 3D
> version.
>
> Robin has already noted Si Hang's "Tetgen" program. This would make a good
> backbone for a 3D program. As Robin has also noted, planning is key. The
> internal structure of the current 2D version wasn't incredibly well planned,
> and that has made it hard to make things modular enough to be developed by a
> team. Opportunities for an object-oriented structure weren't really
> exploited very well, and an opportunity to make a code that would easily be
> modified to attack other similar problems (e.g. thermal, elastic,
> electrostatic) was lost. Any 3D effort would need to be structured in such
> a way so that multiple programmers could be working on it without everyone
> having to understand virtually everything about the way that the code works
> to be able to make a valuable contribution.
>
>
> We could use an existing front-end for a 3D solver, but the pre- and
> post-processors are what really make or break the functionality of the
> program. For example, like 4/5 of the source code of femm is devoted to the
> user interface--the technical things that the program does aren't really
> incredibly novel. For a 3D code, it would probably be better in the long
> run to write and maintain a 3D user interface. Probably the preprocessor
> could largely be an analog of the 2D version, which I originally envisioned
> as a graphical way of entering in the information used in a Triangle .poly
> geometry definition file. A lot of the heavy lifting gets sorted out for
> free by the mesh generator. Just tagging regions with block labels makes it
> a lot easier to do the preprocessor, because the preprocessor then doesn't
> really have to be all that smart and keep track of the various regions in
> the problem as the geometry is changed. I'd like to do a similar approach
> for a 3D code, except that one would think of the preprocessor as being a
> graphical tool for building a Tetgen input file.
>
>
> We need to define a core functionality that the program would implement:
> How does user interface "work"?
> What type of problems are to be solved? (suggest nonlinear magnetostatic
> and nonlinear time-harmonic as a start)
> What formulation is to be used? ("dive off the deep end" and suggest
> T-Omega formulation)
> What sort of license will the program be developed under? (Some sort of
> open-source license, but which one?)
>
>
> How would the program be structured? By breaking things into the
> old-fashioned preprocessor-solver-postprocessor divisions, or just having
> one code that envelops all aspects (e.g. like latest Quickfield version)?
>
>
> We also need to define what set of programming tools will be used. The
> current 2D code is all MSVC++, but there are tools out there that allow for
> simultaneous development on both Linux and Windows platforms. Historically,
> cross-platform development has resulted in some of the commercial magnetics
> FEA programs having really lousy user interfaces. However, cross-platform
> development tools are maturing pretty rapidly, and they might now be good
> enough for our purposes. Candidates might be wxWindows or Fox Toolkit
> (among others?) for getting things to compile across platforms. And if
> things could be made to compile on Linux machines concurrently with Windows
> machines, we might have access to a pool of Linux programmers who are used
> to contributing to open-source projects. There could be a learning curve to
> using either wxWindows or Fox, but it might be worth it in the end.
>
>
> We would want to include scripting (i.e. Lua) in an integral way from the
> start, rather than as a "retrofit".
>
>
> Lastly, we need to create a skeleton of the where multiple programmers can
> be working at the same time. Some of the logistics could be accomplished
> via standard CVS tools at BerliOS (or SourceForge). A project has already
> been created for femm at BerliOS (see
> http://developer.berlios.de/projects/femm/
> <http://developer.berlios.de/projects/femm/> ). Perhaps it would be better
> to move discussions about a 3D version over to the "Developers" discussion
> forum on Berlios and focus the Yahoo list more on the 2D version. (N.B.: You
> have to sign up with Berlios and become a developer for the project to get
> access to the "Developers" forum. There are no restrictions as far as who
> can become a developer, and it doesn't cost anything to sign up.)
>
>
> Dave.
> --
> David Meeker
> http://femm.berlios.de/dmeeker <http://femm.berlios.de/dmeeker>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .
>
>
>
>
> --------------------------------------------------------------------------
> This e-mail may contain privileged/confidential information and may be
> read, copied and used only by the intended recipient. If you have received
> it in error, please contact the sender by return e-mail or by
> telephoning +44 (0)1480 302100.
> Please then delete the e-mail and do not disclose its contents to any
> person.
>
> Any information in this message that does not relate to the official
> business of Linx shall be understood as neither given nor endorsed by Linx.
> We reserve the right to monitor all e-mail communications through our
> internal and external networks.
> --------------------------------------------------------------------------
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Get your FREE credit report with a FREE CreditCheck
> Monitoring Service trial
> http://us.click.yahoo.com/ACHqaB/bQ8CAA/ySSFAA/PMYolB/TM
> ---------------------------------------------------------------------~->
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>