pulse backend string model parser

[DanPuzzuoli]

Summary

Closes #53.

Bring string model parser from Aer into dynamics. Currently a work in progress as I attempt to reduce the original number of files and lines of code involved.

Details and comments

[DanPuzzuoli]

This PR is ready for review. I think it adds the "smallest usable unit" that makes sense for parsing the pulse backend model strings.

All non-test files added are in qiskit_dynamics/pulse/string_model_parser. The main function, and probably the only one that should be used, is string_model_parser.parse_hamiltonian_dict, which takes in the backend hamiltonian dictionary, and returns:

• The static hamiltonian,
• The hamiltonian operators (i.e. the terms with time-dependent coefficients in the form of channels/signals), and
• A corresponding list of channel labels for the terms with time-dependent coefficients.
• A dictionary containing subsystem labels as keys and dimensions as values

In subsequent developments, the operators can be used to construct a model or solver in dynamics, and the list of channels will be used in the schedule -> signal conversion routine put the output signals in the right order.

Some notes:

• The legacy_parser.py file compartmentalizes the actual string parsing part from the Aer pulse simulator, which is untested and that is treated as a black box. At this stage I think there are diminishing returns to trying to understand/test it, and putting it in this file is an attempt to make it clear that we are purposefully compartmentalizing it.
• I've tried to document the expected input format in the doc string for parse_hamiltonian_dict. I think this doc string is important to review.
• I've put everything into it's own subfolder since it consists of several files but there's really only one meaningful function coming out of it. I'd be interested in comment on this structure as well.

[DanPuzzuoli]

Not sure why I can't reply to the one comment about adding the output to one of the examples in the docs.

I'm kind of on the fence about this - two of the outputs of the function consist of arrays and so showing them isn't necessarily too informative. Given that this function is primarily for internal use anyway I'm leaning towards not adding this.

[brosand]

Not sure why I can't reply to the one comment about adding the output to one of the examples in the docs.

I'm kind of on the fence about this - two of the outputs of the function consist of arrays and so showing them isn't necessarily too informative. Given that this function is primarily for internal use anyway I'm leaning towards not adding this.

Not sure why I can't reply to this one either haha, but this makes sense,

[DanPuzzuoli]

@chriseclectic I think I've addressed most comments with the latest changes. The remaining things to discuss are:

• Usage of the word "legacy". Maybe we can change the file to regex_parser.py and this function to regex_parser - this will drop the problematic terminology and may be a more informative name (indicating this is where the true "parsing" happens).
• Using underscores for functions/classes that are meant to be internal: I'd prefer not to do this as I feel like it is unnecessary and I don't really like the way it looks. I think the fact that these things aren't being imported into the standard packaging structure/API, along with the warnings in the files, should be sufficient to imply that they are internal?

[DanPuzzuoli]

Closing this PR as it is extremely out of date - will reopen a new one.