SfePy June 2013

sfepy@python.org

6 participants
11 discussions

Re: Torque
by Robert Cimrman 09 Mar '18

09 Mar '18

In examples/large_deformation/hyperelastic.py a rotation by displacements is applied. By using a similar function the vectors defining the force couples could be defined for dw_surface_ltr (IMHO). Does it make sense? r. ----- Reply message ----- From: "Andre Smit" <freev...(a)gmail.com> To: <sfepy...(a)googlegroups.com> Subject: Torque Date: Sat, Dec 18, 2010 05:10 What is the best way to apply a torque load to a model? -- Andre -- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...(a)googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.

4 7

1D line elements in SfePy
by Nimish 22 Jan '16

22 Jan '16

I am currrently looking for FEM packages to help me solve a system of beams and columns, basically a collection of 1D bernoulli/timoshenko line elements. I started reading SfePy docs and i am getting the idea that doing the above is not really possible here, am i right? Are only 2D area elements permitted in SfePy? Or is there any direct support for solving 1D line elements too.. Cheers Nimish

4 9

Python 3 compatibility
by Robert Cimrman 11 Aug '14

11 Aug '14

FYI: As SciPy 0.12.0 is out and one of the release highlights is "Support for Python 2 and Python 3 from the same code base (no more 2to3)", we can think seriously about updating SfePy in this respect as well, cf. [1]. r. [1] https://github.com/sfepy/sfepy/issues/164

4 5

Evaluate a solution in the arbitrary point in the domain
by Alec Kalinin 03 Apr '14

03 Apr '14

Dear SfePy users, Is it possible to evaluate a solution not only in the FEM mesh node, but in any arbitrary point in the domain with the given (x, y, z) coordinates? For example, consider Dirichlet problem for Poisson equation. We apply essential boundary conditions on the surface nodes and after the problem has been solved we have the solution vector, i.e. vector of values in the FEM mesh nodes. But I want to know the solution in point v(x, y, z) that is not FEM mesh node. What is the best way to obtain solution in this point v? Sincerely, Alec Kalinin

3 25

elliptical hole under isotropic stress
by David N. Mashburn 13 Jan '14

13 Jan '14

Hello sfepy developers and users! I am modelling a simple linear elastic sheet under isotropic stress with an elliptical hole in the center (and I have it working under sfepy, great little platform!). It is obvious the model should initially yield more easily in the direction of the short axis of the ellipse. What is not so obvious to me is what should happen in the limit as stress goes to infinity. Part of me wants to believe that the hole should eventually become a circular, but the results of the simulation show that the ellipse eventually switches its aspect ratio with what was the the short axis becoming the long axis and vice-versa. My question is whether: A: The finite element result is the product of a small-displacement/non-moving mesh artifact (and if so, if there is a way to get the correct behavior using sfepy...) OR B: My intuition about the physical behavior of this ideal system is incorrect and the ellipse really wouldn't round out into a circle under increasingly large stress (aka, the FE model is still physical/correct with large displacements). This might be obvious to people who have done more finite element modeling than I have, but thanks anyway! I'm attaching a picture to make it easier to see at a glance (quarter-ellipse with x and y symmetry boundary conditions and equal tractions applied at the top and right boundaries). Thanks! -David Mashburn

4 12

GSoC Phase 1
by Ankit Mahato 30 Jul '13

30 Jul '13

Hi R, I was very sick for the past few days. Just got up from bed yesterday. Earlier I went through the docs, samples, guide as you had instructed. Also I got the weak form of the equations. Kindly look at the attached PDF and suggest me the path I should take. >From today onwards I will remain online all day and will ping you whenever I get struck. Regards Ankit

2 31

Gravity modeling
by Alexander Mihailov 21 Jun '13

21 Jun '13

