Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential refactoring of the backends into a solver class and a backend class #13

Closed
semi-h opened this issue Nov 2, 2023 · 0 comments · Fixed by #7
Closed

Potential refactoring of the backends into a solver class and a backend class #13

semi-h opened this issue Nov 2, 2023 · 0 comments · Fixed by #7

Comments

@semi-h
Copy link
Member

semi-h commented Nov 2, 2023

We can do a refactoring so that the backend class only provides subroutines that executes kernels. To do this we need to extract a solver class from the current backend class. For example, transeq operation is very specific to Incompact3D algorithm and we can define this under a solver class. We still need child classes for different architectures as the specifics of the operations we carry out differs based on the architecture. However, most operations solver need rely on tridiagonal solvers, so tridiagonal solver kernels can be provided via a backend class that is independent from the solver.

This could be useful when we want to extend the capabilities of the new framework such as adding low mach number support. The low mach number solver can specify its own preferences and execute transeq in a slightly different way.

@semi-h semi-h linked a pull request Nov 28, 2023 that will close this issue
@slaizet slaizet closed this as completed in #7 Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant