Skip to content

Conversation

@talbring
Copy link
Member

@talbring talbring commented Feb 17, 2020

Proposed Changes

In order to structure the construction of the solvers a little bit and to remove the dependency of the driver on the solver, I created a static solver factory class. There are routines to create individual instances as well as the whole container. It should be much easier now to see what position in the containers are actually allocated for the different solvers.

The createSolver routine is a generic one that simply calls new. The others have some additional checks or calls for the construction. The idea here was to remove any if statements in the createSolverContainer routine to ease readability.

If everybody agrees, we could use a similar structure for other classes as well. Let me know what you think.

Note from TobiKattmann: This PR depends on #861

Related Work

Resolve any issues (bug fix or feature request), note any related PRs, or mention interactions with the work of others, if any.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

  • I am submitting my contribution to the develop branch.
  • My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
  • My contribution is commented and consistent with SU2 style.
  • I have added a test case that demonstrates my contribution, if necessary.
  • I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp) , if necessary.

@pcarruscag
Copy link
Member


LGTM what other families to you have in mind? I think doing this for the numerics would be very nice but they should move to the solver.

@talbring
Copy link
Member Author

Since I am already at it, I am gonna add factory classes for numerics (we can use them even if we move the allocation to the solvers) and integration.

Copy link
Member

@economon economon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. The factory pattern is a good one that we should have been using for a long time. I am for adding this for the integration / numerics as well.


for (unsigned short iSol = 0; iSol < MAX_SOLS; iSol++){
if (solver_container[iZone][INST_0][MESH_0][iSol] != NULL){
if (solver_container[iZone][INST_0][MESH_0][iSol] != nullptr){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the switch to nullptr

#include "../../include/solvers/CIncEulerSolver.hpp"
#include "../../include/solvers/CNSSolver.hpp"
#include "../../include/solvers/CIncNSSolver.hpp"
#include "../../include/solvers/CTurbSASolver.hpp"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting all of the headers out of CDriver is great 👍

@TobiKattmann TobiKattmann changed the title Solver Factory class WIP Solver Factory class Feb 25, 2020
void CDriver::Solver_Preprocessing(CConfig* config, CGeometry** geometry, CSolver ***&solver) {

unsigned short iSol;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well well, what do we have here 🕵 (Detective Whitespace on the hunt)


delete [] solver[val_iInst];

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🕵 This is one of the easier cases for Detective Whitespace

@dep dep bot added the dependent label Feb 26, 2020
Comment on lines 54 to 57
* \param kindSubSolver - The kind of sub solver
* \return - Pointer to the allocated integration instance
*/
static CIntegration* createIntegration(INTEGRATION_TYPE integrationType);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

integrationType instead of kindSubSolver (although integrationType directly depends on kindSubSolver as far as I understand)

case TEMPLATE_SOLVER: template_solver = true; break;
case EULER : case INC_EULER: euler = true; break;
case NAVIER_STOKES: case INC_NAVIER_STOKES: ns = true; break;
case RANS : case INC_RANS: ns = true; turbulent = true; break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we remove the functions Solver/Integration_Preprocessing (and all the *_Preprocessing routines that follow) and pull the few lines up to the CDriver constructor as it is only called from there.
This function has 4 lines of code and only hands work over to the factory 🏭 (why didn't I think earlier of using the factory emoji 🤦‍♂ )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will leave it like that for the moment. We can consider a clean-up once we have factory methods for the rest of the containers (especially numerics).

Comment on lines 47 to 50
* \param[in] kindSolver - The kind of main solver
* \return - Pointer to the allocated Output
*/
static COutput* createOutput(ENUM_MAIN_SOLVER kindSolver, CConfig *config, int nDim);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing param[in]

@talbring talbring changed the title WIP Solver Factory class Solver Factory class Mar 2, 2020
@dep dep bot added the dependent label Mar 2, 2020
Comment on lines 38 to 41
/*!
* \brief Private constructor to avoid creating instances of this class
*/
COutputFactory();
Copy link
Member

@pcarruscag pcarruscag Mar 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the const stuff, everything looks very nice.
I think it is a good idea to have a separate numerics PR.

Final note, the preferred C++11 way to achieve this is to delete the default constructor instead of making it private. COutputFactory() = delete;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thanks! If that's the preferred way then we should do it 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least according to Scott Meyers xD

@TobiKattmann
Copy link
Contributor

As all comments are addressed, I am merging this in. Thanks @talbring for the effort 💐

@TobiKattmann TobiKattmann merged commit f42191d into develop Mar 2, 2020
@TobiKattmann TobiKattmann deleted the solver_factory branch March 2, 2020 15:39
@pr-triage pr-triage bot added the PR: merged label Mar 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants