Patran Accuracy 1

[johnhors]

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 ?

 

[EdR]

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.

 

[SWComposites]

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.

 

[GBor]

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.

 

[EdR]

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.

 

[GBor]

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

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?

 

[EdR]

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.

 

[GBor]

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

 

[rb1957]

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 ?)

 

[GBor]

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...

 

[johnhors]

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.

 

[GBor]

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?

 

[rb1957]

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)

 

[GBor]

My last statement was backwards:

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

 

[EdR]

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.

 

[rb1957]

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)

 

[EdR]

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.

 

[EdR]

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.....

 

[crisb]

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??

 

[johnhors]

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.