Hi all. I have already asked my question at http://math.stackexchange.com/questions/422928/modeling-gravity-field-with-… and http://stackoverflow.com/questions/17160835/modeling-gravity-field-with-fin… but seems there are no people there, who knows sfepy and finite elements, in particular. I want to model the gravity field on 3D rectangular area. It can be described by the equation: div(G) = rho. Here G is vector unknown function, rho is scalar parameter, which is constant at the selected point and fully determined by material. The weak form is: int( div(G) * g ) = int( rho * g ). Here g is vector test function. Using sfepy syntax: {'Gravity' : """dw_div_grad.1.Omega( g, G ) = dw_volume_lvf.1.Omega( m.rho, g )"""} I used gmsh to build .mesh file. My .geo, .mesh and .py files attached to this message. When I try to run sfepy, it says that matrix is singular, so the solving process does not converge. What I have to do to correct the model? Thanks in advance.

3 12

test_cmesh.py runTest error
by Ankit Mahato 17 Jun '13

17 Jun '13

Hi R, I was installing the latest code on my new workstation, when runTests.py exited with error. On running it on debug mode, I got the following output: ankit@ankit-HP-Pavilion-dv4-Notebook-PC:~/sfepy$ ./runTests.py --debug tests/test_cmesh.py <<< directory: tests, test files: 1 <<< tests/test_cmesh.py sfepy: left over: ['data_dir', 'nm', '__builtins__', '_filename', '__file__', '__package__', 'expected', '__doc__', '__name__', 'os', 'TestCommon', 'verbose'] >>> test instance prepared (1 test(s)) ... mesh: 2_3_2.mesh sfepy: reading mesh (/home/ankit/sfepy/meshes/elements/2_3_2.mesh)... sfepy: ...done in 0.00 s sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0xb5ce4cc0, cookie: 0 mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 211: ptr: 0x82bba80, cookie: 1786 mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0xb5ce4cc0, cookie: 0 mem_free_mem(): error exit! mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0x8bf30b0, cookie: 3 mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 211: ptr: 0x817b0e3, cookie: 136600713 mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0x8bf30b0, cookie: 3 mem_free_mem(): error exit! mem_free_mem(): error exit! mem_realloc_mem(): error exit! conn_resize() failed!sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0xb5ce4cc0, cookie: 0 mem_free_mem(): error exit! mem_free_mem(): error exit! sfepy/fem/extmods, sfepy/fem/extmods/mesh.c, conn_free, 210: ptr: 0x8bf30b0, cookie: 3 mem_free_mem(): error exit! mem_free_mem(): error exit! Segmentation fault (core dumped)

2 11

(c)mesh + regions update
by Robert Cimrman 14 Jun '13

14 Jun '13

Hi All, I am updating and cleaning up the code implementing regions, so it's a good time to fix the naming of certain things, especially to be consistent with the new CMesh class (a C implementation of mesh-related data structures, as described in [1]). The CMesh should make the changes proposed below feasible. In a modern FEM, there is a distinction between a node (a topological entity, where degrees of freedom are defined - e.g. points, edges, faces, element/cell interiors) and a vertex (the geometrical points that define the element shape). Our the regions selectors use the term "nodes", due to historical reasons, incorrectly, as what is really meant is "vertices". So I would like to propose a new naming scheme (feedback welcome!), a new "kind" attribute of regions, and a bunch of new operators: 1. nodes -> vertices elements -> cells edges, faces stay facets refer to entities with co-dimension 1 (= dimension 1 less than cells; = edges in 2D, faces in 3D) 2. set-like operators: + (union), - (difference), * (intersection), followed by one of ('v', 'e', 'f', 'c', and 's') for vertices, edges, faces, cells, and facets. So the current '+n' would be '+v', '+e' would be '+c' etc. The actual meaning of those operators would depend of the region kind, see below. 3. region kinds (is there a better word than "kind"?): - cells_only, facet_only, face_only, edge_only, vertex_only - only the specified entities are included, others are empty sets (so that the ops are still defined) - cells, facet, face, edge, vertex - entities of higher dimension are not included - the "cells" kind is the most general, and corresponds to current implementation with the "can_cells" flag set to True. The flags will disappear. - intermediate regions used in expressions would have the "cells" kind for simplicity - this could be improved later - Question: maybe there would be too many kinds? Too few? I can see an application for cells_only, facet_only, face_only, edge_only, but the others were added more or less for the feeling of "completeness". The kinds would allow a clear distinction between regions of different purpose (volume integration domains, surface domains, etc.) and could use less memory. Let me know what you think about the proposed changes (especially Vladimir and other people who work with the internals). Cheers, r. [1] A. Logg: Efficient Representation of Computational Meshes. 2012

