F.D.+E. Calculation Wrappers for SAE Standard Files

Introduction

The Quick/Easy Way for Stress-Strain-Life Fatigue Data:

1. Open the example file in a web browser:
   __________Example Html File___________
   
   
2. Using your browser edit the file's lines in the text box.
   Adjust the "Copyright (C)..." lines to suit your own data.
   You must have a value for the elastic modulus in the
   #E=
   line. NOTE!: Do NOT use TAB to seperate columns. Use 1 or more spaces.
   
   
3. Use the "Submit" button to view the file's results.
   
   
4. Use the "Back" button to review and edit. Then re-submit.
   
   
5. When things work to your satisfaction use the browser
   "View Source" option to see the complete file in a
   window. Highlight all the text and copy and paste it
   into a file on your disk.
   
6. Suggestion: edit the example file in small sections and between
   each edit "Submit" the file and view the changes. That way if the
   file chrashes out for some reason, it will be easier to determine the cause.

The Calculation Wrapper Process in Detail:

Graphical Explanation 1.1Kb gif

Steps:

1. Create standard file(s) on your computer.
   In the present case, a standard file implies one of the new SAE/F.D.+E.
   standard files for strain-life data, stress-strain data, or rainflow
   data. Each has a specific, yet simple, format specified by FD&E or SAE.
   The user can either create his own file with any text editor, or in many
   cases the data may originate from a testing center or other supplier.
   
   Examples of standard files:
   
   • SAE Rainflow, |
   • FDE Strain-Stress, |
   • SAE Strain-Life,
     Note: An additional 2 lines must be added to the
     standard rainflow and strain_life files:

   #FileType= strain_life    # in the case of strain life files
   or
   #FileType= rainflow       # in the case of rainflow files
   
    and the line :
   
   #DataType= raw      #"raw"= measured, as opposed to "fitted"
   
   

   Which could be made part of the "standard" SAE file definition?
   The two lines simply tell the calculation site what kind of standard
   files to expect. At this time the rainflow one does not work
   on this site yet.
   
   
   
2. The user then places a "Calc Wrapper" around the standard file. This consists of 5 or 6 lines of text at the top of the file and 2 lines at the bottom of the file.
   The wrapped file is saved back on the user's own disk.
   Examples :
   • Wrapper_Head |
   • Wrapper_Tail |
   • Wrapper_Script. Note that the wrapper script will work on a Linux
     operating system, but will require alterations to run
     on MSWindows.
     
     
     
   • Using a web browser such as Firefox, the user then must
     Open File... i.e. open and view the file just created
     and placed on your hard drive somewhere.
     
     
     
   • Select an option at the top of the page such as "Plot" or
     "Calculate" and then click on the Submit button.
     (At the moment only Plot works.)
     

Future:

• As long as you place data into the standard format it can be displayed/ graphed. Thus you can put a lot of things in this format and still get them graphed ( or analysed, in the future).
  
  
• People who do tests for you can send you their results in this format via email if you wish. If you use your browser for mail you can "pop" the attached files right there to view or analyse them.
  
  
• You can correct or change the data easily. Use notepad in Win.. or vi in Linux, or whatever your favorite editor may be. Beware however that your editor is set to NOT format the page. In the standard file there are comment lines and data lines. If the lines are joined together or "end wrapped" around to make a new line by your editor, you will have problems. Turn this feature OFF before you edit.
  
  
• Since the head/tail wrapped standard files are also "HTML" pages, they can be placed in a folder on your local web server and, voila, you have a database of files (cheap). You will probably want to add an index page "above" the standard files, but not much else is required - only the SAE standard files (text files, mostly). Our site at the Univ. of Waterloo has a simple file structure: dindex.html example. Using one real data set (plus some "virtual" sets to demonstrate the layout) we have created a structure to show how to start your own database.
  
  
• If you do not have access to a web server, a simple folder in your own disk will accomplish the same thing. After you "open" the first local page from your own machine, like an index, your browser can find the other pages that the index points to.
  
  Open Page... -> index_file -> file1_fatigue_life.html
  
  Thus even if you don't wish to set this up for other people you can have your own browsable database.
  
  
