Python findAt(...) command...
Python findAt(...) command...
(OP)
Hi everybody,
I'm creating a parametric model, which is going to be automatically optimized then, using the Python scripting language. I got stuck at an absolutely unbelievable point. I'm trying to do two things:
a) select whole rectangular face partition edges - I have now used the command PartitionCellBySketch and I want to use this partition to create a whole cell partition - the above partitions just the face, which I use for creating constraints and interactions. After this point, I need to select edges to create the cell partition, so I use the findAt(..) command with multiple points inserted as variable coordinates - see the "cut out" below:
....
rectFind = pEdge.findAt((rectWidthEau/2, rectHeightEau, eauWidth/2-(rectYGouv+enl_ABSY)),
(rectWidthEau/2-(rectXGouv+enl_ABSX) , rectHeightEau, eauWidth/2),
(rectWidthEau/2, rectHeightEau, eauWidth/2+(rectYGouv+enl_ABSY)),
(rectWidthEau/2+(rectXGouv+enl_ABSX) , rectHeightEau, eauWidth/2), )
thePartEau.PartitionCellByExtrudeEdge(line=dirEdgeFind, cells=selCell, edges=rectFind, sense=FORWARD)
....
What the script does then is, that he creates the partition just by using the first edge inserted in findAt parentheses.. Does anybody has a solution? I was trying to find it everywhere and this also corresponds to examples in Abaqus 6.6-1 manual...
b) second problem is, that I can't select the datum planes other way than using the option:
mdb.models[modelName].Part(name=partNameEau, dimensionality=THREE_D, type=DEFORMABLE_BODY).datums[i]
which is not unfortunately the best way, while the id can change with version of Abaqus etc. findAt command doesn't work with this - I got a message from "Abaqus compiler", that says that. Any solution?
I'm really getting desperately angry about the Python-Abaqus guys after few days spent on solving these problems without any clear single-solution documentation and many absolutely undocumented commands...
Thanx for any advise.
I'm creating a parametric model, which is going to be automatically optimized then, using the Python scripting language. I got stuck at an absolutely unbelievable point. I'm trying to do two things:
a) select whole rectangular face partition edges - I have now used the command PartitionCellBySketch and I want to use this partition to create a whole cell partition - the above partitions just the face, which I use for creating constraints and interactions. After this point, I need to select edges to create the cell partition, so I use the findAt(..) command with multiple points inserted as variable coordinates - see the "cut out" below:
....
rectFind = pEdge.findAt((rectWidthEau/2, rectHeightEau, eauWidth/2-(rectYGouv+enl_ABSY)),
(rectWidthEau/2-(rectXGouv+enl_ABSX) , rectHeightEau, eauWidth/2),
(rectWidthEau/2, rectHeightEau, eauWidth/2+(rectYGouv+enl_ABSY)),
(rectWidthEau/2+(rectXGouv+enl_ABSX) , rectHeightEau, eauWidth/2), )
thePartEau.PartitionCellByExtrudeEdge(line=dirEdgeFind, cells=selCell, edges=rectFind, sense=FORWARD)
....
What the script does then is, that he creates the partition just by using the first edge inserted in findAt parentheses.. Does anybody has a solution? I was trying to find it everywhere and this also corresponds to examples in Abaqus 6.6-1 manual...
b) second problem is, that I can't select the datum planes other way than using the option:
mdb.models[modelName].Part(name=partNameEau, dimensionality=THREE_D, type=DEFORMABLE_BODY).datums[i]
which is not unfortunately the best way, while the id can change with version of Abaqus etc. findAt command doesn't work with this - I got a message from "Abaqus compiler", that says that. Any solution?
I'm really getting desperately angry about the Python-Abaqus guys after few days spent on solving these problems without any clear single-solution documentation and many absolutely undocumented commands...
Thanx for any advise.





