[austin.m]

Is there a way to interrupt a solver run in progress so that a solution file still gets written?

[economon]

Hi Austin,

At the moment, we have not embedded the required system calls for interrupting the process and cleanly exiting (i.e. writing a solution file, etc.). Note, however, that the frequency with which a restart file is written can be adjusted using the WRT_SOL_FREQ option. Lastly, once a restart file has been written, new solution files can be generated from it by calling the SU2_SOL executable.

Thanks for your question and for trying out SU2! Cheers,
Tom

[austin.m]

Hi Tom-

Thanks for your reply. I knew you could modify the restart frequency but I didn't know you could generate solution files from the restart files!

I've been trying to run RANS runs on a fairly large mesh (8M elements) and I'm finding that the Geometry Preprocessing (particularly "Setting the multigrid structure") takes many minutes. It would be very helpful to be able to modify a run in progress (eg CFL number) or be able to save the geometry preprocessing data so stopping and restarting a run doesn't take so long. Maybe this isn't an issue for a cluster, but unfortunately I only have access to an 8 core machine.

Thanks!
Austin

[economon]

Austin,

Indeed, the geometry preprocessing for the multigrid can be quite costly, as it is performing an agglomeration procedure to group control volumes for forming the coarser mesh levels. As there are a large number of elements per core for your runs (~8M cells on 8 cores), each processor is doing a lot of work to agglomerate its portion.

You may want to try tuning the MG parameters a bit to see if you can maximize performance (to make up for the wait time), or possibly change the number of levels that you are using. Have you compared the performance without MG for your RANS case? You may try turning MG off and increasing the CFL number to see how total wall time compares.

Hope this helps,
Tom

[austin.m]

Hi Tom-

With 3 levels of MG (V-cycle), convergence was taking 700+ iterations at 1.8 minutes per iteration, or 21+ hours of run time. Most comparisons I've seen of MG vs no-MG show the significant convergence improvements with MG; I'm skeptical that turning off MG will result in an overall improvement in run time, but I'm willing to give it a shot.

Your comment about increasing the CFL number brings me back to why I posted this question in the beginning- I try to push the CFL number up as high as I can until the solution diverges, but doing this on a trial-and-error basis when the run startup takes so long is frustrating! It would be nice to be able to stop a run (or change the CFL number dynamically) before it diverges.

Nonetheless, let me say I'm very appreciative of all of the work you guys have put into this code and for taking the time to answer questions here!

Austin