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
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
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
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
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
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.
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
