-
Notifications
You must be signed in to change notification settings - Fork 847
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
Evaluate time-varying boundary conditions and motion at the end of the time step for implicit temporal schemes #2353
Comments
Time
, TimeIter
, and IC Outputs Not Correct?
The solution is always at the end of time steps, to restart at time iter 2 you need 0 and 1 |
Hi @pcarruscag, thank you for your response but I am referring to an issue I found when not restarting and just using the freestream as the initial condition - because the solution is always at the end of timesteps, after inner iterations are completed on the 0th iteration / 0th timestep, SU2 outputs a I feel that before SU2 performs any inner iterations, it should output Please let me know if I am misunderstanding anything, I found this issue when wanting to use the freestream as an initial condition without a restart file. |
I do understand the confusion but the iteration indexing is 0-based, so at iteration "i", ""i+1" * dt has elapsed. |
That makes sense, thank you for the explanation but I think there are a lot of places in the code that presume that the time to be solved for is SU2/TestCases/py_wrapper/dyn_fsi/run.py Lines 61 to 66 in 0e1495c
SU2/SU2_CFD/src/solvers/CFEM_DG_EulerSolver.cpp Lines 3322 to 3325 in 0e1495c
SU2/Common/src/grid_movement/CVolumetricMovement.cpp Lines 2116 to 2123 in 0e1495c
SU2/Common/src/grid_movement/CSurfaceMovement.cpp Lines 3433 to 3437 in 0e1495c
SU2/SU2_CFD/src/solvers/CMeshSolver.cpp Lines 992 to 996 in 0e1495c
The last 3 in particular seem to avoid this assumption by checking if the iteration is 0. To reiterate I may be completely misunderstanding here (if the intention for everything is to be IMEX), but want to confirm this with you. It may be worthwhile to add clarifications regarding this to the documentation. |
That is right, for time-implicit approaches we should have everything at the end of the timestep. |
Should I open a new issue then for this documenting it? Or should we re-open this one and change the title? |
Time
, TimeIter
, and IC Outputs Not Correct?
There seems to potentially be a bug with doing an unsteady dual-timestepping simulation without a provided initial condition (restart file):
When no restart file is provided, the first inner iterations have Time_Iter=0 and Cur_Time=0 (the state before these inner iterations). After completion of this time iteration, a file
flow_00000.vtu
and all others are outputted. These files are not the initial condition as specified by the configuration file -- they seem to actually be the solution after the first time step. This can be reproduced easily in the config file I have attached to this issue (an updated version of TestCases/plunging_naca0012 for SU2 v8). Theflow_00000.vtu
file has non-uniform flowfields, which doesn't make sense.For simulations where a restart file like
restart_00000.dat
is provided, the Time_Iter=1 and Cur_Time=dt (the state after these inner iterations), and the subsequently outputted files have the correct time iteration appended to it.I think that for non-restart unsteady simulations, the IC should be outputted as solely just the initialization before any inner iterations are completed, Time_Iter++ and Cur_Time+=dt, and THEN inner iterations performed.
plunging_NACA0012.cfg.txt
Bug report checklist
Please make sure that you have followed the checklist below, many common problems can be solved by:
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: