Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Why the references to cards & decks?
- Thread starter trainguy
- Start date
![[bigglasses]](/data/assets/smilies/bigglasses.gif "[bigglasses] [bigglasses]")
Good point... however, the use of cards and decks bring organization to the "lines" of code.
It would be very difficult to debug lines of code (which are nothing more than numbers in most cases)! Therefore, it is much easier (for my brain, anyway) to think of all the bulk data entries as cards in a deck that can be shuffled and organized as I see fit.
These are just my thoughts...
Hombre
It would be very difficult to debug lines of code (which are nothing more than numbers in most cases)! Therefore, it is much easier (for my brain, anyway) to think of all the bulk data entries as cards in a deck that can be shuffled and organized as I see fit.
These are just my thoughts...
Hombre
trainguy,
In a way I have some sympathy with what you are saying - although initially in F.E.A. the required data was presented to a computer on various punched cards, you're right to suggest that computers haven't solved like this for a long time.
However, many of the solvers still use the analogy of cards to help the user understand the format in which data must be entered to ensure it meets the solvers expectations and required standard. If you just inserted any old number any old where in the deck - how could you be sure of what the solver calculated ? You could liken this to computers not representing programs and data as 0s and 1s, but it helping users and programmers communicate and understand functinality by representing information in this way.
I personally still refer to material data as being on cards - possibly because of my training - but maybe a more modern analogy might be to refer to them as sub-routines, with the numbers in them as global/local variables ?
Sean
In a way I have some sympathy with what you are saying - although initially in F.E.A. the required data was presented to a computer on various punched cards, you're right to suggest that computers haven't solved like this for a long time.
However, many of the solvers still use the analogy of cards to help the user understand the format in which data must be entered to ensure it meets the solvers expectations and required standard. If you just inserted any old number any old where in the deck - how could you be sure of what the solver calculated ? You could liken this to computers not representing programs and data as 0s and 1s, but it helping users and programmers communicate and understand functinality by representing information in this way.
I personally still refer to material data as being on cards - possibly because of my training - but maybe a more modern analogy might be to refer to them as sub-routines, with the numbers in them as global/local variables ?
Sean
Trainguy
Nearly all of the original benchmark FEA packages were written in FORTRAN and the solvers in assembler. The FORTRAN code is written between columns 7 and 71 in an 80 column record length. Columns 1 to 5 are used for logical reference numbering of statements, while column 6 is a line continuation column. Columns 72 to 80 are used for numbering the lines of code. This was done in case the cards were dropped and needed to be put back in order. For a programmer this could spell disaster. NASTRAN used the same record length of 80 characters for their input fields as it lined up with the 80 character length cards. In large measure this has survived, and even if you are able to read a PATRAN generated NASTRAN bulk deck, it will still be in this format. The "ECHO" is also in this format, if my memory serves me correctly. The input reader routines were written in the 70's, and not changed, "don't fix what aint broke". Some preprocessors allow "free format" input, but behind the scenes this is still converted into the 80 character fixed format of the original NASTRAN input.
So, what you are experiencing, comes from a long line of tactical decisions made many years ago, which still impact on your use of the S/W today.
Ed.
Nearly all of the original benchmark FEA packages were written in FORTRAN and the solvers in assembler. The FORTRAN code is written between columns 7 and 71 in an 80 column record length. Columns 1 to 5 are used for logical reference numbering of statements, while column 6 is a line continuation column. Columns 72 to 80 are used for numbering the lines of code. This was done in case the cards were dropped and needed to be put back in order. For a programmer this could spell disaster. NASTRAN used the same record length of 80 characters for their input fields as it lined up with the 80 character length cards. In large measure this has survived, and even if you are able to read a PATRAN generated NASTRAN bulk deck, it will still be in this format. The "ECHO" is also in this format, if my memory serves me correctly. The input reader routines were written in the 70's, and not changed, "don't fix what aint broke". Some preprocessors allow "free format" input, but behind the scenes this is still converted into the 80 character fixed format of the original NASTRAN input.
So, what you are experiencing, comes from a long line of tactical decisions made many years ago, which still impact on your use of the S/W today.
Ed.
![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question