Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations GregLocock on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Python findAt(...) command...

Status
Not open for further replies.

vasekx1

Automotive
Nov 29, 2006
10
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

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.
 
Replies continue below

Recommended for you

I do not have any explicit solutions to your problems, but....

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.

 
Well, I use the scripting the way you suggest - I do the features at first by recording macro and then make a clean up of the mess and use the routines in my own script, which work "the best". But still doesn't work every time - the numbering of features sometimes differ and I didn't find out any method, how to discover it in the abaqus cae for ie. edges in sketch or partition etc.

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)
 
I don't get this comment...

"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.
 
Regarding your point b) with the id of datum features...

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.
 
brep: thanks for the second advice - this is what I completely erased from the possibilities ;o) Anyway - this would work just with datums and similar things, but not with selection of features created by processing the script... This I forgot to mention - it's actually connected with my first point..

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 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)...
 
I do not agree that Python is
vasekx1 said:
"the real peace of crap"
, as you stated.


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 ( 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.
 
I will not get drawn into "my language is better than your language" type of argument...

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.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor