Homepage | About EASA | Contact
Homepage | About EASA | Contact
This page consists of a series of authoring examples that can be used as a reference.
A powerful feature of an EASAP is its ability to dynamically update content available to users without modifying the EASAP. This task is accomplished by accessing a text file each time an EASAP is initiated and extracting out all necessary information from the file for the EASAP to use.
Once the files containing the desired information have been uploaded to the EASAP directory, information can be extracted from the files using EXTRACT in combination with FIND and REPEAT. This information can then be used as choices in a CHOICE LIST and as input data to the batch files of the underlying software applications.
In this example, the goal will be to extract a list of materials and their associated physical properties from a text file for use in a CHOICE LIST. The example material database file called
material.txt is shown below.
The steps for accomplishing data extraction from a materials database in a text file are as follows:
In addition to populating the choices of the example CHOICE LIST with the name data in ‘mname’, the extracted property data of ‘Ein’ and ‘muin’ can be used as input data for the underlying software applications of the EASAP. An example of how this data can be applied is provided in Example 4: Material Properties.
In this example, the goal will be to extract two numbers from an output text file, the minimum and maximum pressure values. Part of the output file,
output.dat, is shown below with a black arrow pointing to the line containing the desired data.
The strategy will be to first locate a unique text string just above the line containing the desired data, and then extract the two numbers of interest. This two-step approach eliminates the possibility of finding the wrong match earlier in the file.
The steps for accomplishing this type of data extraction are as follows:
Note: Only single spaces are used between the different words and characters in the Value: parameter, even though there is actually more white space in the file as shown in the file example above.
The result of this example will be that the numbers, -23.8 and 44.5, will be stored under the object names, pmin and pmax. See Using the Extract Tool.
In this second example, the goals will be to extract columns of node displacement data from an output file called
plate.out and then to determine the maximum displacement value. The relevant section of this file is shown below.
The steps for accomplishing a multiple line data extraction are as follows:
The result of this example will be that
This section contains a few examples of typical scenarios in which you will need to manipulate user inputs. In these examples, you will see how the various DATA PROCESSING Child objects can be put to use to achieve the desired data manipulation.
It is very likely that an EASAP may be analyzing something made out of some sort of material, and subsequently, software applications used in the analysis will need to have the material properties specified. Many software applications can pull this information from an existing database knowing only a material name, but many times software applications expect to receive the individual material properties as input.
From the users’ perspective, authors should avoid asking them for individual material properties and ask only for the material name. The author should then take on the responsibility for ‘mapping’ the material choice into the appropriate material property values.
This example is a continuation of Example 1: Material Property Database above, in which data extracted from a materials database file has been used to populate a CHOICE LIST.
The goal here is to determine the appropriate value for the Modulus of Elasticity and Poisson ratio for the material selected by the user.
The steps for accomplishing this type of data manipulation are as follows:
To keep input file sizes smaller and to simplify reading of inputs, many software applications make use of ‘flags’ within their input files. Flags are typically integer numbers that represent a certain setting e.g. 1 for the first possible setting value, 2 for the second setting value, etc.
Here is another instance where users of an EASAP should not be asked to supply exactly what the underlying software requires. Instead, a more descriptive, literal set of choices should be provided to the user, and again the author should then map the choices to the appropriate flags expected by the software applications.
For this example, let’s say a structural analysis code needs to have the support conditions specified for a loading analysis of a beam or plate. The three possible conditions are ‘free’, ‘pinned’ or ‘fixed’, but the code uses flags to represent these settings in its input file. Namely, these flags are: 0 for free, 1 for pinned, and 2 for fixed. The steps for accomplishing the necessary data manipulation are as follows:
Any software applications that make use of finite difference, finite element, finite volume or similar numerical methods will need to somehow divide the geometry of the object or area being analyzed into smaller, discrete pieces. This discretization of a whole into a sum of smaller pieces is also known as gridding or meshing. These types of software applications will require inputs defining how the meshing or gridding process should take place.
In general, authors should avoid requesting gridding or meshing specific inputs from users. One of the benefits of an EASAP should be the capturing of best practices, and EASAP authors are expected to be expert users of the underlying software applications. Therefore, where possible, authors should make the determination of how the meshing of a particular problem should be performed. Users should only be asked for geometric information and maybe in addition an indication of their accuracy and turn around time expectations. From this information, an author can then determine the settings for the meshing performed in the underlying software applications.
For this example, we’ll look at the analysis of a flat rectangular plate. The analysis software expects two inputs per side of the rectangle to govern the meshing process: 1) the number of elements along a side, and 2) the uniform element size along a side. It does not expect the full dimension of the side. However, the full dimensions of the rectangle are exactly what the user should be asked to supply. The steps for accomplishing the necessary data manipulation are as follows:
Often in analysis software applications, certain assumptions must be specified up front about the problem to be analyzed in order for the application to produce sensible results. A common situation that results in assumptions being made is when there are multiple ‘regimes’ governing the mathematics or physics of a problem.
Examples of these regimes are for instance in structural analysis, elastic vs. plastic deformation, and in fluid flow analysis, laminar vs. turbulent flow or incompressible vs. compressible flow. Typically, software applications need to have a single regime specified at the outset of the analysis in the input files.
Following the common theme of not exposing the needs of the underlying software applications to the user, authors should avoid asking the user to specify a regime for the analysis performed by an EASAP. There are two ways to avoid the regime question:
The example of regime selection to be provided below uses the second method, in which the regime is determined based on user inputs. In this example, the problem to be analyzed involves fluid flow in a pipe, and the regime selection is between laminar or turbulent flow. The regime will be determined from the user inputs of pipe diameter, fluid type, and volumetric flow rate. The procedure for the required data manipulation is as follows:
Note: An alternative to performing steps 10 and 11 in Example 7 would be to have two separate input files created, one set up for laminar flow and the other set up for turbulent flow. Then, all you would need to do is use the Run if: parameter in the separate PROCESS's.