Fix output names of unsteady simulation

[rois1995]

Proposed Changes

It solves two main issues in unsteady simulations:
1- if the history file is not updated during the simulation (ex. setting inner_iter = 0) the time iteration is not updated in the file output names.
2- mesh file output does not have the time iteration at the end.

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 --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• 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.

[rois1995]

I would also try to add the writing of the mesh in the CGNS format, although this can be done in another PR.

[bigfooted]

LGTM

[bigfooted]

So if the filename is empty, the time iteration is added, but if the filename is not empty, the iterations were always already added before to fileName, is that it?

[rois1995]

Essentially I have followed all the other cases. Without appending the time iter at the end of the file name it just overwrites the same file at each unsteady iteration.

[pcarruscag]

If curTimeIter is a member variable, why are you having to set its value here?
It was already used in line 418/421.
So do we have the same problem with innerIter and outerIter? Can you fix this closer to the current place where these iteration counters are set? (history file judging from the comment)

[rois1995]

The problem only arises when I set the inner iterations to be 0 in an unsteady dual time-stepping simulation. I guess that, since in this case the history file is not updated, the curTimeIter is not updated and remains 0 when writing the output files. In all other cases where the history file is written it is not necessary. I guess I could use an if-statement for that but I don't think that it is necessary. I don't know if the problem persist with the outer iter, I will check (I guess it only matters during a steady simulation when (WRT_*_OVERWRITE is set to YES in the config file). However, in that case if the iterations are set to 0 then the simulation terminates right away, thus there should be no problem.

[pcarruscag]

Yes but please look for a single place where to put setting these variables, potentially moving where they are set at the moment.

[rois1995]

Sure, I missed that request before. I have created a setCurTimeIter function in the COutput class and I call it when the Solve function is called. I have checked also for multi-zone problems and it works fine. I can remove the TimeIter variable from all the other functions of the COutput class where the curTimeIter was set equal to it to clean up the code if needed.