×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Patran Accuracy

Patran Accuracy

Patran Accuracy

(OP)
A colleague of mine brought the following to my attention:-

"Actually, because Patran is single precision, accuracy is only 6 sig figures (even though can write out 7 figures, the last is not necessarily accurate)

A workaround to problems with significant figures/accuracy is to scale the model larger in Patran so that the coordinate values are defined accurately with 6 significant figures"


MSC Software knowledge database
Product Line: Patran
Solution#: 2900


Am I missing something here ?

RE: Patran Accuracy

johnhors:

Don't think you are missing anything.....32 bit real values generally support about 6 or 7 digits of precision....Since Patran (and most other) preprocessing codes only deal with coordinates, properties, etc. this precision is enough to represent most real structures....However for the solution of equations this is not enough precision to get accurate solutions and double precision ( which gives about 15 digits) is used in almost all (probably all) codes....

Ed.R.

RE: Patran Accuracy

Except, we typically don't know the real loads or material properties to more than 2 or 3 significant digits, so using an FE code to output stresses to 10 significant digits is just silly or dumb, depending on your point of view.

RE: Patran Accuracy

As critical as your statement sounded SW, I tend to agree.  I recently made the move from the marine industry to the aviation world.  In a discussion with a DER, they were shocked to find out that I worked to 0.25" precision in my previous life (marine world), but when your structures are measured in 10's or even 100's of feet, 0.25" is pretty accurate.

I recently had a situation where, in the aviation world, we were arguing over an analysis to the nearest millimeter on a part that was approx. 900 mm in diameter.  My problem with this was, just how accurate do you think FEA can be?  The material was pretty well known and the geometry virtually perfect (just like we build it in the "real world"), but...?  Why do we think conservativism was built in to original equations?

I think this line of thought has been hashed out in a previous thread, but JohnHors started this one with a little more technical specifics.

RE: Patran Accuracy

SWC


I'm absolutely astonished that you don't believe each and every digit of the resulting stresses, strains, displacements, velociities, accels,....etc. for an analysis....you have probably set the engineering world back 50 or 100 years with this lack of faith......

Ed.R.

RE: Patran Accuracy

JohnHors,

I wasn't really paying that close of attention the other day when I snapped off my reply, but do I understand correctly that the MSC Knowledge Database is where it says

Quote:

A workaround to problems with significant figures/accuracy is to scale the model larger in Patran so that the coordinate values are defined accurately with 6 significant figures
??????????????????
What is that supposed to mean?  To me, this makes no sense...anyone have an idea?

RE: Patran Accuracy

GBor:

Actually I don't have much of an idea either but I suspect what they are trying to suggest is to change the range of input data e.g. instead of using mm for a structure that has dimension ranges from 0 - 10^8 mm change the units to m (with a range of 0 - 10^5). When the stiffness, etc. is computed using the values with the smaller range AND THOSE VALUES ARE THEN ASSUMED EXACT for doing the computations less error will occur than by using the larger range values. I'm not sure this is absolutely true but that's my best guess as to what is being said.

Keep in mind that the values used for coordinates, mat'l props, etc. (and the errors introduced by those values) are different than the errors introduced by and during the solution...and its the solution errors that can generate trash results....(think of the 2 spring problem with stiffnesses differing my several orders of magnitude as opposed to the springs being represented by bar elements still having differing stiffnesses but having coordinate differences which are in the 5-th or 6-th digit)

Ed.R.

RE: Patran Accuracy

Hmmmm...have to digest that one a little, Ed. R., but sounds pretty good on the surface.  Thanks, G-

RE: Patran Accuracy

i take it you're modelling something very small.

i think scaling dimensions would reduce the number of significant digits.

of course you could always scale in PATRAN say 3 or 4 orders of magnitude, and then in your FEM solver of choice, you could un-scale the input ... that'd save you having to convert all the units (E, inertia loads?, pressure loads ?)

RE: Patran Accuracy

OK.  Significant figures:

Any non-zero number to the left of the decimal.

Any explicitly expressed number to the right of the decimal (including zeros).

Any number between two significant digits.

Precision:

The number of significant digits to the right of the decimal.

Accuracy:

How closely to the accepted value a particular result approximates it.

If these definitions are correct, then scaling may only increase the precision of the input, but not necessarily the accuracy.  For instance, if I have something that is exactly 1.000 meters long, in order to improve the precision of the answer, I might scale the input to 1000.0.  This doesn't improve the accuracy and actually reduces the precision.  It increases the number of significant digits from 4 to 5, but if I fail to put that '0' after the decimal point, then it actually reduces them from 4 to 1.  In this example, the precision is actually lower in the second number, based on my definitions above (which, incidentally, are paraphrased from a couple of high school science books).

Sounds like you would have to really be careful...

RE: Patran Accuracy

(OP)
A quick gleam from google yielded these two sites:-

http://en.wikipedia.org/wiki/Significant_figures

http://chemed.chem.purdue.edu/genchem/topicreview/bp/ch1/sigfigs.html


However both these sites and much of the discussion above seem to be more concerned about how the number is written down and interpreted. The computer software stores the coordinate data as a real floating variable and it is the precision that the program uses that is important. I simply fail to understand how a scaling of the model geometry can improve accuracy. The numbers 123.456 and 123456. both have six significant numbers. Simply scaling the coordinates will only change the position of the decimal point in output displacements and stresses, the actual digits will be the same.

Assuming that this scaling is done within Patran with it's single precision arithmetic, then if anything accuracy is likely to deteriorate with extra unnecessary operations on the data.

