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.
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.