Mailman 3 June 2010 - SfePy

more refactoring of sfepy.fem
by Robert Cimrman 25 Jun '10

25 Jun '10

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. [1] http://github.com/rc/sfepy

2 3

refactoring of terms
by Robert Cimrman 11 Jun '10

11 Jun '10

Hi all, I have started some refactoring of the terms, aiming at better interactive usability. Things like this already work: t1 = Term.new('dw_lin_elastic_iso(m.lam, m.mu, v, u)', 'auto', omega, m=m, v=v, u=u) print t1 terms = t1 - (3 * t1 - 2 * t1) * 4 + t1 * 2.4j print terms Things like this are going to be possible: eq = Equation(t1 + Term('lin_volume_force', 1, gamma2, f, v)) eqs = Equations([eq], [fix_u]) pb = ProblemDefinition('problem', eqs, nls, ls, ts=None) pb.time_update(ebcs=[fix_u, shift_u]) pb.solve() pb.save_solution('results.vtk') - i.e. it will be possible to build equations from individual terms using arithmetical operators. The "work in progress" implementation can be found at [1], for the brave, see tests/test_high_level.py I try not to break current examples - by some decent hammering all the tests pass except three... Comments welcome! r. [1] http://github.com/rc/sfepy/tree/terms

1 1

Fix for abaqus format
by Andre Smit 11 Jun '10

11 Jun '10

Hi guys Please consider the following small fix for the abaqus mesh format. I've attached the patch and input file I had a problem reading. Thx -- Andre

2 1

talk accepted to euroscipy
by Robert Cimrman 09 Jun '10

09 Jun '10

FYI: The talk [1] has been accepted. Due to the number of high-quality submissions we have got 15 minutes, but it's nice anyway - the acceptance rate was of 58%. r. [1] http://www.euroscipy.org/talk/1714

2 1

MED format mat_ids
by Logan Sorenson 09 Jun '10

09 Jun '10

Hi all, I was playing a bit with the grouping functionality in Salome which allows one to group similar elements and nodes into families. AFAIK, this more or less corresponds to the mat_id associated with the elements in SfePy. However, I couldn't find a way to explicitly specify the numbering, and the implicit numbering by Salome appears to write meshes with negative integers for the mat_id. Are negative mat_ids allowed in SfePy? If not, I'll submit a patch for the MED format read code. Otherwise, we should correct the mat_ids in the comsol format write code, since negative domain numbers do not seem to be allowed there. Thanks! Logan

2 5

removing (most) integrals from problem definition files?
by Robert Cimrman 09 Jun '10

09 Jun '10

Hi all, I'm thinking about replacing the current syntax: dw_laplace.i1.Omega( coef.val, s, t ) where 'i1' is integral_1 = { 'name' : 'i1', 'kind' : 'v', 'quadrature' : 'gauss_o2_d3', } with simply: dw_laplace.2.Omega( coef.val, s, t ) Discussion ---------- The only important information in the 'integral' keyword is the integration order - the space dimension is given by the region dimension. So instead of the integral name, let's use directly the integration order in its place. The order can be either a positive integer, or 'a' as 'automatic' (for future automatic order determination). This will simplify most input files, with the only one exception: custom quadratures will still use the current syntax. What do you think? r.

4 8

all tests pass again
by Robert Cimrman 08 Jun '10

08 Jun '10

Hi all, we have fixed tests/test_input_linear_elastic_mM.py, so now all tests should pass again. Verifications welcome! r.

3 11

Sphinx documentation example link
by Logan Sorenson 03 Jun '10

03 Jun '10

Hi All, FYI, there is a nice example of using Sphinx on PYPI at [1]. Greetings! Logan [1] http://packages.python.org/an_example_pypi_project/sphinx.html

2 1

git clone test failure
by osman 02 Jun '10

02 Jun '10

Hi Robert, I just cloned the latest snapshot. I am getting 2 failures. One is in quadrature test : ./runTests.py tests/test_quadratures.py --filter-less<<< directory: tests, test files: 1 tests/test_quadratures.py test instance prepared (2 test(s)) ... geometry: 1_2 ... order: 1 --- test_quadratures: failed! ... geometry: 1_2 ... order 1: True ... order 3: True ... order 5: True ... order 7: True ... order 9: True ... geometry: 2_3 ... order 1: True ... order 2: True ... order 3: True ... geometry: 2_4 ... order 2: True ... order 3: True ... order 5: True ... geometry: 3_4 ... order 1: True ... order 2: True ... order 3: True ... geometry: 3_8 ... order 2: True ... order 3: True ... order 5: True +++ test_weight_consistency: ok !!! 1 test failed 1 test file(s) executed in 0.22 s, 1 failure(s) of 2 test(s) ./runTests.py tests/test_input_linear_elastic_mM.py --filter-less <<< directory: tests, test files: 1 tests/test_input_linear_elastic_mM.py --- test instance creation failed !!! 1 test failed 1 test file(s) executed in 0.00 s, 1 failure(s) of 1 test(s) Now that one is due to my ubuntu karmic not having a good python tables (no hdf5 support). The first one: ./runTests.py tests/test_quadratures.py --filter-less --debug <<< directory: tests, test files: 1 <<< tests/test_quadratures.py sfepy: left over: ['get_poly', 'nm', '__builtins__', '_filename', '__file__', '__package__', '__doc__', 'sm', '__name__', 'ordered_iteritems', 'TestCommon'] >>> test instance prepared (2 test(s)) ... geometry: 1_2 ... order: 1 >>> <type 'exceptions.AttributeError'> Traceback (most recent call last): File "./runTests.py", line 225, in <module> main() File "./runTests.py", line 216, in main run_tests(stats, dirname, [filename]) File "./runTests.py", line 148, in run_tests n_fail, n_total, test_time = run_test( conf_name, options ) File "./runTests.py", line 111, in run_test ok, n_fail, n_total = test.run( options.debug ) File "/home/osman/src/sfepy/sfepy/base/testing.py", line 38, in run ret = test_method() File "tests/test_quadratures.py", line 96, in test_quadratures is_simplex=is_simplex) File "tests/test_quadratures.py", line 20, in get_poly xs = sm.symarray(dim, 'x') AttributeError: 'module' object has no attribute 'symarray' Anything I can do for this failure? Regards, Osman

2 7

interesting git links
by Robert Cimrman 02 Jun '10

02 Jun '10

FYI: numpy crowd now discusses switching to git + github (finally!), and during the discussion several interesting links appeared, so let me post them here: how to compare versions of code on github (code review) [1] ipython (and nipy) development workflow [2] r. [1] http://github.com/blog/612-introducing-github-compare-view [2] https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html

2 2