refactor: create class variables for supported models and engines

[goccert25]

Pull Request doc

Purpose

What is the larger goal of this change?
Create a single place where supported models and engines are listed for the Grid class. This will allow the download manager project to easily use those supported models and engines as choices for CLI parameters

What the code is doing

How is the purpose executed?
Adding class variables to Grid

Testing

How did you test this change (unit/functional testing, manual testing, etc.)?
unit tests

Where to look

N/A

Usage Example/Visuals

N/A

Time estimate

How long will it take for reviewers and observers to understand this code change?
1 minute

[jenhagg]

I believe source can also be a path to a .mat file which contains a modified grid. See L#47 where this is handled.

[goccert25]

@jon-hagg updated the input validation to account for this. I think long term though the source parameter should be refactored to be an object that's passed into this class. In other words, this logic:

        if cached is not None:
            data = cached
        elif source == "usa_tamu":
            data = TAMU(interconnect)
        elif os.path.splitext(source)[1] == ".mat":
            if engine == "REISE":
                data = FromREISE(source)
            elif engine == "REISE.jl":
                data = FromREISEjl(source)

should exist outside of the Grid class. This makes the code more maintainable by using dependency injection. As the code base grows, adding more source/engine options and tests to this class is going to become more of a PITA. Thoughts on adding a github issue/jira ticket/asana task (not sure how action items are tracked 😅 ) for refactoring this Grid class?

[danielolsen]

A github issue is probably best. This idea doesn't quite fit into our definition of a 'feature', but I think the feature request issue template is probably the best to use for a refactor like this.

[rouille]

We also need to factor out a lot of code from the TAMU class since other grid models will have the same input files (CSV) with the same columns and header.

[danielolsen]

Part of that work was done in my branch daniel/read_hifld_grid, which is behind develop by a bit, but most of the relevant commits should be cherry-pickable without any merge conflicts.

[jenhagg]

LGTM