Question on DecomposePar

nore5 · February 19, 2013, 10:18

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

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.

February 19, 2013, 10:18	Question on DecomposePar	#1
nore5 New Member Join Date: Jan 2013 Posts: 20 Rep Power: 13	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

February 19, 2013, 14:40	DecomposePar question	#2
RocketMan1691 New Member Nick Dale Join Date: Feb 2013 Posts: 9 Rep Power: 13	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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Question about blockMesh and decomposePar	ywang	OpenFOAM	2	June 18, 2011 13:28
Question about decomposePar	RDanks	OpenFOAM Pre-Processing	2	May 20, 2011 09:24
internal field question - PitzDaily Case	atareen64	OpenFOAM Running, Solving & CFD	2	January 26, 2011 15:26
transientSimpleDyMFoam, mapFields and decomposePar	pad	OpenFOAM Running, Solving & CFD	0	December 3, 2010 05:22
Poisson Solver question	Suresh	Main CFD Forum	3	August 12, 2005 04:37

February 19, 2013, 15:33		#3
nore5 New Member Join Date: Jan 2013 Posts: 20 Rep Power: 13	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

February 19, 2013, 15:58		#4
RocketMan1691 New Member Nick Dale Join Date: Feb 2013 Posts: 9 Rep Power: 13	The give away is creation time. Old files will have a time that is out of sequence with the others in the directory.

February 19, 2013, 16:20		#5
nore5 New Member Join Date: Jan 2013 Posts: 20 Rep Power: 13	It worked for me. Thanks. Still i did not understand your last message please abut creation time, Could you explain please?

February 19, 2013, 16:45		#6
RocketMan1691 New Member Nick Dale Join Date: Feb 2013 Posts: 9 Rep Power: 13	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.