On 12/05/11 17:35, Md. Golam Rashed wrote:

http://docs.sfepy.org/doc/primer.html#problem-description

look at the .py files, are those alright? looks like there's something extra on the beginning of each python file on this primer.

you mean r"""? It's ok - r is for raw string, which is needed when the string contains e.g. LaTeX with sequences like \n \r \b, that you want to preserve. Those are normally swallowed/interpreted by python.

r.

On 12/05/11 18:46, Md. Golam Rashed wrote:

For the same primer, what is the dimensions of the second mesh? the "big.mesh" one?

you can see it yourself if you download it - 2885 vertices, 5568 triangles (not really big...)

r.

On 12/06/11 07:39, Md. Golam Rashed wrote:

yes, but i need info like this- "The ITS specimen has a diameter of 150 mm. Using *Gmsh* add three new points (geometry elementary entities) at the following coordinates: (0.0 0.0), (75.0,0.0) and (0.0,75.0)."

• its from its2D.mesh.

is the "big.mesh" has the same overall dimension??

Yes, it represents the same geometry, just with more elements.

BTW. in 2011.4 one could do something like:

def refine(filename, level): if level > 0: mesh = Mesh.from_file(filename) domain = Domain(mesh.name, mesh) for ii in range(level): output('refine %d...' % ii) domain = domain.refine() output('... %d nodes %d elements' % (domain.shape.n_nod, domain.shape.n_el))

     suffix = os.path.splitext(filename)[1]
     filename = domain.name + suffix

     domain.mesh.write(filename, io='auto')

 return filename

filename_mesh = refine('its2D.mesh', 1)

r.

On 12/06/11 09:38, Md. Golam Rashed wrote:

i don't think it represents the same geometry. if it were the same geometry, the analytic solution would not differ for the mesh refinement, would it? i think there is a overall dimension change for the "big.mesh". i don't have any mesh editor and importing to Gmsh fails.

It does represent the same geometry, I checked that.

I am not sure what is the actual definition of the "analytical solution" though. It seems to be computed using nodal forces, which do depend on element size, so it is not truly analytical.

Andre, are you around? :)

################################ for its2D.mesh-

Load to give 1 mm displacement = 1209.789 Newton

Analytical solution

Horizontal tensile stress = 5.135 MPa/mm Vertical compressive stress = 15.404 MPa/mm

FEM solution

Horizontal tensile stress = 4.58 MPa/mm Vertical compressive stress = 15.646 MPa/mm ################################ for big.mesh-

Load to give 1 mm displacement = 740.779 Newton

Analytical solution

Horizontal tensile stress = 3.144 MPa/mm Vertical compressive stress = 9.432 MPa/mm

FEM solution

Horizontal tensile stress = 3.148 MPa/mm Vertical compressive stress = 9.419 MPa/mm

Yes, that's how it should be. The problem is, that in nodal_stress() function the point load P is computed from the _numerical_ rezidual - it is in fact a concentrated nodal load, which reflects contribution of elements containing that point. So it obviously depends on the mesh.

To fix this, there would have to be some way of getting P just from the geometry, material and given loading displacement.

As it is now (IMHO), P is just an approximation of the true point load.

The finer mesh means better approximation of P, and also better agreement between "(not really) analytical" and numerical.

r.

On 12/06/11 09:54, Md. Golam Rashed wrote:

for the same geometry and material property, analytic solution will not differ, even for extensive mesh refinement. it will always be the same. the analytic solution is derived from solid mechanics and there's no function of mesh or element. from http://docs.sfepy.org/doc/primer.html#problem-statement -

The tensile and compressive stresses that develop in the specimen as a result of the point loads P are a function of the diameter (D) and thickness (t) of the cylindrical specimen. At the centre of the specimen, the compressive stress is 3 times the tensile stress and the analytical formulation for these are, respectively:

(1)[image: \sigma_t=\frac{2P}{\pi tD}]

(2)[image: \sigma_c=\frac{6P}{\pi tD}]

On 12/06/11 11:16, Md. Golam Rashed wrote:

Then i think we should not call it analytic solution. Analytic solution would be based on solid mechanics knowledge, getting the vertical and horizontal stress due to application of 1mm displacement at the top.

Agreed. Let's wait some time whether Andre Smit who wrote the primer chimes in with his opinion. You can create a new issue so that it is not forgotten.

Thanks, r.

Then, i think the FEM solution should be updated as calculation of vertical and horizontal stress at the center due to application of point load. and the analytic solution can be used as described in the primer.

The tensile and compressive stresses that develop in the specimen as a result of the point loads P are a function of the diameter (D) and thickness (t) of the cylindrical specimen. At the centre of the specimen, the compressive stress is 3 times the tensile stress and the analytical formulation for these are, respectively:

(1)[image: \sigma_t=\frac{2P}{\pi tD}]

(2)[image: \sigma_c=\frac{6P}{\pi tD}]

Can you update the primer on your spare time?? as i am new to sfepy, am not confident enough.

On 12/07/11 19:19, Robert Cimrman wrote:

On 12/07/11 16:45, Md. Golam Rashed wrote:

...

Can you update the primer on your spare time?? as i am new to sfepy, am not confident enough.

Yes, I can do it, but I cannot tell you when...

The "when" was just a moment ago - check [1].

r. [1] http://docs.sfepy.org/doc-devel/primer.html

On 12/09/11 18:56, Md. Golam Rashed wrote:

Thnx! but error occurs, also rename the .py file of the primer as its2D_1,its2D_2 etc

$ simple.py its2D_1.py Traceback (most recent call last): File "./simple.py", line 125, in<module> main() File "./simple.py", line 113, in main required, other) File "c:\src\sfepy\sfepy\base\conf.py", line 308, in from_file_and_options override=override) File "c:\src\sfepy\sfepy\base\conf.py", line 270, in from_file funmod = import_file( filename ) File "c:\src\sfepy\sfepy\base\base.py", line 120, in import_file mod = __import__(name) File "c:\src\sfepy\its2D_1.py", line 19, in<module> from sfepy.fem.utils import refine_mesh ImportError: cannot import name refine_mesh

You need the latest git version for that to work (which I forgot to push to master, done now).

As for the file names, sphinx sometimes renames files when it thinks they are not the same (e.g. if the path is not exactly the same). It's fixed now.

r.

On Mon, Dec 5, 2011 at 10:44 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:

On 12/05/11 19:20, Ondřej Čertík wrote:

...

On Mon, Dec 5, 2011 at 3:08 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:

...

I am pleased to announce release 2011.4 of SfePy.

Description

SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method. The code is based on NumPy and SciPy packages. It is distributed under the new BSD license.

Home page: http://sfepy.org Mailing lists, issue tracking: http://code.google.com/p/sfepy/ Git (source) repository: http://github.com/sfepy

Documentation: http://docs.sfepy.org/doc

Highlights of this release

• cython used instead of swig to interface C code
• many terms unified thanks to new optional material term argument type
• updated Lagrangian formulation for large deformations
• automatic generation of gallery of examples

Awesome!

I installed dependencies and did:

$ python setup.py build_ext --inplace Traceback (most recent call last): File "setup.py", line 105, in<module> package_check('tables', INFO.PYTABLES_MIN_VERSION) File "/home/ondrej/repos/sfepy/build_helpers.py", line 301, in package_check __import__(pkg_name) File "/home/ondrej/repos/qsnake/local/lib/python2.6/site-packages/tables/__init__.py", line 56, in<module> from tables.utilsExtension import getPyTablesVersion, getHDF5Version File "definitions.pxd", line 138, in tables.utilsExtension ValueError: numpy.dtype does not appear to be the correct type object

I think this comes from incompatible versions of numpy and pytables (and Cython), so I'll try to rebuild all dependencies to fix this.

Thanks! Let me know how it went.

It is some issue with h5py or tables and numpy (I think it's unrelated to sfepy). I've reinstalled everything, but it didn't help. I don't have more time for this today, so I'll try to fix this later.

Ondrej