Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for method properties (name, etc.) #23

Closed
HugoMVale opened this issue Jul 12, 2023 · 4 comments
Closed

Improve support for method properties (name, etc.) #23

HugoMVale opened this issue Jul 12, 2023 · 4 comments

Comments

@HugoMVale
Copy link
Contributor

I think it would be helpful if the method classes included a character component storing the name of the method. Among other things, we could then run tests in a more programmatic manner.

Actually, pushing the idea one step further and combing it with #22, I was wondering if it would make sense to add the properties of a method as components of the corresponding concrete class:

type, extends (rk_fixed_step_class), public :: euler_class
    !! Basic Euler method
    integer :: p =1 ! order
    integer :: ncache = 1 ! cache size
    character(:), allocatable ::  name = "Euler"
    contains
    procedure :: step => euler
end type euler_class

I believe this would also avoid the need to have $N$ "method_order" procedures, whose sole purpose is to return p.

@jacobwilliams
Copy link
Owner

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.

@HugoMVale
Copy link
Contributor Author

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.

@jacobwilliams
Copy link
Owner

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.

jacobwilliams added a commit that referenced this issue Jul 16, 2023
added python script to generate all the files
See #23
@HugoMVale
Copy link
Contributor Author

Addressed in #24.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants