Remove SolverABC

[hsaunders1904]

Linked Issues

Closes #1423

Description

Removes SolverABC and incorporates its functionality into CodesSolver. Fortunately, SolverABC wasn't used in many places.

I do think we may be missing a piece of the puzzle, in that we have Builders that make CAD, Designers that design CAD, but we don't have a base 'calculator'. It could be that we don't actually need one, but I think it's worth a discussion at some point. #1611 contains one suggestion.

Interface Changes

No more SolverABC.

Checklist

I confirm that I have completed the following checks:

• Tests run locally and pass pytest tests --reactor
• Code quality checks run locally and pass flake8 and black .
• Documentation built locally and checked sphinx-build -W documentation/source documentation/build

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
0.0% Duplication

[hsaunders1904]

I've just noticed that RunMode is used in equilibria, but I've moved it into codes. This probably needs to be resolved before we can think about merging this.

Edit: although, the transport solver is using a CodesSolver from codes anyway. What do you think, @je-cook?

[je-cook]

I've just noticed that RunMode is used in equilibria, but I've moved it into codes. This probably needs to be resolved before we can think about merging this.

Edit: although, the transport solver is using a CodesSolver from codes anyway. What do you think, @je-cook?

We could put them both under an if typing.TYPE_CHECKING: as a quick thing. It may be quite difficult to resolve otherwise.

If we have better solutions than that I am open to them but I imagine we will come across these typing dependency things quite regularly.

[github-actions]

⚠️ Warning Report

Found 0 new warnings, 0 fixed warnings. 🎉

[hsaunders1904]

We could put them both under an if typing.TYPE_CHECKING: as a quick thing. It may be quite difficult to resolve otherwise.

The concern is more of an architectural one - modules should be as 'standalone' as we can make them, and, where possible, only rely on things in base and probably utilities. In theory, we could definitely have a transport solver that's not a CodesSolver in the case of fem_fixed_boundary.

Since I noticed that the dependency on codes was already there, I'm less worried about this being merged. But I think we should consider this issue as part of #1611 (or open a new ticket)

[je-cook]

I'm happy with this as is with the open issues.

It may be nice to have a CodeSolver example that isnt dependent on having any code installed. Maybe instead of getting that in here we should open an issue for that. I think it could be made from the example thats deleted here.