-
Notifications
You must be signed in to change notification settings - Fork 65
Description
Description
To facilitate the addition of new host-specific constituent properties fields without cluttering the constituent object, a new abstract class should be created that can be extended by the host models.
Solution
Proposed solution includes
- Creating new abstract class:
type, abstract :: host_constituent_properties_t
contains
procedure(host_constituent_get_prop) => get_prop()
procedure(host_constituent_set_prop) => set_prop()
procedure(host_constituent_create_prop) => create_prop()
procedure(host_constituent_has_prop) => has_prop()
end type host_constituent_properties_t
- Adding new object to constituent properties object:
type, public, extends(ccpp_hashable_char_t) :: ccpp_constituent_properties_t
character(len=:), private, allocatable :: var_std_name
…
class(host_constituent_properties_t) :: host_props
The specifics of the implementation of the host properties object are up to the host model. The only hard requirement at this point, beyond agreeing on the abstract interface, is that any added properties should not negatively impact any physics scheme or framework capability that is used by others (i.e. none of the added properties should be needed by other host models that are not using the host-specific physics features).
Note: We will also want to eventually add property standard names to the ESMStandardNames dictionary for potential shared constituent properties to keep things portable.