2 2

Re: [sfepy-devel] possible GSoC project ideas
by Robert Cimrman 07 Jun '13

07 Jun '13

Ok, thanks! r. ----- Reply message ----- From: "Steve Spicklemire" <st...(a)spvi.com> To: <sfepy...(a)googlegroups.com> Cc: "Steve Spicklemire" <st...(a)spvi.com> Subject: [sfepy-devel] possible GSoC project ideas Date: Fri, Jun 7, 2013 00:32 Unfortunately I have said everything I know about FiPy (what's on the web page). I've never used it. ;-( I'll try to dig more deeply and report back. -steve On Jun 6, 2013, at 11:10 AM, Robert Cimrman <cimr...(a)ntc.zcu.cz> wrote: > On 06/06/2013 05:41 PM, Steve Spicklemire wrote: >> >> On Jun 6, 2013, at 2:38 AM, Robert Cimrman <cimr...(a)ntc.zcu.cz> wrote: >> >>> On 06/06/2013 01:09 AM, steve wrote: >>>> Is anybody pursuing parallelization at this point? Any hints about how >>>> that might be done? I'd be interested in contributing. I've got some >>>> experience with pypar (openmpi python wrapper), but not sure how sfepy >>>> would need to be modified to make that work. >>> >>> We agreed with Ankit (the GSoC student), that both devise and implement >>> the parallelization would be too much in the three or so months GSoC >>> supports, and too risky, so I think nobody is pursuing that right now. >>> >>> I have only some vague ideas, like that it should be done at a high level, >>> so that the FE assembling code does not see it. So any help, mostly >>> theoretical in the current state, would be appreciated! >>> >>> r. >> >> So.. from my brief perusal it seems like the easiest approach might be >> something like that taken in FiPy. It looks like they switch between >> pysparse, scipy and trilinos depending on the situation and whether they >> want to use MPI. I have no idea how hard that would be to actually >> implement. ;-) To what degree does the FE assembling code depend explicitly >> on scipy? > > Well, we can "sort of use" a parallel linear solver right now (see PETScParallelKrylovSolver in [1]), but that cannot be efficient unless the matrix is assembled in parallel (all terms evaluated in their respective parallel subdomains). The "sort of use" means, that the matrix is assembled in a single process, and then a parallel solution is launched. It can get us something like 2.5x speed-up at 4 cores, so it's not that bad, but cannot get us further... > > Does FiPy has "parallel assembling"? I know it's finite volumes, but it's essentially the same as finite elements in this respect - one has a grid/mesh, that needs to be distributed among processors. > > r. > > [1] http://sfepy.org/doc-devel/src/sfepy/solvers/ls.html > >> this is from the FiPy "solvers" page: >> <http://www.ctcms.nist.gov/fipy/documentation/SOLVERS.html> >> >>> FiPy requires either PySparse, SciPy or Trilinos to be installed in order >>> to solve linear systems. From our experiences,FiPy runs most efficiently >>> in serial when PySparse is the linear solver. Trilinos is the most >>> complete of the three solvers due to its numerous preconditioning and >>> solver capabilities and it also allows FiPy to run in parallel. >> >> -steve >> > > -- > You received this message because you are subscribed to the Google Groups "sfepy-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to sfepy-devel...(a)googlegroups.com. > To post to this group, send email to sfepy...(a)googlegroups.com. > Visit this group at http://groups.google.com/group/sfepy-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sfepy-devel...(a)googlegroups.com. To post to this group, send email to sfepy...(a)googlegroups.com. Visit this group at http://groups.google.com/group/sfepy-devel?hl=en.

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

SfePy June 2013