more refactoring of sfepy.fem
by Robert Cimrman
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
8 years, 10 months
refactoring of terms
by Robert Cimrman
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
8 years, 10 months
Fix for abaqus format
by Andre Smit
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
8 years, 10 months
MED format mat_ids
by Logan Sorenson
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
8 years, 10 months
removing (most) integrals from problem definition files?
by Robert Cimrman
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.
8 years, 10 months
all tests pass again
by Robert Cimrman
Hi all,
we have fixed tests/test_input_linear_elastic_mM.py, so now all tests should
pass again. Verifications welcome!
r.
8 years, 10 months
git clone test failure
by osman
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
8 years, 10 months
