Hi Robert,
On Thu, Jun 24, 2010 at 4:26 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
On 06/23/10 19:40, Logan Sorenson wrote:
Hi Robert,
This is very cool stuff! I like the idea of being able to interactively construct the problem description in python. I suppose it would eventually be possible to write the finalized version of the problem to a file (autogeneration of a problem description file). One could then implement a GUI on top of that (with a basic set of functions), which would allow new users the ability to interactively and easily learn how to use SfePy and its functionality.
Hey, it's a cool idea to "save session" to a problem description file! It will be actually pretty easy...
Cool, I need to find time to dig into the latest changes. Is something like ProblemConf.to_file already implemented (reverse of ProblemConf.from_file)? Or would implementing this function allow the needed functionality?
A GUI, on the other hand, is not easy, even if using the cool traits+traitsgui+mayavi. It is an area, where people not experienced with FEM or the code internals might help, though. Any volunteer? :-) The current implementation of sfepy_gui.py is not very elegant, as I am still not quite familiar with using the traitsgui properly - there are lots of things to improve...
A gui would be definitely be more of a long term target. But on the other hand, even a simple window showing the mesh and a embedded python console to allow interactive development of the problem description would be cool. Maybe eventually we could implement visual region selection tools (such as grabbing domains, boundaries, edges, and vertices).
Could you create a new issue for the first (IMHO easy) task?
Issue #142
Greetings, Logan
Cheers, r.
On Wed, Jun 23, 2010 at 2:56 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
Hi all,
the code has underwent another major update of the core functionality, so this e-mail should both warn you and raise your interest [1] :).
Short summary
The fundamental "change of philosophy" is, that term arguments (basically materials and variables) are now assigned explicitely at the term construction time. Their "values" can be changed later at will, and the term can be re-evaluated. Before the change, the terms were constructed only with names of the real arguments - those had to be assigned later, e.g. in the assembling loop. This lead sometimes to problems like what more needs to be assigned in order to be able to evaluate a term. The current design is IMHO clearer, and better suited for interactive work e.g. in ipython (isfepy).
Details
See also previous thread "refactoring of terms".
Besides lots of smaller tweaks, there are two major changes, that change the high-level API significantly. Here by high-level I mean the level of tests/test_high_level.py - the example input files were mostly unaffected, apart those doing some advanced post-processing.
The major changes are: (a) variables are now an attribute of Equations, instead of ProblemDefinition (b) DOF connectivity setup moved from variables to fields.
Both changes simplified significantly the assembling loop, and improved term evaluation - this is where the most visible changes are, see the updated tests and examples (commit e6ab7410ce9cf594057cf7114d697f35f3f510e0).
The next aim is to finish the API prototyped in tests/test_high_level.py.
Also, I have to fix the sfepy.homogenization module, as it was not updated yet to reflect the changes (-> hence the one failing test).
Best regards, r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.