CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   CONVERGE (https://www.cfd-online.com/Forums/converge/)
-   -   Parallel Block Size Issue (https://www.cfd-online.com/Forums/converge/174756-parallel-block-size-issue.html)

ChiefSeaBiscuit July 18, 2016 11:55

Parallel Block Size Issue
 
Hello, I'm trying to run a basic simulation within Converge. The simulation consists of a 3D cuboid with one face being the inflow, one the outflow and then the rest of the faces being walls. The problem is when I'm trying to check inputs within command prompt this shows up (when using the serial solver)

reading inputs.in data from file inputs.in
reading amr.in data from file amr.in
turb_flag = 1 in inputs.in, reading in turbulence.in
reading turbulence.in data from file turbulence.in
reading species.in data from file species.in
trying to read in therm.dat... reading
reading initialize.in data from file initialize.in
reading gas.dat data from file gas.dat
reading boundary.in data from file boundary.in
reading post.in data from file post.in
reading surface.dat data from file surface.dat
The parallel block size (dx, dy, dz) is 8.000000e-002 8.000000e-002 3.200000e-001.

and this when just running serial without check_inputs

reading inputs.in data from file inputs.in
reading amr.in data from file amr.in
turb_flag = 1 in inputs.in, reading in turbulence.in
reading turbulence.in data from file turbulence.in
reading species.in data from file species.in
trying to read in therm.dat... reading
reading initialize.in data from file initialize.in
reading gas.dat data from file gas.dat
reading boundary.in data from file boundary.in
reading post.in data from file post.in
reading surface.dat data from file surface.dat
The parallel block size (dx, dy, dz) is 1.000000e-001 1.000000e-001 4.000000e-001.

The dimensions of the cuboid are (0.1,0.1,0.5) and the base grid is (0.05,0.05,0.2). I've tried different variations of the base grid and nothing has worked? Is there something obvious I am missing?

Many thanks,
Adrian

MFGT July 19, 2016 06:43

Block size in the normal run looks fine, remember the min. block size is twice the base grid size.

However, i also exeprienced different cell and block sizes when i convert the first output of the check_inputs run.

ChiefSeaBiscuit July 19, 2016 06:54

I understand that the block size is double the size of the base grid, it's just when running a 2D simulation this doesn't come up and runs perfectly fine. However, whilst running a 3D simulation the parallel block size comes up on the last line and then the command prompt crashes so the simulation doesn't actually run? Do I have to have fixed embedding/grid scaling on as well but shouldn't it just run solely on base grid?

alemoine July 21, 2016 18:11

Quote:

Originally Posted by ChiefSeaBiscuit (Post 610223)
I understand that the block size is double the size of the base grid, it's just when running a 2D simulation this doesn't come up and runs perfectly fine. However, whilst running a 3D simulation the parallel block size comes up on the last line and then the command prompt crashes so the simulation doesn't actually run? Do I have to have fixed embedding/grid scaling on as well but shouldn't it just run solely on base grid?

Hello,

check_inputs is meant to be a quick and inexpensive way of validating all of the inputs without having to launch the full simulation. In order for this to be computationally inexpensive, check_inputs does not generate the mesh (which is required when calculating the parallel block sizes). Therefore, the parallel block size listed when using check_inputs is not the true parallel block size.

Thank you,

ChiefSeaBiscuit July 22, 2016 13:20

Ah I see now, that's quite handy. Is there anything that would cause an issue with trying to run the simulation then as it just crashes? Going from what you said I guess that it's crashing during the mesh generation phase by what comes on the output. The mesh it's generating though is a basic cuboid shape so I don't see how there can be a problem with the mesh generation?

Many thanks,
Adrian Parisi

alemoine July 22, 2016 14:03

Hi Adrian,

There are many possible causes for a crash: poorly defined boundary/initial conditions, issues with the surface geometry, incorrect model settings, etc. When investigating the reason for a crash, it is best to start with the logfile/screen output. Our recommendation is to always run a CONVERGE simulation with screen_print_level=2 as this provides the most detailed output. The output here will give you a good idea of where CONVERGE is at in the simulation (i.e. setting up the grid, solving transport equations, etc). Therefore, more information is required to determine the root cause of your particular crash.

Thank you,


All times are GMT -4. The time now is 11:36.