Dear Jelle, Communication by mails is not simple :-).
Ok, here is what I understand. Relating to my previous mail, the primary target for pythonOCC is to have "level I" functionalities: generating a mesh, and some groups. I will write a bit less in this mail (I have said all I know on this topic in my previosu mails :-)), and only ask questions :-): 1. > The FEM.py would "just" have a command to start the solver >> I would say yes for meshing / conditions, no for starting the solver. The reason is really simple: for a trivial problem this would be doable, but I do not see how this is within scope of the PythonOCC project. Cannot a python program execute a sh command like: "Code_Aster_Installation_Folder/as_run Code_Aster_export_file.export"? This is what I call "a command to start the solver." It is much like any other command to start any other executable :-). 2. >> I do think that there is sufficient reason to implement meshing and boundary / initial conditions in pythonOCC however. Please Jelle, I beg you, what do you mean by "to implement [...] *boundary / initial conditions*"? => is it only to create groups of elements or nodes in the generated mesh? => if not, do you mean that you will modify boundary / initial conditions of an existing model? => if so, how? It would be really graceful of you to definitely shed some light on this topic (and also maybe detail this part in the FEM.py sketch). I thank you in advance for your help. Best regards, Pierre 2010/2/25 Jelle Feringa <jelleferi...@gmail.com> > Regarding functions necessary for level I: > you don't even need to implement a function to group elements and nodes and > give them a name: > it already is an SMESH fuctionality > > > True in Salome, False in pythonOCC. > The methods related to grouping are currently not working. > > So, assuming that SMESH functions are used to create a MED files with > appropriate groups, I would say that a first version of FEM.py could be > really, really simple: > - "just" a command to start the solver > (ok, and all the others for error management) > > > I would say yes for meshing / conditions, no for starting the solver. > The reason is really simple: for a trivial problem this would be doable, > but I do not see how this is within scope of the PythonOCC project. > > Take care though; I do not know much ( if anything ) about FEM. > So if you can prove me wrong, please do so. > > - regarding result post-treatment, this may be more complicated, because > according to what you study, the result file to consider will not > necessarily be always the same. > > > Well, do not forget that Salome is a good project, with impressive post > processing capabilities. > For sure we wouldn't like to produce a second version of Salome ;') > > I do think that there is sufficient reason to implement meshing and > boundary / initial conditions in pythonOCC however. > Meshing is well implemented for the moment, and once the missing methods on > SMESH_Mesh surface, it will be easy to make a simple example. > > For instance, something like this tutorial by Kees Wouters would be > interesting: > http://www.caelinux.org/wiki/index.php/Contrib:KeesWouters/plasticity > > or > > > http://code-saturne.blogspot.com/2010/02/cfd-example-laminar-flow-along-2d.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+FreeYourCfd+%28Free+your+CFD%29 > > So, this example _would_ contain the .comm and .export file, such to > _demonstrate_ > how one can achieve Code_Aster ( Code_Saturn ) integration. > ( with a README that questions related to the solver should be asked on the > Code_Aster forum ;') > > I'm very much looking forward to completing such an example! > > Take care, > > -jelle > > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
