Skip to content

Simple "plugin" architecture for forward model components #22

@davidraythompson

Description

@davidraythompson

Currently we explicitly import the all surface or RT model options (e.g. surf_multicomp.py, surf_glint.py, et cetera) upon initialization, and specify the appropriate one at the top-level config file. Writing a new surface model variant thus requires expanding the top-level configuration format options and modifying forward.py. A more elegant alternative would use a dynamic import, which would let the user write their own surface model classes and designate their filepath in the forward model configuration block. This would preclude the need for hard-coded string names for each surface type. A user writing a variant surface object would not have to alter forward.py, they'd just change the configuration file. The same would go for instrument models, RT models, and maybe inversion methods also. The resulting "plugin" style architecture would be more dynamic and reduce duplicate code.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions