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 ?
"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
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
RE: Patran Accuracy
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
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
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 ??????????????????
What is that supposed to mean? To me, this makes no sense...anyone have an idea?
RE: Patran Accuracy
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
RE: Patran Accuracy
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
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
http://en.wikipedia.org/wiki/Significant_figures
http://ch
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
RE: Patran Accuracy
but 0.123 and 0.124 are clearly different (even in single precision)
RE: Patran Accuracy
RE: Patran Accuracy
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
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
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
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
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
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
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
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