Dear Jelle,
I would like to come back on 3 items following our email discussions which
seems to me points on which we do not have the same understanding yet.
*1. boundary / initial conditions topic:*
I strongly suggest to stop naming it that way.
The feature that is target is finally to be able to create element and/or
node groups with pythonOCC.
These groups are necessary for several purposes as ~every~ physical
entities I have been speaking about in previous emails are defined thanks to
groups (boundary / initial conditions, as well as bodies, contact,
joints...).
The ability to create and name element and/or node sets is a very important
functionality, but its use is definitely not restricted only to boundary /
initial definitions.
~~~~~~~~~~~~~~~~~~~~~~~~~~
I have seen that you started a FEMIntegration page with subtitles:
"Integration of FEM meshing / boundary conditions"
I think it should be more like:
"Integration of FEM meshing and group labelling" (or something like that)
(create groups of element and/or node and give them label)
What do you think?
~~~~~~~~~~~~~~~~~~~~~~~~~~
*2. .export file for Code_Aster*
Personally I think the .comm simulation syntax is quite ok with the EFICAS
editor, but I **hate** the way the .astk / .export files are created.
I'd love to work around this, perhaps the PyQT code you submitted offers
perspective here?
Jelle, I urge you to consider the .export file as you see the .comm file.
The .export file is part of a Code_Aster model at the same level than a .med
or .comm file.
It contains the names for those latter file.You cannot use it without
modifying a .export file from a previous calculation on a new Code_Aster
model.
When using Salome, if you already accept to use a module to create a file
such as SMESH for *.med and EFICAS for *.comm, what is the problem then in
using ASTK for *.export file?
Finally, if you assume that when using pythonOCC, the user has to have an
already running Code_Aster model, he/she will have all the files he/she
needs: i.e. .comm, .export, .med and so on...
*3. FEM interface in pythonOCC*
Jelle,
I would like to discuss the content the logical "functionality packages", or
let's even say the "roadmap" concerning pythonOCC FEM module. That is to
say, I identify functions that grouped together make sense.
Could we now define these groups of functionalities please?
///////////////////////////////////////////////////////
*package A.
*First, let's focus on the two primary functions that should be implemented
in pythonOCC, which are also SMESH global functions:
a.- meshing
b.- grouping and labelling
This should be a start, and I think only this.
I don't think then that it makes sense to have the ability to start
Code_Aster calculations yet, and read back results in pythonOCC.
I don't know of any elegant solution to make the user format correctly
his/her simulation so that one retrieves the results that can be read by
pythonOCC (for instance, MED file are not writtent by default in Code_Aster,
you have to require them)...
With these functionalities, we will be able to do something in pythonOCC
like:
~~~~~~~~~~~~~~~~~~~~~~~~~~
smesh_mesh = box.mesh()
f1,f2,f3,f4,f5,f6 = Topo(box).faces()
smesh_mesh.GroupOnGeom(f1,'load')
smesh_mesh.GroupOnGeom(f4,'fixate')
~~~~~~~~~~~~~~~~~~~~~~~~~~
The user will have then to make use of the produced result file by his/her
own.
///////////////////////////////////////////////////////
*package **B.* The following capabilities are then targeted to start simple
calculations (one body only - linear static simulation) from pythonOCC:
The functionalities added are:
c.- initialization of the calculation environment (solver)
d.- definition of the analysis (only static loading right now)
e.- definition of body and related properties (only one body)
f.- definition of initial and boundary conditions
g.- write() and start() calculation
With these functionalities, and dealing with code_Aster only right now, we
will be able to do something like this in pythonOCC:
~~~~~~~~~~~~~~~~~~~~~~~~~
f1,f2,f3,f4,f5,f6 = Topo(box).faces()
smesh_mesh = box.mesh()
smesh_mesh.GroupOnGeom(f1,'load') # define loading
smesh_mesh.GroupOnGeom(f4,'fixate') # define boundary
conditions
smesh_mesh.GroupOnGeom(box,'myBox') # define body
# initialize solver options (could be the same for CalculiX (solver
dependant))
mySolver=Code_Aster('64bits', 'installationFolder')
#initialize calculation (same for calucliX (solver independant))
myCalculation=FEMcalculation('SinglePrecision', 'nberOfCPU',
'calculationFolder')
#define FEM model
# initialize analysis (same for CalculiX (solver independant))
myAnalysis=FEManalysis('staticLinear')
# staticNonLinear would deal with material non linearity, as well as
contacts
#define material
myMaterial = material()
myMaterial.E=210 # Young modulus, GPa
myMaterial.nu= 0.3 # poisson's
myMaterial.rho=7.8e-9 # density ton/mm^3
# give material properties to the box / there could be additionnal
parameters (thickness for shell)
# (this part is still solvere independant (could be the same with CalculiX))
myBody = body('box','myMaterial')
myBoundaries = constrainedNode('fixate') # nodes on f4 are
contrained
myLoads = load('load', 100, 0, 0) # apply 100 N with
respect to X
myFEMmodel = FEMmodel('myBody', 'myBoundaries', 'myLoads', 'myAnalysis')
# write down FEM model according to a solver - the following interfaces are
then solver dependant
# (to implement CalculiX will require to have some specific functions for
CalculiX for instance)
myFEMmodel.initialize('myFEMmodel', 'mySolver', 'myCalculation')
myFEMmodel.write() # for Code_Aster, write down .export,
.comm and .med files
# the write() method write ASCII files for Code_Aster in the same way thatn
the templates do in Salome
myFEMmodel.start() # start calculation
~~~~~~~~~~~~~~~~~~~~~~~~~~
///////////////////////////////////////////////////////
*C.* Following capabilities are target to read back results.
This can be done because now, we fully master how entities are named, where
there are (calculation folder), what files are written (results in med
file)...
The functionalities added are:
h.- interface VTK and pythonOCC
~~~~~~~~~~~~~~~~~~~~~~~~~~
viz = VtkVisualizeAnalysis(myFEMmodel) # show the Von Mises stresses in
VTK
viz.camera = display # display is the OCC
viewer instance we use
viz.display() *# w*
~~~~~~~~~~~~~~~~~~~~~~~~~~
///////////////////////////////////////////////////////
*package **D.* Add material non linearities:
i. Deal with hardening curve
///////////////////////////////////////////////////////
*package **E.* Add new analysis: dynamic, thermal, modal...
///////////////////////////////////////////////////////
*package **F.* Now that interesting simulations can be started and results
can be retrieved, let's consider optimisation...
j.- let's talk with Frederic Renou (OGACA project) and see if his work can
be interfaced with pythonOCC
k.- let's also speak of this work with guys from FreeCAD. If they are
interested, they may give a hand to progress more quickly, most notably for
the next step, which is a very big one.
///////////////////////////////////////////////////////
*package **G.* Add multi-bodies simulations capabilities (tricky topic,
because dealing with "advanced" modelling capabilities of the solver):
j.- Transform interface so that we can deal with several bodies, several
materials
k.- Add contact definition
l.- Add joints definition
///////////////////////////////////////////////////////
Jelle, I hope you will consider these proposals.
I can help most notably when it will come to write python functions to
write down the Code_Aster files.
If this suits you, we could detail the interfaces in pythonOCC, that
is to say detail your FEM sketch
<http://svn.gna.org/viewcvs/pythonocc/trunk/src/addons/FEM/FEM.py?rev=576&view=markup>.
The name of the various functions, attributes... can be well defined
once we have started.
If you set up the basis of the write() method for Code_Aster, I can
start working on filling them.
Do not hesitate to comment any of these proposals.
Best regards,
Pierre
PS:
Jelle, if you read back my previous mails (gathered together, you
should already have a small book :-)),
you should be able to see the link with the notion of "FEM interface"
and my proposal to consider the STEP AP209 standard.
The idea would be to define/name the pythonOCC FEM functions according
to the AP209 whenever it is possible.
~~~~~~~~~~~~~~~~~~~~~~~~~~
This would most notably ensure the possibility to save the FEM model
in a neutral format (the AP209).
I see on the OCC website that OCC would offer already some
compatibility with this format.
Can you confirm and indicate us if there are already some link in
pythonOCC with this work?
http://www.opencascade.org/about/news/issue103/
http://www.opencascade.org/about/news/issue108/
~~~~~~~~~~~~~~~~~~~~~~~~~~
There may also be a tool from NASA: PGEF
I think that Thomas was speaking of this tool but that is was not open
source, right?
http://step.nasa.gov/pde2007/PGEF_PDE2007.pdf
~~~~~~~~~~~~~~~~~~~~~~~~~~
Also, did you know this presentation? I found it interesting about the
STEP modularization:
http://me.kaist.ac.kr/upload/course/MAE647_2009/STEP_AMs_intro_090511.ppt
It speaks about a STEP module repository on Sourceforge: I was
surprised, I didn't know it existed...
http://stepmod.sourceforge.net/
I don't know if some reading/writing tools are available with it.
~~~~~~~~~~~~~~~~~~~~~~~~~~
Finally, maybe the jsdai also offer some compatibility with STEP AP 209?
I am sorry. I hope you are not overwehlmed by all these suggestions.
A good next step, if most of these proposals suit you, is to detail
them in a wiki page to display a clear view to other pythonOCC
members.
Best regards,
Pierre
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
