Finite element analysis solution algorithms

Furthermore, it must be evaluated whether the data representations currently provided in AMOS are efficient enough to support discretisation operations. If more efficient data representations are required, a similar approach to the matrix data source, de-scribed in Section 5.2.3, might be applicable where foreign and specialised data repre-sentations were implemented and made available from AMOS. For this purpose, it might be suitable to apply a tree data structure as described in Fenves [39].

Finally, it would be most interesting to investigate if function materialisation techniques [149] could be applied in this context to automatically handle computation and caching of, for instance, derived topology functions.

equation system is performed by applying the operations that correspond to Eqs. (67), in Section 5.2.3. We see that:

(69) the factorisation of K should return a diagonal matrix and at least one upper unit trian-gular matrix. If we, for instance, consult Hughes [23], we see that the LDL factorisation produces a diagonal matrix, D, where the matrix elements have the same unit as the el-ements of K. Further, for the upper and lower unit triangular matrices, U and U^T, the elements are unitless. Continuing with the solution of the upper triangular equation sys-tem,

(70) this operation should produce a displacement vector a. When considering the bbf bind-ing pattern, this operation should produce a displacement vector x, since U is unitless.

Consistently, the next diagonal scaling operation

(71) should generate a displacement vector x with the bfb binding pattern, whereas the bbf binding pattern should return a load vector y, due to the multiplication of stiffness ele-ments in D with displacement eleele-ments in x. Finally, for the operation that solves the lower triangular system

(72) a load vector y should be produced since f is a load vector and U is unitless. Conse-quently, the bbf binding pattern for this operation returns a load vector with the present arguments.

If the original matrix multiplication operations have been carefully designed, they will produce the correct result type for several cases. For instance, in Eqs. (70) and (72), the correct type will be produced since it is deduced from one of the argument or result types. However, when the result type is dependent on combinations of argument and re-sult types, as in Eq. (71), special treatment is needed. In the present case, this function is overloaded for the domain types signatures. Likewise, the result type of D in the ftorisation operation, corresponding to Eq. (69), is domain-dependent. Here, this is ac-complished by overloading this operation on K.

By using these basic matrix operations, the solution of the system can be stated in AMOSQL in a very convenient notation. Presuming that a stiffness matrix and a load vector exist and are bound to the interface variables :k and :f respectively, the

K^b = (U^T)^f⋅D^f⋅U^f

U^b⋅a^f = x^b

D^b⋅x^f = y^b

U^T

( )^b⋅y^f = f^b

AMOSQL query for solving the displacements would look like:

select a for each displacement_vector a where :k * a = :f;

Figure 41. The representation of application domain types, such as stiffness, loads, and displacements, as subtypes of matrices in the matrix taxonomy. The taxonomy is here somewhat reduced to simplify the presentation.

The stiffness matrix, K, could have been modelled with either of the available represen-tations, i.e. as a subtype of the ^regular or ^skyline matrix schemes that implies a reg-ular or a skyline representation of the equation system. However, this does not change the expression for the solution algorithm and the system automatically creates matrices with the appropriate types and selects the correct operations to solve the equation sys-tem. By providing several matrix representations schemes, the application can

explicit-matrix

row vector column vector square

upper triangular

upper unit triangular lower triangular

lower unit triangular matrix scheme

regular skyline sparse

symmetric stiffness regular matrix fea concepts

stiffness load

displacement

symmetric

diagonal triangular

diagonal stiffness matrix load vector

displacement vector

symmetric stiffness skyline matrix

ly choose a suitable representation depending on the problem type, or implicitly, by let-ting the query processor make the decision based on type information or a potential cost model. The DBMS could also support the derivation of the correct type representation by using a derived type mechanism as described in Werner [93], but this facility was not available at the time of this work. Thus, the potential convenience of using derived types must be further evaluated.

If the solution algorithm were embedded within an application, it would be suitable to represent it as a database function that could be accessed from the application. This is expressed as follows:

create function lin_solve(symmetric_stiffness_regular_matrix k, load_vector f) -> displacement_vector a as select a where k * a = f;

and overloaded for the skyline representation:

create function lin_solve(symmetric_stiffness_skyline_matrix k, load_vector f) -> displacement_vector a as select a where k * a = f;

A small example¹ in Figure 42 is used to show how this can be used in problem solving.

The compact representation using skyline matrices is assumed in this example. The cre-ation of the basic matrices and the solution of the corresponding equcre-ation system are performed by the following AMOSQL statements:

set :k = construct(“symmetric_stiffness_skyline_matrix”,{{1.0}, {-1.0,2.0},{-1.0,2.0},{-1.0,2.0}}});

set :i = construct(‘iarray’,{0,2,4,6});² set dindex(:k) = :i;

set :f1 = construct(“load_vector”,{1.0,0.0,0.0,0.0});

set :a = solve(:k,:f1);

print(:a);

{4,3,2,1}

1. Normally, matrices are created and updated by calling database functions from the application which are inconvenient to use in textual examples. The syntax for inter-active manipulation of matrices is somewhat temporary and has been slightly mod-ified to shorten the presentation of the examples.

2. It is not necessary to create the index array :i of the skyline matrix :k explicitly but this is the current procedure.

It is further possible to express the repetitive solution of the same problem for different load cases by overloading the solve function on bags¹ of load vectors. This would be expressed as:

create function lin_solve(symmetric_stiffness_skyline_matrix k, bag of load_vector f) ->

displacement_vector a as select a where k * a = element(f);

Figure 42. An example equation system with a 4x4 stiffness matrix, a displacement vector with 4 unknowns, and two load vectors including one non-zero component each.

Combining the load_vector ^:f1 with another called ^:f2 into a bag ^:fseq makes it pos-sible to express the corresponding solution in the following manner:

set :f1 = construct(“load_vector”,{1.0,0.0,0.0,0.0});

set :fseq = {:f1,:f2};

set :aseq = lin_solve(:k,:fseq);

print(:aseq,0);

{4,3,2,1}

print(:aseq,1);

{8,6,4,2}

It should be noted that, by overloading matrix operations, the domain conceptualisation will hold independently of how each concept is represented or how the operations are implemented. As discussed earlier, the declarativeness of the query language makes it possible to achieve both logical and physical data independence. Since the schema in

1. Actually, one would like to have a sequence of load_vector instead of a bag (or multiset) to preserve order but, as have been pointed out earlier, this capability is not currently available in AMOSQL.

1 –1 0 0 1

– 2 –1 0 0 –1 2 –1 0 0 –1 2

a₁ a₂ a₃ a₄

⋅

1 0 0 0

2 0 0 0 ,

=

our case not only includes data descriptions, but also operator descriptions, this inde-pendence of physical and logical implementation becomes valid for operations too.

For instance, in the present context the solution of a triangular equation system A b = c, where A is a triangular matrix and b and c are column vectors, is expressed in AMOSQL as:

select b for each column_vector b where :A * b= :c;

This expression is independent of how the C-procedure that solves this system is imple-mented which results in physical implementation independency.

Furthermore, by replacing the name of the variables in this expression, the expression solves a linear equation system K a = f, where K is a symmetric matrix and a and f are column vectors. However, this solution includes a transformation of the equation sys-tem into a set of simpler equations, according to Eq. (68), that is expressed by an AMOSQL expression. The transformation in Eq. (68) could be replaced by a different transformation that also solves the linear equation systems, for example by applying a different matrix decomposition method. This does not influence the expression of the solution in terms of the times operator on the highest level. Hence, a form of logical im-plementation independency is achieved.

In this sense, the term “data independence” might be unsuitable to use in some situa-tions and a more suitable term could, for instance, be physical and logical implementa-tion independence.

Since both structure and process of the application domain can be captured, we can model complete parts of the domain knowledge independently of any application.

Hence, this provides sharing of domain knowledge among applications and further fa-cilitates its reuse. Furthermore, the ability of the query optimizer to handle domain models including concepts, data representations, operators, and cost models that are main-dependent, can be viewed as a form of domain compilation. Hence, we have a do-main compiler that uses dodo-main knowledge in the compilation process.

Further work in this area would be to develop corresponding domain models for other parts of the FEA process, such as calculating element quantities including the element stiffness in Eq. (32) and the element loads in Eq. (33). The possibility of using matrix algebraic expressions for this purpose must be studied in more detail.