Replace get_lhs and get_rhs with something more appropriate

[ahojukka5]

I just realized the obvious when thinking about dynamic analyses. We have to rename the commands how the local matrices are assembled. Here is a short memo

• Eigenvalue analysis
• Modal analysis
• Damping matrix?
• Explicit Euler
• Newmark https://en.wikipedia.org/wiki/Newmark-beta_method
• HHT (Hilber-Hughes-Taylor) http://opensees.berkeley.edu/wiki/index.php/Hilber-Hughes-Taylor_Method
• BDF
• Crank-Nicholson method
• Backward Differences Formula (BDF) https://en.wikipedia.org/wiki/Backward_differentiation_formula
• Bossak
• Generalized alpha-method http://opensees.berkeley.edu/wiki/index.php/Generalized_Alpha_Method
• Linear multistep methods https://en.wikipedia.org/wiki/Linear_multistep_method
• Energy-momentum methods (EMM)
• Generalized energy-momentum method (GEMM)

The thing is that while technically we are finally always solving linear system of equations, i.e. Ax=b, which has left hand side and right hand side, in implicit methods the same global matrix (mass matrix for instance) can be in both sides of equation. In multistep methods (like BDF2) earlier solutions are used to stabilize the next solution and again depending on the order of method they can be on left or on right side. While there is always some kind of fundamental Ax=b with LHS and RHS, it depends heavily from solution algorithm what actually is on left and and what is on right side.

So while this a(u,v) = l(v) canonical form works for some set of problems very well it's not general enough. Any suggestions for better naming convention, @JuliaFEM/owners ? It's not a big job to change this in this point of development but later on it definitely will be so the changes must be done immediately.

[ahojukka5]

What first comes to mind is to have something like

• get_stiffness_matrix
• get_mass_matrix
• get_damping_matrix
• get_force_vector

which would work for linear systems (Mu'' + Ku = f) well, but I suspect this is causing some headaches with non-linear systems, where the equation is more like Mu'' = f(u), where f(u) contains (at least) internal forces f_int(u) and external forces f_ext(u). And depending from problem type, some interface forces like f_contact(u) etc. If we are using automatic differentiation then we don't have to take care of linearizing f(u) to tangent stiffness but of course it should still be possible.

Yet another source of confusion would be Dirichlet boundary conditions (and contact boundary conditions for instance) which contribute to both sides. Technically the lhs is mass matrix like thing without anything or very little to do with mass.

Anyway it should be now very obvious that calling get_lhs and get_rhs is way too straightforward approach to ask for a local element matrices.

[ahojukka5]

After thinking a bit we could start from virtual work or residual vector, and get_lhs and get_rhs are more like low level function calls, which are used internally but can be defined also by user.

[ahojukka5]

Now we have

• get_mass_matrix
• get_stiffness_matrix
• get_force_vector

for a "traditional approach", which is activated using has_mass_matrix, has_stiffness_matrix and has_force_vector set true for equation. Furthermore, we have

• get_residual_vector and has_residual_vector if only residual force vector is known and ForwardDiffhandles automatic differentiation of jacobian. This situation arises when equations are derived using principle of virtual work.

-get_potential_energy and has_potential_energy if only potential energy of system is known and ForwardDiff handles automatic differentiation of hessian + gradient of equation. This situation arises when equations are derived using principle of minimum potential energy.

Finally, we have calculate_local_assembly! which can be overridden by user defined function if nothing above doesn't fit for needs. This for example allows to access problem (=larger set of equations) if element needs to interact with other elements, which is the case in interface problems (fluid-structure-interaction, contact mechanics, ...)