Dear Pierre,
Many thanks for your valued input,
> Following your link for the FEM sketch, here are some first comments to help
> complete this sketch.
> Once having a more complete view of the work to be done, maybe decisions will
> have to be hold to decide doing or not this or that item.
>
> (all my comments are based on a user point of view)
> _________________
>
> I understand that you are working on "boundary conditions".
> I would highlight the following in the part "setting-up the simulation":
>
> You suggest the definition 3 functions:
> "lock", "load", "boundary"
>
> I would suggest to define for now 2:
> "boundary_conditions", and "initial_conditions"
>
> A boundary conditions is applied at boundary (of the problem which is in our
> case represented by the mesh):
> - temperature given at a face
> - locked nodes (which you defined previously as a function) (in FEM, the term
> is more often "constrained nodes")
> - for CFD (if any), why not a input flow rate?
> …
You are absolutely correct, its best to adhere to terminology used in FEM.
> Initial conditions are given to a part of the mesh, and have user-defined
> values for the first increment. These values may then evolves during the
> simulations:
> - an initial velocity applied to an object (a car)
> - a load on a face
> - stress and plastic strain states to objects that have been stamped in a
> previous step
> ...
> _________________
>
> I see then different items missing in the analysis setup
>
> a. how defining contact between objects?
What do you have in mind exactly Pierre?
I've seen examples of such transitions from one FEM element to another, but I'm
not sure whether pythonOCC is the place to define these.
Likely the best place to define this is the .comm file
The goal of the pythonOCC interface is to define mesh & initial + boundary
conditions, that's it ;')
> b. how defining joints between objects?
.comm file?
> c. how defining materials properties of objects?
.comm file?
> d. if this is a dynamic simulation (where inertia of bodies have to be
> considered), it will be solved over a time range: setup of the "duration" of
> the simulation (not the time it will take to compute, but the elapsed time it
> simulates"
Again, that is related to the simulation, we're merely interested in providing
the model for the simulation, not defining the simulation itself.
> Maybe some "automatically setup according user preferences" options should
> also be dealt with:
> e. defining integration schemes / analysis tunings
> _________________
>
> I would like to comment a bit point b.
> Defining joints between object is maybe one the "touchest" topic in a
> simulation framework such as pythonOCC. If there is most often an "easily"
> identified relationship between set of elements and physical bodies, this is
> not so true for joints.
>
> A joint is for instance a spot weld, a seam weld, a bolt, adhesive bonding...
> Sometimes, you add mater (for instance additionnal metal for welding),
> sometimes not (spot weld).
> The geometrical dimensions of these joints make "their meshing" not obvious,
> hence a specific modelling, often dedicated to a solver and an analysis.
>
> Basically, this means that such entities should be defined geometrically, and
> the important physical data should be given to a "translator" that will model
> them as finite element entities.
> Such a translator could be a specific script commanding SMESH.
>
> These "finite element entities" could be elements (beam, hexaedre, shell...)
> but also equations linking DOFs of nodes (MPC in ABAQUS,
> AFFE_CHAR_MECA/LIAISON_DDL in Code_Aster).
> _________________
>
>
>
>
> In the end, concerning shape and topology optimization, I would like to point
> another method based on R-functions that looks interesting to me (work from
> Vadim Shapiro). You can have a look of his work in this publication:
> http://cdl.engr.uconn.edu/asmeda/DAC2006.BestPaper.pdf
> But also in this one: "shape optimization with topological changes and
> parametric control"
Very interesting, much appreciated Pierre.
I still have a _lot_ of ground to cover in FEM, so likely I will come back to
this post in the near future.
Thanks for your input, its much appreciated to have such knowledgeable persons
in Code_Aster on this list, terrific!
> Please, do not hesitate to tell me of any comments.
Again, thanks very much, that's most kind of you,
Best,
-jelle
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