RE: Python findAt(...) command...
b)It's true that ABAQUS sometimes changes the syntax of some ABAQUS Scripting Interface commands here and there in a new version, but it is nothing you can do about it, besides correcting your code to make it run for the new version. So, I would not worry about version changes. Also, the changes occurs only with major versions and they are usually listed somewhere in a manual and they are not so many.
a) From my experience, when you script a model, it is better first to model it manually in CAE to be sure the modeling approach is good. In general, what you can do in CAE (and even more) you can script. Also, you can test script portions and command syntaxes in the command prompt at the bottom of the CAE. I would recommend to try to reproduce the partitioning command in the CAE (using the menu) and see how it works. It might work in a way which is not clear from the documentation of the equivalent scripting command.
In the beginning I was also upset with the documentation of the scripting interface and I found a few mismatches between the command description in the documentation and the actual implementations.
After a while you get used to it. In fact the ABAQUS Scripting Interface is not that bad, it can save you a lot of time.
RE: Python findAt(...) command...
Anyway there is one absolutely fascinating thing - if you define some variable in the beginning, you have to redefine it in most occassions just before using it...
Thanks for advice, it was more to make me see, that it's just common ;o)
RE: Python findAt(...) command...
"Anyway there is one absolutely fascinating thing - if you define some variable in the beginning, you have to redefine it in most occassions just before using it..."
...as it is not true.
When you look at the journal file, you might see a redefinition of a variable eg.
p=mdb.models['Model-1'].parts{'Part-1']
...
but this is just a consequence of the journalling process. It is absolutley *not* a requirement for your own scripts.
The variable handling in Python is extremely powerful and any good Python reference manual will give you the details about this.
RE: Python findAt(...) command...
When you create a datum in your script you can simply return the result of the construction to a variable. E.g.
>>> p=mdb.models['Model-1'].parts['Part-1']
>>> myDatum = p.DatumAxisByThreePoint(p1,p2,p3)
Now when you refer to this datum in later lines of your script, you just refer to the myDatum.id. E.g.
>>> print p.datums[myDatum.id]
Thus, if the id changes in future upgrades, the script is not hardcoded to the old id.
RE: Python findAt(...) command...
And just an addition to the first one: regular variables, like points, strings, simple numbers and all others, which refers to strictly defined stuff are ok, but if I define a varible i.e. like >> dirEdgeFind = pEdge.findAt( vertDirPoint, ) << I have to copy this line in more places in the script to make it working (doesn't matter, whether the edge was somehow edited during the script or not - like partitioned etc.). Funny is, that it's not regular, it depends on some unpredictable occurences...
And just to bring you back to ground: I have been programming in BorlandC, C++, Basic, VisualBasic and few other scripting languages like PHP, JavaScript, HTML aso. (it's not much, but enough I think) and the Python is the real peace of crap, compared to those mentioned above (before I started using Python, I thought that the worst is MS VB and new .NET, but now I have changed my opinion ;o) ). Python does not have any good reference manual in Abaqus and the one available at www.python.org, which is much better, doesn't count with many routines, which are own just to Abaqus (and still contains too many messy pages instead of "informationful" data)... An if you finally find a good explanation of usage (especially with sample script) and aply it to the "real" script, the output is in most ocassions just an unbelievable error message (like the one mentioned in my first post)...
RE: Python findAt(...) command...
1. 0ne needs to dinstinguish between the language Python and the Python-based ABAQUS Scripting Interface. ABAQUS Scripting Interface contains C++ modules, also. But we do not say that C++ is a piece of crap.
2. I think "ABAQUS Scripting User's Manual" gives a fairly good introduction to Python and of what you can do with ABAQUS Scripting Interface....but lot of people choose to ignore its content.
3. Python is a free multi-platform programming tool. As it happens with many free tools, the documentation might not be the best you could have. If you add for example, only all the free scientific computing modules developed for it , e.g. scipy (www.scipy.org), and the GUI toolkits you might find that Python is not such a "peaceful crap". I doubt you can find so many free versatile tools for any of the languages you mentioned.
BTW: HTML is not a programming language by itself.
RE: Python findAt(...) command...
But suffice to say I suggest you look a little bit more closely at Python and its rapid rise as a programming language in the last 6 years or so. There are very good reason for this. I have met plenty of real programmers in my years, and let's just say that your opinion is very much in the minority.