CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Question on DecomposePar (https://www.cfd-online.com/Forums/openfoam-solving/113417-question-decomposepar.html)

nore5 February 19, 2013 10:18

Question on DecomposePar
 
Hi,

I am trying to run calculations on parallel 8simple method) but each time I use decomposedPar I get that kind of error after it assigns cells, patches and .. to each processor. I can't figure out where it comes from.


--> FOAM FATAL IO ERROR:
size 2520 is not equal to the given value of 5538

file: /home/noba/OpenFOAM/noba-2.1.1/run/cube2/0/U::boundaryField::inlet from line 36 to line 5097.

From function Field<Type>::Field(const word& keyword, const dictionary&, const label)
in file /home/noba/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/Field.C at line 236.

FOAM exiting

Thank you in advance for your help.

Nore

RocketMan1691 February 19, 2013 14:40

DecomposePar question
 
I have not had the problem with decomposePar but something similar happens when you mess with the run sequence for blockMesh and snappyH. Running the programmes in the wrong sequence can leave old files in the directories. The old files have the wrong cell count which is flagged by the next programme.

Not sure if that is what is happing here, but maybe it is something similar.

nore5 February 19, 2013 15:33

Thanks for the reply. So you advice me to remove all the files and keep the ones needed for running the simulation?

I will tru and let you know....

Thanks again

RocketMan1691 February 19, 2013 15:58

The give away is creation time. Old files will have a time that is out of sequence with the others in the directory.

nore5 February 19, 2013 16:20

It worked for me. Thanks. Still i did not understand your last message please abut creation time, Could you explain please?

RocketMan1691 February 19, 2013 16:45

When I have had the problem, it happened because I had to rerun a programme I had already run. Each programme writes its output at more or less the same time. So the creation times are similar. In some parts of the processing chain, later files overwrite earlier ones. If run in the right order, all the relevant files are over written, again at more or less the same time. When the earlier programme is rerun, some of the files have been overwritten with the wrong data and the inevitably wrong cell count. The re-run programme complains.

To de-bug it, just look for an creation time that does not match its neighbours. It may be earlier or later but it will standout.

Hope that makes sense.


All times are GMT -4. The time now is 08:27.