• In the Head of the wrapper there is an HTML address or URL pointer which vectors the file contents to a calculation site. Initially in this case the site is https://fde.uwaterloo.ca/ and the process it executes there is "catgnume". It is easy to change this site to some other that you prefer to get the service from. It is also not terribly difficult for your own web administrator to set this up on your own server. In fact if you dual load Linux alonside your MSWindows system, and you then choose a Linux boot, an APACHE web server is often running, and it is fairly simple to provide a similar calculation site for whatever data types you happen to like.
  
  

Problems:

• Security: Because the transportation of your wrapped file data and the return transport of the results is not presently encrypted, the data could be "observed" by sites using "packet sniffers". Although the probability of such acts is fairly low, it is still a possibility and the user should not transmit any sensitive files in this manner. If the F.D.&E. folks decide that the whole thing has merit, we may try to test some encryption methods in the future.
• HTML "pointers" in the data files do not work when they are in a text field, such as created by the saeheadwrap and the saetailwrap text lines. The user must click on the submit button and when the file/data returns the pointers become active and can then be clicked for further files.
• When the plots come back, the directory or folder in Netscape becomes the same as the address of the calculation/plot handling software. "Relative" HTML pointers such as: a href="anotherfile.html" will thus go to the wrong address. It is therefore necessary, presently, to use the full path in imbedded html pointers. This may be an advantage in the long run, as it prevents confusion as to where files came from, but it does make transfer of directory structures across systems more difficult.
• The gnuplot utility does a nice job of plotting hysteresis loops, but the quality of the strain-life plots leave much to be desired. We are working on getting some better plot routines.
• We are working on getting some data fitting (least squares, etc) routines.

Future:

• It would be interesting to have a "large" computer facility involved, such as the one at U. Illinois, to handle large files -filtering RPC road load files for example. A problem that would arise is the transfer of "large" RPC files (these days (1999) a large web file is 10Mb), and it would not be good citizenship to ship a lot of these around the net. A general rule should be "Keep the files small, and the problems large".
  
  
• Many fatigue life computational problems involve "small" input files of loads or life information and long process times. Simulating the propagation of a crack through a stress concentratioin zone under variable amplitude loads can take a long time, particularly if one attempts to do it for a large number of FEA results, for example. Under such circumstances it might be useful to ship a standard file to the cgi-bin handling routine of a "broker" machine. The broker could split the problem into smaller chunks and assign them to some willing secondary computation machines.
  
  Visual of Concept
  
  The compute load of the calculation machines could be announced to the broker in some automatic method using similar forms of standard files. After the individual machines have completed their parts of the solution they transmit their results back to the broker who collects and returns them to the client. Such a distribution of the computation would allow one to pose questions such as: "Give me the life predictions for my Rainflow file for all 600 materials in the distributed FDE materials data base" and the means of obtaining a result fairly quickly.
  
  
• If one takes another step and assumes that not only the problem input files, but also the output files from the cgi sites, have a standard format, one can then "plug" the results into another problem and repeat the process. Thus we could have a standard "raw" data strain-life fatigue file that is sent to a cgi calc site, is reduced and comes back as the common 6 or 7 strain-life fatigue parameters, or a "fitted" digital curve, and is then sent to another program that uses it and a rainflow file to compute life. In a rough analogy one could compare the raw strain-life file to a "problem-bolt". Our problem-bolt gets sent to a calc site and returns as a "solution-bolt". In the meantime a raw time history (problem-nut) is sent to a cgi site and returns as a rainflow file or "solution-nut". When they have both returned, along with possibly a Kt/FEA description ("solution-washer?"), the whole thing gets re-assembled into a solution-prediction. This might then be returned to the originator/broker who is assembling a whole bunch of FEA predictions etc. etc.

  As long as a given problem is big enough to warrant the effort, and decomposible into smaller segments, the method may be worthwhile. This type of feature may require inventing some sort of problem identification tag for files, e.g.:
  
  #pit= /leftside/front/assembly102/part15/bolt1
  
  which would require another addition to the standard file description.

How to Proceed?