Re: Torque
by Robert Cimrman
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.
1 year, 1 month
Re: easier_terms branch merged
by Robert Cimrman
It should be in any repo quite some time - is it missing somewhere? Bunch of .rst files in doc/...
r.
----- Reply message -----
From: "Andre Smit" <freev...(a)gmail.com>
To: <sfepy...(a)googlegroups.com>
Subject: easier_terms branch merged
Date: Thu, Jul 28, 2011 05:23
Which repo - development?
On Wed, Jul 27, 2011 at 3:48 PM, Robert Cimrman <cimr...(a)ntc.zcu.cz> wrote:
Ok, I will think where to put it. The current sphinx docs can be accessed from sfepy.org, the sources are in doc subdir of the git checkout.
Cheers,
r.
----- Reply message -----
From: "Andre Smit" <freev...(a)gmail.com>
To: <sfepy...(a)googlegroups.com>
Subject: easier_terms branch merged
Date: Wed, Jul 27, 2011 16:58
Anytime past Aug 1 is good - swamped until then:) It would help if you could create the initial Sphinx docs as a start. I'll then transfer the Github primer which should be in a similar format and patch these to revise.
a.
On Wed, Jul 27, 2011 at 9:48 AM, Robert Cimrman <cimr...(a)ntc.zcu.cz> wrote:
On 07/27/11 16:38, Andre Smit wrote:
Yes - let's do it. I suggest rewriting certain sections though to make it
more formal and clearer - and revisiting some of the figures. I'd also like
to include sections on modeling using abaqus and another on paraview
post-processing.
Those section would be pretty useful! I have to update also the developer guide to reflect the current state. (And fix finally term docstrings...)
I would like to make 2011.3 some time in the first half of August (before euroscipy), so it would be nice to have something by then. (Just a note, I am not trying to rush you ;))
Unfortunately my gmsh is down at the moment - it's a bugger to recompile :)
Fingers crossed :)
r.
a.
On Wed, Jul 27, 2011 at 9:21 AM, Robert Cimrman<cimr...(a)ntc.zcu.cz> wrote:
Great! Do you think we should include somehow the primer into the sphinx
docs? It's really a very nice document showing lots of features.
r.
On 07/27/11 15:37, Andre Smit wrote:
Sounds good - I'll update the Primer accordingly.
a
On Wed, Jul 27, 2011 at 4:46 AM, Robert Cimrman<cimr...(a)ntc.zcu.cz>
wrote:
Yes, it is.
Now you need to explicitly write the term evaluation mode other than
'eval'
which is the default. So the fix is:
strain = ev('de_cauchy_strain.2.Omega(****u)', mode='el_avg')
stress = ev('de_cauchy_stress.2.Omega(****Asphalt.D, u)',
mode='el_avg')
You can also add verbose=False to suppress output, if you wish.
The term evaluation modes are:
'eval' : evaluate the integral over a region, result has dimension like
the
quantity integrated
'el_avg' : element average - result is array of the quantity is averaged
in
each element of a region - this is the mode for postprocessing
'qp' : quantity interpolated into quadrature points of each element in a
region
'weak' : assemble either the vector or matrix according to dw_mode
argument.
Look at ProblemDefinition.evaluate() doc to see description of all the
arguments.
Currently, not all terms support all the modes, one needs to look at the
sources =:) But all dw_* terms support 'weak' mode, all 'dq_*' term
support
'eval' mode, 'de_*' term support 'el_avg' mode etc. Actually most 'dq_*',
'de_*', 'di_*', 'd_' terms support 'eval', 'el_avg' and 'qp' modes.
The prefixes are due to history when the mode argument was not available,
so now they are mostly redundant, but at least one as a notion what is
the
evaluation purpose of each term. They may disappear after some more term
unification. easier_terms branch already resulted in a number of terms
disappearing.
So, that's how things are now :)
r.
--
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.
--
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.
--
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.
--
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.
7 years, 8 months
Re: easier_terms branch merged
by Robert Cimrman
Ok, I will think where to put it. The current sphinx docs can be accessed from sfepy.org, the sources are in doc subdir of the git checkout.
Cheers,
r.
----- Reply message -----
From: "Andre Smit" <freev...(a)gmail.com>
To: <sfepy...(a)googlegroups.com>
Subject: easier_terms branch merged
Date: Wed, Jul 27, 2011 16:58
Anytime past Aug 1 is good - swamped until then:) It would help if you could create the initial Sphinx docs as a start. I'll then transfer the Github primer which should be in a similar format and patch these to revise.
a.
On Wed, Jul 27, 2011 at 9:48 AM, Robert Cimrman <cimr...(a)ntc.zcu.cz> wrote:
On 07/27/11 16:38, Andre Smit wrote:
Yes - let's do it. I suggest rewriting certain sections though to make it
more formal and clearer - and revisiting some of the figures. I'd also like
to include sections on modeling using abaqus and another on paraview
post-processing.
Those section would be pretty useful! I have to update also the developer guide to reflect the current state. (And fix finally term docstrings...)
I would like to make 2011.3 some time in the first half of August (before euroscipy), so it would be nice to have something by then. (Just a note, I am not trying to rush you ;))
Unfortunately my gmsh is down at the moment - it's a bugger to recompile :)
Fingers crossed :)
r.
a.
On Wed, Jul 27, 2011 at 9:21 AM, Robert Cimrman<cimr...(a)ntc.zcu.cz> wrote:
Great! Do you think we should include somehow the primer into the sphinx
docs? It's really a very nice document showing lots of features.
r.
On 07/27/11 15:37, Andre Smit wrote:
Sounds good - I'll update the Primer accordingly.
a
On Wed, Jul 27, 2011 at 4:46 AM, Robert Cimrman<cimr...(a)ntc.zcu.cz>
wrote:
Yes, it is.
Now you need to explicitly write the term evaluation mode other than
'eval'
which is the default. So the fix is:
strain = ev('de_cauchy_strain.2.Omega(****u)', mode='el_avg')
stress = ev('de_cauchy_stress.2.Omega(****Asphalt.D, u)',
mode='el_avg')
You can also add verbose=False to suppress output, if you wish.
The term evaluation modes are:
'eval' : evaluate the integral over a region, result has dimension like
the
quantity integrated
'el_avg' : element average - result is array of the quantity is averaged
in
each element of a region - this is the mode for postprocessing
'qp' : quantity interpolated into quadrature points of each element in a
region
'weak' : assemble either the vector or matrix according to dw_mode
argument.
Look at ProblemDefinition.evaluate() doc to see description of all the
arguments.
Currently, not all terms support all the modes, one needs to look at the
sources =:) But all dw_* terms support 'weak' mode, all 'dq_*' term
support
'eval' mode, 'de_*' term support 'el_avg' mode etc. Actually most 'dq_*',
'de_*', 'di_*', 'd_' terms support 'eval', 'el_avg' and 'qp' modes.
The prefixes are due to history when the mode argument was not available,
so now they are mostly redundant, but at least one as a notion what is
the
evaluation purpose of each term. They may disappear after some more term
unification. easier_terms branch already resulted in a number of terms
disappearing.
So, that's how things are now :)
r.
--
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.
--
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.
7 years, 8 months
easier_terms branch merged
by Robert Cimrman
Hi,
I have merged significant changes related to terms into the master repository.
It is easier now to add new terms. The merge resulted in:
63 files changed, 2790 insertions(+), 3765 deletions(-)
so you can see the code is much shorter now (check, e.g., the BiotTerm before
and after the merge), retaining or even improving the original functionality.
The test_install.py script reports no errors for me (and the elapsed times
should be around 40s (examples) and 80s (tests) on a recent-enough computer,
see test_install_times.log created after you run it), however note that not all
terms were updated yet for the new term evaluation code, as not all terms are
covered by tests (unfortunately).
I will update all terms eventually as I will need them, but the time frame is
vague, so let me know about any problems to increase priority of terms you need
:) The 'adding a new term' document needs an update as well, so again, if
anyone wishes to add a new term, nag here...
cheers,
r.
7 years, 8 months
[PATCH] fix typo in traitsui import
by Andre Smit
---
sfepy/postprocess/viewer.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sfepy/postprocess/viewer.py b/sfepy/postprocess/viewer.py
index 6355073..43e21e4 100644
--- a/sfepy/postprocess/viewer.py
+++ b/sfepy/postprocess/viewer.py
@@ -17,7 +17,7 @@ except:
from traits.api \
import HasTraits, Instance, Button, Int, Bool, on_trait_change
from traitsui.api \
- import View, Item, Group, H2Group, spring
+ import View, Item, Group, HGroup, spring
from traitsui.editors.range_editor import RangeEditor
from tvtk.pyface.scene_editor import SceneEditor
from mayavi.tools.mlab_scene_model import MlabSceneModel
--
1.7.6
7 years, 8 months
importing mayavi
by freevryheid
To get isfepy to run I needed to change 3 files to satisfy mayavi
installation on archlinux - really just the imports by stripping "enthought"
and changing "traits.ui" to "traitsui".
My mayavi installation comprises the following community compiled modules:
python-enthought-mayavi 4.0.0-1
python-enthought-utils 4.0.0-1
Not sure if these issues are also in the mayavi git version. Anyway - here's
the three files that change:
1. /sfepy/sfepy/postprocess/viewer.py
"""
from enthought.traits.api \
import HasTraits, Instance, Button, Int, Bool, on_trait_change
from enthought.traits.ui.api \
import View, Item, Group, HGroup, spring
from enthought.traits.ui.editors.range_editor import RangeEditor
from enthought.tvtk.pyface.scene_editor import SceneEditor
from enthought.mayavi.tools.mlab_scene_model import MlabSceneModel
from enthought.mayavi.core.ui.mayavi_scene import MayaviScene
"""
from traits.api \
import HasTraits, Instance, Button, Int, Bool, on_trait_change
from traitsui.api \
import View, Item, Group, HGroup, spring
from traitsui.editors.range_editor import RangeEditor
from tvtk.pyface.scene_editor import SceneEditor
from mayavi.tools.mlab_scene_model import MlabSceneModel
from mayavi.core.ui.mayavi_scene import MayaviScene
2. /sfepy/sfepy/postprocess/dataset_manager.py
"""
from enthought.traits.api import (HasTraits, Instance, Array, Str,
Property, Dict)
from enthought.tvtk.api import tvtk
from enthought.tvtk.array_handler import array2vtk
"""
from traits.api import (HasTraits, Instance, Array, Str,
Property, Dict)
from tvtk.api import tvtk
from tvtk.array_handler import array2vtk
3. /sfepy/sfepy/postprocess/sources.py
"""
from enthought.tvtk.api import tvtk
from enthought.mayavi.sources.vtk_data_source import VTKDataSource
from enthought.pyface.timer.api import Timer
"""
from tvtk.api import tvtk
from mayavi.sources.vtk_data_source import VTKDataSource
from pyface.timer.api import Timer
7 years, 8 months
installing sfepy.
by tone....＠gmail.com
i'm finding sfepy to be very interesting, but installing it on windows
is very much tiresome. is there any way to make the installation one-
click???
thanks.
7 years, 9 months
