Skip to content

Conversation

@jayantmukho
Copy link
Contributor

Proposed Changes

This is a restructuring of the solver classes in the fashion of what has been done for variable classes, output classes etc. Changes include:

  • Moving all solver .hpp and .cpp files into individual class specific files
  • Moving all inline functions into the header files
  • Some bits of code cleanup

Things still left to be done:

  • Updating the IDE files
  • Any other things that might come up in the review process

This has mostly just been copying and pasting things around. If there any thing else to address in the solver classes (menial or significant) that would be appropriate to include in this restructuring, let me know in the comments!

Related Work

@pcarruscag is already working on the CFEASolver in #843. I have split the files here as well since it was already automated. But I can just merge with his branch in the likely case that his PR is ready for merging before this one.

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.

Copy link
Member

@pcarruscag pcarruscag left a comment

Choose a reason for hiding this comment

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

Nice work @jayantmukho, I hope that script helped with moving the inlines.
General question, did you update the #include "solver_structure.hpp" automatically or manually (fixing the compilation errors one by one)? I ask because this kind of file restructuring gives us a good opportunity to make sure we are including files only where needed, which helps with build times.

Apart from the two comments below, I would add that it would be nice to put virtual (override or final) and const specifiers where appropriate, at some point, not necessarily now.

@jayantmukho
Copy link
Contributor Author

Nice work @jayantmukho, I hope that script helped with moving the inlines.

Yes! It did. I was able to build off the script you gave me to enable moving multi-line inlines. Now it only fails when the function signatures don't match up (because of different variable names). I've attached it here:
split_inlines.txt
merge_inlines.txt

General question, did you update the #include "solver_structure.hpp" automatically or manually (fixing the compilation errors one by one)? I ask because this kind of file restructuring gives us a good opportunity to make sure we are including files only where needed, which helps with build times.

I replaced the solver_structure.hpp files with just CSolver.hpp first. Then quashed errors by specific solver includes when needed. But its a good point. I will go through it again to remove any unnecessary includes that might have crept in.

Apart from the two comments below, I would add that it would be nice to put virtual (override or final) and const specifiers where appropriate, at some point, not necessarily now.

Ah yes, this is a good time to do this. Will do.

@talbring
Copy link
Member

@jayantmukho Thanks for that restructuring. When you are finished use the two commands in the new folders from the script externals/utils/replace-tabs-and-trim-trailing-whitespaces.sh to replace tabs and to remove whitespaces.

This is probably the part where most of the people will encounter conflicts and problems. I can only encourage everybody to merge with develop ASAP. It won't get any easier.

Copy link
Contributor Author

@jayantmukho jayantmukho left a comment

Choose a reason for hiding this comment

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

Some things came up while going through with a fine tooth comb. A couple of unused functions, and an unused boundary condition

* \param[in] val_coord - Location (x, y, z) of the max residual point.
*/
// inline void AddRes_Max(unsigned short val_var, su2double val_residual, unsigned long val_point, su2double* val_coord) {
// if (val_residual > Residual_Max[val_var]) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are a couple of functions like this that I found no references to elsewhere in the code. So I have them commented out for now. Will be removing them soon.

You can find the functions by searching for TODO. Some in CSolver, CEulerSolver, CIncEulerSolver

* \param[in] val_marker - Surface marker where the boundary condition is applied.
*/
// inline virtual void BC_Neumann(CGeometry *geometry,
// CSolver **solver_container,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This boundary condition (BC_Neumann) doesn't seem to be implemented anywhere. It is also not mentioned in the config template.

Unless there is a plan for this, I was going to take out all references to the Neumann boundary conditions. Including the option from config_structure.cpp.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe it is from the time when there was a Poisson solver?

Copy link
Member

Choose a reason for hiding this comment

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

It is. The BC_Dirichlet was also from the Poisson solver, not sure if it is used elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@koodlyakshay you are right, the BC_Dirichlet is just an empty function in CEulerSolver.

I'll remove both. Thanks for the input!

break;
// case NEUMANN: TODO
// solver_container[MainSolver]->BC_Neumann(geometry, solver_container, numerics[CONV_BOUND_TERM], config, iMarker);
// break;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the only call to BC_Neumann

@jayantmukho
Copy link
Contributor Author

Thanks for taking care of the merge with develop @pcarruscag, I am going to make some simple formatting changes to the CFEASolver and CMeshSolver so that they conform to the rest of the solver files

Copy link
Contributor Author

@jayantmukho jayantmukho left a comment

Choose a reason for hiding this comment

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

I still have to change the visual studio and xcode project files. I haven't done this before so if anyone has any tips, links, how-to's, that'd be greatly appreciated.

/*--- Distance vector from iPoint to jPoint ---*/

su2double dist_ij[MAXNDIM];
su2double dist_ij[MAXNDIM] = {0.0};
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just getting rid of some Wmaybe-uninitialized flags

unsigned short iMesh,
unsigned long Iteration,
unsigned short RunTime_EqSystem,
bool Output) override;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the formatting I had mentioned. I'd changed all the other solver files so I figured CFEASolver and CMeshSolver can join in the makeover

inline void BC_Normal_Displacement(CGeometry *geometry,
CNumerics *numerics,
CConfig *config,
unsigned short val_marker) final { }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pcarruscag I'm assuming you have some plan for this and BC_Sine_Load functions which is why these are the only definitions of them

Copy link
Member

Choose a reason for hiding this comment

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

I do not

inline void BC_Sine_Load(CGeometry *geometry,
CNumerics *numerics,
CConfig *config,
unsigned short val_marker) final { }
Copy link
Contributor Author

Choose a reason for hiding this comment

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

^^

CSolver ***solver,
CConfig *config,
int val_iter,
bool val_update_geo) override;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

added an override over here

|| (donor_config->GetKind_Solver() == DISC_ADJ_INC_RANS)
&& (donor_config->GetEnergy_Equation()));
|| (donor_config->GetKind_Solver() == DISC_ADJ_INC_RANS))
&& donor_config->GetEnergy_Equation());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is purely to get rid the last pesky -Wparentheses warning. Logic is still the same

Copy link
Member

Choose a reason for hiding this comment

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

Don't suppress that warning until someone says something about it, I left a post merge comment in #839, the logic looks fishy.

Comment on lines 33 to 50
#include "../solvers/CSolver.hpp"
#include "../solvers/CEulerSolver.hpp"
#include "../solvers/CIncEulerSolver.hpp"
#include "../solvers/CNSSolver.hpp"
#include "../solvers/CIncNSSolver.hpp"
#include "../solvers/CTurbSASolver.hpp"
#include "../solvers/CTurbSSTSolver.hpp"
#include "../solvers/CTransLMSolver.hpp"
#include "../solvers/CAdjEulerSolver.hpp"
#include "../solvers/CAdjNSSolver.hpp"
#include "../solvers/CAdjTurbSolver.hpp"
#include "../solvers/CHeatSolverFVM.hpp"
#include "../solvers/CFEASolver.hpp"
#include "../solvers/CTemplateSolver.hpp"
#include "../solvers/CDiscAdjSolver.hpp"
#include "../solvers/CDiscAdjFEASolver.hpp"
#include "../solvers/CFEM_DG_EulerSolver.hpp"
#include "../solvers/CFEM_DG_NSSolver.hpp"
Copy link
Member

Choose a reason for hiding this comment

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

These should go to the cpp otherwise a change to any solver will trigger recompilation of all drivers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oooo, that's a good point. Will move these

Comment on lines 198 to 201
inline CVariable* GetNodes() const {
assert(base_nodes!=nullptr && "CSolver::base_nodes was not set properly, see brief for CSolver::SetBaseClassPointerToNodes()");
return base_nodes;
}
Copy link
Member

@pcarruscag pcarruscag Jan 26, 2020

Choose a reason for hiding this comment

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

Methods returning non-const pointers to class members should not be declared const IMO. While the method itself does not change the state of the object, it still provides a way to (changing the nodes in this case), this would allow a function taking a const CSolver* to change its state via such methods which would be misleading.
So, until we can return const CVariable*, this should not be const.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair enough, I agree.

@jayantmukho jayantmukho merged commit 1a64163 into develop Jan 27, 2020
@jayantmukho jayantmukho deleted the restructure_solvers branch January 27, 2020 17:49
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.

6 participants