CFD Online Discussion Forums - Foam fatal io error: cannot find file

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Foam fatal io error: cannot find file (https://www.cfd-online.com/Forums/openfoam-solving/134568-foam-fatal-io-error-cannot-find-file.html)

Foam fatal io error: cannot find file

Hi, I'm new to using openFoam. I have completed all the tutorials without a problem, however now that I am leading towards my own simulation cases, I wanted to test out the snappyHexMesh. I found a tutorial on snappywiki for a simple cube. I downloaded the case file and created a new new directory for it. Both blockMesh and the snappyHexMesh ran without problem. All looked fine in paraView etc.

I then tried to run simpleFoam and got the following error:

--> FOAM FATAL IO ERROR:
cannot find file

file: /home/adam/OpenFOAM/adam-2.3.0/run/cube/system/system/controlDict at line 0.

From function regIOobject::readStream()
in file db/regIOobject/regIOobjectRead.C at line 73.

FOAM exiting

I'd appreciate any help.

Thanks, Adam

Greetings Adam and welcome to the forum!

If you run this command:

Code:

pwd

it will tell you in which folder your terminal/shell is currently working on. In your case, it should say this:

Code:

/home/adam/OpenFOAM/adam-2.3.0/run/cube/system/

If you step back to the previous folder, it should work as intended. For example, to step back, check where you are and to run the solver:

Code:

cd ..

pwd

simpleFoam

Best regards,
Bruno

Hi Bruno, thanks for your help however when I run pwd I get the following output:

/home/adam/OpenFOAM/adam-2.3.0/run/cube/system

so I'm not able to move back a folder.

Apologies if there is something really simple that I'm missing

Thanks,

Adam

Hi Adam,

Sorry, I made a bad copy-paste... I should have removed the second "system" from the path on the 2nd code block. I've edited my post and fixed it.

The idea is that the case folders look something like this:

cube <- this is the folder where you should be working from
- 0
- constant
- system <- this is the folder you're in right now

Which means that you have to change to the base case folder named "cube", in order to run the solver.

Best regards,
Bruno

I had tried that but I get a similar error:

--> FOAM FATAL IO ERROR:
cannot find file

file: /home/adam/OpenFOAM/adam-2.3.0/run/cube/1/p at line 0.

From function regIOobject::readStream()
in file db/regIOobject/regIOobjectRead.C at line 73.

FOAM exiting

Hi Adam,

I've got the feeling that you've run snappyHexMesh without the "-overwrite" option. This will create additional time/iteration folders that only have a mesh.
If this is the case, I suggest that you run the following steps:

Remove the outdated folders with this command:

Code:

rm -r 1 2 3
Run snappyHexMesh once again, with the "-overwrite" option, like this:

Code:

snappyHexMesh -overwrite
Now you can run the solver:

Code:

simpleFoam

My advice is that you also study a bit more about how to use the shell; for example, check this tutorial: http://linuxcommand.org/learning_the_shell.php

edit: And also have a look at the courses available here: http://openfoamwiki.net/index.php/Ha...enFOAM_courses

Best regards,
Bruno

Hi Bruno,

sorry that was my mistake, I'm using openFoam on a virtual window atm and I haven't shared the clipboard so I'm having to type out the error.

I did use snappyHexMesh -overwrite but the error should have been:

--> FOAM FATAL IO ERROR:
cannot find file

file: /home/adam/OpenFOAM/adam-2.3.0/run/cube/0/p at line 0.

From function regIOobject::readStream()
in file db/regIOobject/regIOobjectRead.C at line 73.

I will look into those courses, but I could do with getting this running so that I can progress with some of my own simulations that I will base around it.

thanks,

Adam

Hi Adam,

Then I need to know more about the case you're trying to run, because it doesn't look like one of the tutorials from OpenFOAM. Don't forget that I can't see what you're seeing... ;)

Best regards,
Bruno

Hi Bruno,

edit: I have fixed it now.

Thanks for your help

Adam

Dear Adam

How did you solve it. I am also having the same error. I am supercomputing for air flow in a pipe tee geometry. On coarse meshing it was working fine but on dense mesh, I have got this for many processors. I have taken message for only one processor. After reaching 0.10 seconds, I have got error file showing message below:

--> FOAM FATAL IO ERROR:
[77] cannot find file

file: /scratch/director674/shaqqi/tee/LES/75_original/processor77/0.101057/p at line 0.
[77]
[77] From function regIOobject::readStream()
[77] in file db/regIOobject/regIOobjectRead.C at line 73.
[77]
FOAM parallel run exiting

I have tried to delete earlier steps and rerun but to no avail. For the last 3 weeks this problem is stuck, I shall be grateful for your suggestion.

Best Regards

Greetings sihaqqi,

It's very much possible that the error you're getting is due to a different reason from what happened in Adam's case (which I never got to know any details about it :)).

Therefore, please describe the steps you've taken to reach that error message.

Best regards,
Bruno

Dear Bruno

Greetings on my behalf. Many thanks for your response.I have got this pipe tee geometry built and meshed in Ansys as my work relates to flow induced vibrations. CFD loads shall be imposed on pipe structure. Due to licensing issues for supercomputing as one node on machine requires one license, and due to the number of researchers using Ansys, it was not possible to have many licenses so I opted to run in OpenFoam.

I converted my mesh using fluent3DMeshtoFoam. I decomposed using decomposePar and ran it. The geometry is a vertical pipe is connected to another horizontal in the middle to form a tee. I am running LES using pisoFoam. I have adopted the same procedure as on another geometry which was two pipes connected to each other at 90 degree, having a mitre joint. There was no problem in that geometry, however in this geometry I have started running and after reaching 0.1 from 1e-7, it is giving me this error. I tried to remove earlier time steps, did ./Allrun in the beginning but it is just not working. My fluid is air at 75m/s so it is an incompressible solver. Mach is 0.22.

Please advise what other information you would like to have?

Best Regards
Imad

If I understood you correctly, the solver was running without problems in parallel, running continuously since 1e-7 seconds up until it crashed.

Quote:

Originally Posted by sihaqqi (Post 493932)

Please advise what other information you would like to have?

To confirm, you were not trying to continue the simulation again from 0.1, or were you?
Which OpenFOAM version are you using?
The solver output text from before the error messages you got (before the ones for all processors). That should give an idea of what was the last time iteration that was running, with which deltaT and if there were any residuals or Courant Number that seemed to be near to blowing up.
How frequently were the time snapshots saved? Were they saved on all time iterations?
How much space is the case occupying at "/scratch/director674/"? Because you might have run out of disk space or space quota. There are some clusters that restrict both the total number of files and the total space occupied by each user.

Hello Bruno
Thanks for your response. My answers are

1. I have tried to restart simulations two ways: one by removing some of the last time steps but it again crashed.
2. OpenFoam 2.1.1
4. Time steps are written after every 2000 steps
5. My space is 32GB remaining so it should be alright.

3. Error file is too big to attach, however a some part I am giving below for you to have a look, this comment that it cannot find the file is throughout. I cannot understand the meaning of this error. It has written all previous time steps successfully.

Code:

[1026] 

[1026] 

[1026] --> FOAM FATAL IO ERROR: 

[1026] cannot find file

[1026] 

[1026] file: /scratch/director674/shaqqi/tee/LES/75_original/processor1026/0.101057/p at line 0.

[1026] 

[1026]     From function regIOobject::readStream()

[1026]     in file db/regIOobject/regIOobjectRead.C at line 73.

[1026] 

FOAM parallel run exiting

[1026] 

[520] 

[520] 

[520] --> FOAM FATAL IO ERROR: 

[520] cannot find file

[520] 

[520] file: /scratch/director674/shaqqi/tee/LES/75_original/processor520/0.101057/p at line 0.

[520] 

[520]     From function regIOobject::readStream()

[520]     in file db/regIOobject/regIOobjectRead.C at line 73.

[520] 

FOAM parallel run exiting

[520] 

[835] 

[835] 

[835] --> FOAM FATAL IO ERROR: 

[835] cannot find file

[835] 

[835] file: /scratch/director674/shaqqi/tee/LES/75_original/processor835/0.101057/p at line 0.

[835] 

[835]     From function regIOobject::readStream()

[835]     in file db/regIOobject/regIOobjectRead.C at line 73.

[835] 

FOAM parallel run exiting

[835] 

[923] 

[923] 

[923] --> FOAM FATAL IO ERROR: 

[923] cannot find file

[923] 

[923] file: /scratch/director674/shaqqi/tee/LES/75_original/processor923/0.101057/p at line 0.

[923] 

[923]     From function regIOobject::readStream()

[923]     in file db/regIOobject/regIOobjectRead.C at line 73.

[923] 

FOAM parallel run exiting

[923] 

*** glibc detected *** pisoFoam: double free or corruption (fasttop): 0x0000000000a32220 ***

======= Backtrace: =========

/lib64/libc.so.6[0x3baee76126]

/usr/lib64/libstdc++.so.6(_ZNSsD1Ev+0x39)[0x3bb0e9d4c9]

pisoFoam(_ZN4Foam4wordD1Ev+0x6)[0x42e276]

/lib64/libc.so.6(__cxa_finalize+0x9d)[0x3baee3617d]

/ivec/apps/intel/12.1.7/openfoam/2.1.1/OpenFOAM-2.1.1/platforms/linux64IccDPOpt/lib/libfiniteVolume.so(+0x381566)[0x2ac7d0650566]

======= Memory map: ========

00400000-00546000 r-xp 00000000 bb5:81f2a 35924                          /ivec/apps/intel/12.1.7/openfoam/2.1.1/OpenFOAM-2.1.1/platforms/linux64IccDPOpt/bin/pisoFoam

00746000-0074c000 rw-p 00146000 bb5:81f2a 35924                          /ivec/apps/intel/12.1.7/openfoam/2.1.1/OpenFOAM-2.1.1/platforms/linux64IccDPOpt/bin/pisoFoam

009f6000-02b04000 rw-p 00000000 00:00 0                                  [heap]

3bae600000-3bae620000 r-xp 00000000 fd:00 38822                          /lib64/ld-2.12.so

3bae81f000-3bae820000 r--p 0001f000 fd:00 38822                          /lib64/ld-2.12.so

3bae820000-3bae821000 rw-p 00020000 fd:00 38822                          /lib64/ld-2.12.so

3bae821000-3bae822000 rw-p 00000000 00:00 0 

3baea00000-3baea83000 r-xp 00000000 fd:00 39046                          /lib64/libm-2.12.so

3baea83000-3baec82000 ---p 00083000 fd:00 39046                          /lib64/libm-2.12.so

3baec82000-3baec83000 r--p 00082000 fd:00 39046                          /lib64/libm-2.12.so

3baec83000-3baec84000 rw-p 00083000 fd:00 39046                          /lib64/libm-2.12.so

3baee00000-3baef8a000 r-xp 00000000 fd:00 38823                          /lib64/libc-2.12.so

3baef8a000-3baf189000 ---p 0018a000 fd:00 38823                          /lib64/libc-2.12.so

3baf189000-3baf18d000 r--p 00189000 fd:00 38823                          /lib64/libc-2.12.so

3baf18d000-3baf18e000 rw-p 0018d000 fd:00 38823                          /lib64/libc-2.12.so

3baf18e000-3baf193000 rw-p 00000000 00:00 0 

3baf200000-3baf202000 r-xp 00000000 fd:00 39052                          /lib64/libdl-2.12.so

3baf202000-3baf402000 ---p 00002000 fd:00 39052                          /lib64/libdl-2.12.so

3baf402000-3baf403000 r--p 00002000 fd:00 39052                          /lib64/libdl-2.12.so

3baf403000-3baf404000 rw-p 00003000 fd:00 39052                          /lib64/libdl-2.12.so

3baf600000-3baf617000 r-xp 00000000 fd:00 16570                          /lib64/libpthread-2.12.so

3baf617000-3baf817000 ---p 00017000 fd:00 16570                          /lib64/libpthread-2.12.so

3baf817000-3baf818000 r--p 00017000 fd:00 16570                          /lib64/libpthread-2.12.so

3baf818000-3baf819000 rw-p 00018000 fd:00 16570                          /lib64/libpthread-2.12.so

3baf819000-3baf81d000 rw-p 00000000 00:00 0 

3bafa00000-3bafa07000 r-xp 00000000 fd:00 4149                           /lib64/librt-2.12.so

3bafa07000-3bafc06000 ---p 00007000 fd:00 4149                           /lib64/librt-2.12.so

3bafc06000-3bafc07000 r--p 00006000 fd:00 4149                           /lib64/librt-2.12.so

3bafc07000-3bafc08000 rw-p 00007000 fd:00 4149                           /lib64/librt-2.12.so

3bafe00000-3bafe15000 r-xp 00000000 fd:00 3786                           /lib64/libz.so.1.2.3

3bafe15000-3bb0014000 ---p 00015000 fd:00 3786                           /lib64/libz.so.1.2.3

3bb0014000-3bb0015000 r--p 00014000 fd:00 3786                           /lib64/libz.so.1.2.3

3bb0015000-3bb0016000 rw-p 00015000 fd:00 3786                           /lib64/libz.so.1.2.3

3bb0200000-3bb0216000 r-xp 00000000 fd:00 7062                           /lib64/libgcc_s-4.4.7-20120601.so.1

3bb0216000-3bb0415000 ---p 00016000 fd:00 7062                           /lib64/libgcc_s-4.4.7-20120601.so[1128] 

[1128] 

[1128] --> FOAM FATAL IO ERROR: 

[1128] cannot find file

[1128] 

[1128] file: /scratch/director674/shaqqi/tee/LES/75_original/processor1128/0.101057/p at line 0.

[1128] 

[1128]     From function regIOobject::readStream()

[1128]     in file db/regIOobject/regIOobjectRead.C at line 73.

[1128] 

FOAM parallel run exiting

[1128] 

[1130] 

[1130] 

[1130] --> FOAM FATAL IO ERROR: 

[1130] cannot find file

[1130] 

[1130] file: /scratch/director674/shaqqi/tee/LES/75_original/processor1130/0.101057/p at line 0.

There is no courant blowing up or any other thing.

Thanks for your time again.
Regards
Imad

Hi Imad,

I wanted to see what is the output before the first occurrence of:

Code:

FOAM FATAL IO ERROR:

Having 32GB of free disk space doesn't necessarily mean that you're allowed to write in it. As I tried to explain in the other post, the administrators of some clusters and supercomputers will restrain the quota per user to a limited disk space and/or to a maximum number of files. Usually, to know what is the user's quota, simply run the command:

Code:

quota

Anyway, if I now understood you correctly, you are always restarting the simulation and this is why it crashes.

If I'm not mistaken, the problem is due to a bug that is present in OpenFOAM 2.1.1. If it would be possible to upgrade to at least 2.1.x, this problem should no longer occur. I say this because you're not the first one to trigger a similar issue. Sometime ago there was someone else with the same or at least a similar problem... I'm not sure how he managed to solve the problem... and I can't find the thread I'm thinking of :(.

My final question is this: if you start the case from 0.0s and let it run without stopping, does it still crash at 0.101057s with the same error?

Best regards,
Bruno

Hi Bruno
Before FOAM FATAL IO ERROR: there is nothing however I have copied somethings for you from the log file as shown below this para. After this there is nothing. I shall check with system administrator about what you told me about memory. Also I shall ask him to upgrade however it is beyond my control if they would cooperate because our cluster is not university owned. It is ivec in Western Australia which provides supercomputing facilities to 5 technical universities in Western Australia as it is a joint venture. Still I will pursue. If I delete all my files and these again crash it would take at least 10 days because I am using 100 nodes = 1200 CPUs because of LES. Geometry is very big. Horizontal pipe is 10m and vertical pipe is 3m and I have to capture yPlus value of 1.

Code:

calculating averages



Time = 0.1011976



Courant Number mean: 0.00696108 max: 0.0959961

DILUPBiCG:  Solving for Ux, Initial residual = 4.04902e-05, Final residual = 7.76828e-09, No Iterations 1

DILUPBiCG:  Solving for Uy, Initial residual = 4.82382e-05, Final residual = 8.73335e-09, No Iterations 1

DILUPBiCG:  Solving for Uz, Initial residual = 0.000744114, Final residual = 1.42948e-07, No Iterations 1

DICPCG:  Solving for p, Initial residual = 0.00151149, Final residual = 5.14381e-05, No Iterations 3

time step continuity errors : sum local = 9.95077e-11, global = 2.18734e-14, cumulative = -2.67098e-11



/*---------------------------------------------------------------------------*\

| =========                 |                                                 |

| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |

|  \\    /   O peration     | Version:  2.1.1                                 |

|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |

|    \\/     M anipulation  |                                                 |

\*---------------------------------------------------------------------------*/

Build  : 2.1.1-221db2718bbb

Exec   : pisoFoam -parallel

Date   : May 22 2014

Time   : 02:23:46

Host   : "e138"

PID    : 18850

Case   : /scratch/director674/shaqqi/tee/LES/75_original

nProcs : 1200

Slaves : 

1199

(

"e145.24054"



"e615.6866"

"e624.10033"

"e684.24723"

"e729.12497"

"e735.10917"

"e738.27549"

)



Pstream initialized with:

    floatTransfer     : 0

    nProcsSimpleSum   : 0

    commsType         : nonBlocking

sigFpe : Floating point exception trapping - not supported on this platform

fileModificationChecking : Monitoring run-time modified files using timeStampMaster

allowSystemOperations : Disallowing user-supplied system call operations



// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

Create time



Create mesh for time = 0.101057



Reading field p

Regards
Imad

Hi Imad,

I've made a test just now, using the tutorial case "incompressible/pisoFoam/les/pitzDaily" and using OpenFOAM 2.1.1. It doesn't seem to be a problem with OpenFOAM 2.1.1, because it was possible to continue the simulation in parallel more than once.

I hope you haven't erased the files. Check the contents of one of the folders where the solver complained about the missing "p" file. For example, by running:

Code:

ls -l processor1026/0.101057

What files are present in that folder?

Check the previous processor and time folders to check if they have the field files "U" and "p" and so on.

Another question is: are you using any function objects in "system/controlDict"? And if so, how are they configured to run?

Best regards,
Bruno

Dear Bruno

No such time step as 0.101057 exists anywhere. Last time step I have in all processors is 0.1010569. It has 1 folder "uniform" which has "field averaging properties" and "time" files. Aside from this folder, there are 14 more files which are

Code:

yPlus

yUPrime2Mean

UMeanpPrime2Mean

pMeanU_0

U

phi_0

phi

p

k_0

k

nuSgs

Controldict contents are

Code:

application     pisoFoam;



startFrom       latestTime; 



stopAt          endTime;

//stopAt          nextWrite;



endTime         5e-1;



deltaT          1e-7;



writeControl    timeStep;

//writeControl    clockTime;



writeInterval   2000;



purgeWrite      10;



writeFormat     ascii;



writePrecision  6;



writeCompression off;



timeFormat      general;



timePrecision   6;



runTimeModifiable true;



functions

{

    probes

    {

        type            probes;

        functionObjectLibs ("libsampling.so");

        enabled         true;

        outputControl   timeStep;

        outputInterval  1;



        fields

        (

            p

        );



        probeLocations

        (

         (0.036 2.000 0)

         (0.036 2.400 0)

            (0.036 2.600 0)

            (0.036 2.700 0)

            (0.036 2.798 0)

         (0.100 2.798 0)

         (0.300 2.798 0)

         (0.500 2.798 0)

         (1.000 2.798 0)

            (1.500 2.798 0)

         (2.000 2.798 0)

         (2.500 2.798 0)  

         (3.000 2.798 0) 

         (3.500 2.798 0) 

         (4.000 2.798 0) 

         (4.500 2.798 0)

         (-0.100 2.798 0)

         (-0.300 2.798 0)

         (-0.500 2.798 0)

         (-1.000 2.798 0)

            (-1.500 2.798 0)

         (-2.000 2.798 0)

         (-2.500 2.798 0)  

         (-3.000 2.798 0) 

         (-3.500 2.798 0) 

         (-4.000 2.798 0) 

         (-4.500 2.798 0)      

        );



    }



    fieldAverage1

    {

        type            fieldAverage;

        functionObjectLibs ("libfieldFunctionObjects.so");

        enabled         true;

        outputControl   outputTime;



        fields

        (

            U

            {

                mean        on;

                prime2Mean  on;

                base        time;

            }



            p

            {

                mean        on;

                prime2Mean  on;

                base        time;

            }

        );

    }



    surfaceSampling

    {

        // Sample near-wall velocity



        type surfaces;



        // Where to load it from (if not already in solver)

        functionObjectLibs ("libsampling.so");

        enabled         true;

        outputControl   outputTime;



        interpolationScheme cellPoint;



        surfaceFormat vtk;



        // Fields to be sampled

        fields

        (

            U

        );



        surfaces

        (

            nearWall

            {

                type            patchInternalField;

                patches         ( lowerWall );

                distance        1E-6;

                interpolate     true;

                triangulate     false;

            }

        );

    }

}

Regards
Imad

Quote:

Originally Posted by wyldckat (Post 493917)

Bruno, it was an embarrassing typo on my part in the initial conditions.

Adam

Hi Adam and Imad,

@Adam: Thanks for the feedback :)

@Imad: Sorry, I wasn't able to answer sooner. I have a feeling I have seen this problem before, but I'm not able to figure out what the exact problem is. But I've managed to deduce that it shouldn't be a problem with disk space quota, because you have this option:

Code:

purgeWrite 10;

which means that it only saves the last 10 iterations. This would mean that if you were meant to have disk space quota issues, it should have occurred a lot sooner.

I think that if I could see a good list of the files present in the "processor0" folder, along with the full output of the last attempt of running the case from the latest time snapshot, I might be able to better deduce what the problem is.
You can get a good list of the contents of the folder "processor0" if you run this command from within the main case folder:

Code:

find processor0 > list_of_files_in_processor0.txt

Then compress the file "list_of_files_in_processor0.txt", along with the log file and attach it in your next post.

Best regards,
Bruno