Grid vel in SU2 has to be a vector defined on the nodes in the global frame of reference. The blowing velocity computed in BLASTER is a scalar quantity computed on the elements. It has to be interpolated and projected.

However the solution seems only slightly affected by the blowing velocity computed.

For whatever reason, ther LE element is duplicated in SU2 (although it is defined once in the mesh). So we need to be careful when imposing the blowing velocity

objects can be created. Transfer squantities not ok

Boundary layer results can be saved in vtk format. Correctly handle inputs fuselage for fuselage and added fuselage type in c++ classes

Now the viscous solver is created after the interface. This allows less user inputs and avoids conflict between parameters. The blSolverInterface class was reworked and documentation was improved. The sections can now have no wake or only one side (for fuselage for example). Bug fix here and there and ajusted tests. Only the onera validation case is up to date.

Now a python virtual env is created to use the latest versions of scipy and numpy

The data structures of the viscous solver have been reworked to avoid lists of lists of lists... Users now have the possibility to automatically generate sections on wing or to use prescribed section from another mesh. First option requires to identified upper and lower sides and this information is also used by the rbf interpolator.

Removed the requirement of a transfinite surface mesh to generate viscous section. They are now generated by interpolation of the convex hull (wing) using scipy. This works best if we identify the upper and lower sides of the wing. 2 tests are given; NACA0012 airfoil in 2D with RBF interpolation and RAE2822 wing in 3D with rbf as well.  There might be a problem with parallel run of tests. Validation cases are not updated yet. Usage of LFS mesh is prevented on purpose so the 3D validation cases will fail.

Use the function getSolution in utils to get the viscous solution

BLASTER v1.0

See merge request !1

Avoid modifying install path if the project is a submodule. In that case, installation is handled by the top project.

DART is imported from the submodule if possible or from the blaster install path under blaster/dart. Custom install path can be specified in dartCfg as dart_path.

Avoid forcing installation location