RE: Patran Accuracy

I guess the way I was viewing it was for situations where the movement of the decimal allows for additional input considerations.  For instance, while we may input 1.23456789 (I know, anyone working in the real world would laugh at such an entry, but as analysts, we may do this).  In reality, the software may only consider 1.234567.  If you scale it by a factor of 1000, then the number becomes 1234.56789.  The software will always represent numbers to the right of the decimal, but only consider certain precision to the left.  Is that true?

RE: Patran Accuracy

i thought it was a question of distinguishing 0.000123 from 0.000124, or maybe 0.000000123 from 0.000000124 ?  the latter pair have 9 significant digits (no?) and single precision numbers probably won't distinguish them ...
but 0.123 and 0.124 are clearly different (even in single precision)

RE: Patran Accuracy

My last statement was backwards:  

Quote:

"...will always represent numbers to the left of the decimal, but only consider certain precision to the right"

RE: Patran Accuracy

rb1957:

No....numbers are stored in computers as a binary fraction plus an exponent (the number of bits allocated to each can vary depending on the machine and/or operating system)...Thus all three of the number sets you show above have 3 digits of precision (123 or 124 which are represented as a binary fraction) with only the exponents differing. The problems arise when taking these number, ASSUMING THEY ARE EXACT, and then doing computations involving subtractions (which loose precision) in subsequent computations....

gbor:

I'm stiil chewing on your definitions above but don't think they are quite correct....I was waiting until I could get home to a numerical analysis book to check them....


Ed.R.

RE: Patran Accuracy

ed,

that's how i thought FORTRAN (as an example) worked ... storing numbers as their logs ... maybe PATRAN is different (at least i think that's what the folks at MSC would want us to believe, based on their suggestion)

RE: Patran Accuracy

gbor:

The references johnhors cited give the same basic definitions I was thinking about and I believe they are a bit different than what you defined.....

johnhors:

Taking the numbers you posted and taking a difference of 1 in the last digit and then doing a subtraction gives....

123.456 - 123.455 = 1^10(-3)...a reasonable range for 6 digits
123456  -123455  = 1^10(-6)...at the limits of range of 6 digits

You could also consider using 1 added digit (say 5 in the 7-th digit) for each of the above operations giving

123.456-123.4555 = 5^10(-4)
123456 -123455.5 = ?^10(-7) depending on math unit


now consider using each of these numbers for a large number of additional computations (+,-,*,/) as is required in stiffness formulation and equation reduction computations

 It is the propagation of these types of computations which is important...(and as I noted previously particularly subtractions)

Ed.R.

RE: Patran Accuracy

rb1957:

Yep...and I'll bet that Patran is written in Fortran...

I may even have seen some of the code many moons ago....

Ed.R.

p.s. It's not acutally logs but rather a base 2 number fraction.....

RE: Patran Accuracy

I just input coordinates 123456 with various exponents into my FE program (double precision) and then exported as a .nas file.

Know this is extreme... but this is what I get:

GRID           1        123456.0 1234.560 12.34560       0
GRID           2        1.234560 0.012346 .1235E-3       0
GRID           3        0.123456 .123E-10 .12E-100       0

(have added a few spaces to make it easier to read)

I don't use Nastran or Patran but does it look as though there could be scope for reduction in accuracy as the exponent gets very big??

RE: Patran Accuracy

(OP)
Hi Chris,

What you are seeing there is really only a format output issue when using nastran's fixed eight character field, which is easily overcome by using GRID* instead which uses a fixed sixteen character field.

Yep, you could lose a heck of a lot of accuracy if you inadvertently squeezed in exponents into an eight character field with very large or very small numbers, but as I said above the sixteen character field is plenty of space to get the required precision.

EdR, scaling is applied across the board and as you said earlier the way values are stored with the exponent bit seperate it then follows that scaling ain't going to improve accuracy.

RE: Patran Accuracy

johnhors:

You may be right....I haven't convinced myself yet that scaling can't buy some improved accuracy if its done correctly and on all applicable values.

Ed.R.

RE: Patran Accuracy

I ran into this problem just recently while improting *.bdf files back into Patran.  This is what was found.

Importing the geometry from CATIA into PATRAN left me with a detailed and accurate geometry which was a couple inches in length.  The origin of the reference coordinate system was sufficiently far away from the geometric structure (approx 200").  This geometry was then meshed in PATRAN, and input files (*.bdfs) written for NASTRAN.  The *.bdf files were transfered to another engineer, who ran the analysis and then improted the *.bdf back into PATRAN for post-processing.  What was found was that the once smooth mesh was now textured, and subsequent runs of the file failed due to bad element geometry.  I was puzzled.

My colleague pointed out that to solve this problem, the nodes need to be in a ref. coordinate system which is local to the geometry as the precision is lost due to the limitied number of significant figures being carried in the *.bdf.  With very small global edge lengths, (approx 0.01 - 0.05), what was happening is the loss of precision caused nodes to be move relative to eachother due to rounding.  This in turn altered the element shape, causing the error messages during analysis.

jetmaker

RE: Patran Accuracy

If you are modeling an aircraft component with Patran and got the geometry in aircraft coordinates and in millimeters, the lack of significant figures would matter a great deal.  With the first four or five significant figures common across the entire model, then there can only be two or three that define your mesh.  Scaling does not fix this problem, but translating the geometry to a local coordinate system for modeling does.  I generally try to use a coordinate system with the origin inside or on the boundary of the model so all of the significant figures have meaning to the analysis.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources