-
Notifications
You must be signed in to change notification settings - Fork 918
Update of the python fsi interface and new feature coupling SU2 with Nastran #1124
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
Conversation
pcarruscag
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very interesting especially if it makes it easier to interface other solvers.
One think I must ask is to move all mesh files to the TestCases repository and all the config files to TestCases folder.
You could also try to re-use the mesh files across your different examples, we should try to reduce the size of the repository.
Alternatively you can also create some tutorials (since you already have some readme files), we have a special repository for those, I think a tutorial would give your work more visibility.
I will leave some comments on the code once I go through everything.
|
Thank you for the feedbacks, I am working on the modifications you suggested. I will perform a couple of tests to be sure I did not break anything. Hope to commit the new code soon! |
…into publish_develop
|
I use openMPI 4.0.4 on a Linux CentOS 7 |
|
What about compiler version? If you do gcc --version what do you get? (assuming it is gcc) |
|
gcc version 4.8.5 |
|
I think that was the first gcc with official full c++11 support, and so it might not be full support... |
|
Okok, I may also try to update gcc. The only issue is that it is on a server so I should do it locally and it may take a bit more time. I will test the merge and then, with more time, update gcc. |
|
I solved for the compilation issues by upgrading gcc. Thank you for the suggestion! |
|
I'll merge this now to try to conciliate it with #902 |
|
Ok I will now try to run two main test cases I have. But there were no conflicting files after the last commit so I do not think there should be any issue. |
|
Everything seems to be fine. The test cases run smoothly. I have been following the conversation with Rocco, I will now contact him to understand how to avoid duplication and how to best integrate our works |
yep I had to move to gcc 5.3.0 recently from 4.8.5 actually quite recently... which would be in line with 7.0.6 working for you. I don't recall exactly what feature that was 🤔 Beginning of October with change to 7.0.7 and the SIMD stuff |
|
Guilty as charged. |
TobiKattmann
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I am a bit late to the party. Thanks for the contribution and adding the tutorial as well 💐
It would be nice to have a testcase in tutorials.py to safeguard it against future changes. Maybe it is wise to wait for after #902 if that changes sth (but I have no clue tbh).
Usually not everything needs its own testcase but as this adds a tutorial, so I vote here in favor of testcase.
(btw I stumbled upon this today and thought I already heard that name of the first author somewhere already :D . Big fan of Mr Brunton 👍 )
| for (unsigned long iPoint = 0; iPoint < geometry_container[ZONE_0][INST_0][iMesh]->GetnPoint(); iPoint++) { | ||
|
|
||
| /*--- Overwrite fictitious velocities ---*/ | ||
| su2double Grid_Vel[3] = {0.0, 0.0, 0.0}; | ||
|
|
||
| /*--- Set the grid velocity for this coarse node. ---*/ | ||
| geometry_container[ZONE_0][INST_0][iMesh]->nodes->SetGridVel(iPoint, Grid_Vel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess because it is automatic memory allocation with fixed values the compiler optimizes this su2double Grid_Vel[3] = {0.0, 0.0, 0.0}; away. Otherwise I would argue that Grid_vel could be created outside of at least the iPoint loop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right!
| /*--- Symmetry plane is clamped, for now. ---*/ | ||
| for (iMarker = 0; iMarker < config->GetnMarker_All(); iMarker++) { | ||
| if ((config->GetMarker_All_Deform_Mesh(iMarker) == NO) && | ||
| (config->GetMarker_All_Deform_Mesh_Sym_Plane(iMarker) == NO) && | ||
| (config->GetMarker_All_Moving(iMarker) == NO) && | ||
| (config->GetMarker_All_KindBC(iMarker) == SYMMETRY_PLANE)) { | ||
|
|
||
| BC_Clamped(geometry, numerics, config, iMarker); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahaha yes I also found it quite funny when I first saw it. But it is fine now to clamp it... As the sym plane for fluid and mesh are now separated, one will explicity use the deform mesh sym plane marker if she/he wants to obtain a symmetric deformation. Otherwise, the code will clamp deformation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was because the FEA solver did not use to have a symmetry BC.
And then when I added it, it was better to clamp the symmetry plane for my testcases :)
But now that Nicola decoupled the physical symmetry from the deformation symmetry all is well xD
|
The most critical part is the unsteady FSI, but that actually takes its time... You think it would be fine to compare the results after just few iterations for a testcase? We could use one of the simulations in the tutorial. Thanks for the interest in the youtube video! |
|
All testcases run for only a few steps, not entirely to convergence, the purpose is really just to detect change. |
|
Ok, I will prepare a test case. I will take the Mach=0.1 case from the tutorial and change it slightly. Now the coupling between fluid and structure occurs after 100 steps, I will just couple them immediately. |


Proposed changes
Dear all,
I am very new to collaboration on a open source project, but I have been working on an update for the FSI computation in python that I think may be useful also for other researcher. Would you mind giving me a feedback about the modifications?
In few words, I have updated the python interface for fluid structure interaction to the new version of SU2, including the new driver, the new mesh deformation methods and few other modifications in the python scripts. It works with python3.
As far as the C++ code is concerned, I only added the possibility to separate the symmetry boundary conditions for the fluid solver from the ones of the mesh solver. There is an explanation of this modification in the ReadMe file in SU2_PY/FSI_tools, together with an example of application.
The interface is still general and new structural solvers can be coupled by adding it to the fsi_computation.py file. With the present pull request I only include one structural solver, which provides a coupling with the commercial code Nastran.
I added ReadMe files to explain in detail all the modifications and also the keywords to be used in the config files. Finally, there is also a complete test case where the flutter of a flat plate is studied.
I am looking forward for your comments
Nicola
PR checklist