
In a multispan beam, we write for the deflection of the th span, where
and where is the span's length. The coordinate indicates the
location within the span, with corresponding to the span's left endpoint.
Thus, each span has its own coordinate system.
We assume that the interface of the two adjoining spans is supported on springs
which (a) resist transverse displacement proportional to the displacement (constant of
proportionality of (d for displacement), and (b) resist rotation proportional to the
slope (constant of proportionality of (t for torsion or twist). The spans are numbered
from left to right. The interface conditions between spans and +1 are
1. 
The displacements at the interface match:
.

2. 
The slopes at the interface match
(0).

3. 
The difference of the moments just to the left and just to the right of the
support is due to the torque exerted by the torsional spring:

4. 
The difference of the shear forces just to the left and just to the right of the
support is due to the force exerted by the linear spring:

The special case of a pinned support corresponds to and .
In that case, condition 3 above implies that ,
and condition 4 implies that
Let us write the displacements and in terms of the KrylovDuncan
functions as:
Then applying the cyclic properties of the KrylovDuncan functions described
earlier, the four interface conditions translate to the following system of four
equations involving the eight coefficients .
,
which we write as a matrix equation
.
That coefficient matrix plays a central role in solving
for modal shapes of multispan beams. Let's call it .
Note that the value of enters that matrix only in combinations with
and . Therefore we introduce the new symbols
, .
The following proc generates the matrix . The parameters and
are optional and are assigned the default values of infinity and zero, which
corresponds to a pinned support.
The % sign in front of each Krylov function makes the function inert, that is, it
prevents it from expanding into trig functions. This is so that we can
see, visually, what our expressions look like in terms of the functions. To
force the evaluation of those inert function, we will apply Maple's value function,
as seen in the subsequent demos.
> 
M_interface := proc(mu, L, {Kd:=infinity, Kt:=0})
local row1, row2, row3, row4;
row1 := %K[1](mu*L), %K[2](mu*L), %K[3](mu*L), %K[4](mu*L), 1, 0, 0, 0;
row2 := %K[4](mu*L), %K[1](mu*L), %K[2](mu*L), %K[3](mu*L), 0, 1, 0, 0;
row3 := %K[3](mu*L), %K[4](mu*L), %K[1](mu*L), %K[2](mu*L), 0, Kt/mu, 1, 0;
if Kd = infinity then
row4 := 0, 0, 0, 0, 1, 0, 0, 0 ;
else
row4 := %K[2](mu*L), %K[3](mu*L), %K[4](mu*L), %K[1](mu*L), Kd/mu^3, 0, 0, 1;
end if:
return < <row1>  <row2>  <row3>  <row4> >^+;
end proc:

Here is the interface matrix for a pinned support:
And here is the interface matrix for a general springy support:
> 
M_interface(mu, L, 'Kd'=a, 'Kt'=b);

Note: In Maple's Java interface, inert quantities are shown in gray.
Note: The in this matrix is the length of the span to the left of the interface.
Recall that it is , not , in the derivation that leads to that matrix.
In a beam consisting of 