Improve support for method properties (name, etc.) about rklib HOT 4 CLOSED

Ok, got it.

2nd iteration: we take the logic currently used to deliver the order p, but instead return a derived data type called properties with all we might need:

type :: properties
    integer :: p
    integer :: ncache
    character(:), allocatable ::  name
    ...
end type

We add a get_properties method to rk_class (which will replace the order method for variable step methods)

type,abstract,public :: rk_class
...
procedure(properties_func), deferred :: get_properties
end type

For each method, we define a properties function (replacing what is done today for order):

pure module function rkbs32_properties(me) result(res)
    implicit none
    class(rkbs32_class), intent(in) :: me
    type(properties) :: res
end function rkbs32_properties

and update rklib_variable_orders accordingly:

submodule(rklib_module) rklib_properties
implicit none
contains
    module procedure rkbs32_properties
        !! Returns the properties of the [[rkbs32]] method
        res%p = 3
        res%ncache = 1
       res%name = "rkbs32: Bogacki-Shampine 3(2) method"
    end procedure rkbs32_order
...

I suppose this would work because it is just an extension/generalization of what is done currently.

from rklib.

This is a good idea. I'm going to work on it.

Actually, I'm working on a script to generate all this boilerplate code (interfaces, include files, etc.) automatically. I can add these to that. So we just specify the properties of the methods in a table and the code is autogenerated by a python script.

from rklib.

There are some problems with that though. For example the value of p is used in the stepping algorithm, so it needs to be able to get the value from all the methods. As a type-bound procedure, it is always available, If it was just a variable in all the extended classes, we would have to add a million select type (me); class is (...) statements to access it, which seems not ideal.

If we put these variable in the abstract class, then we'd need to set their values in some initialization step, which also would probably mean a select type there. So neither way seems great.

from rklib.

Addressed in #24.

from rklib.