[boffin5]

After trying to make setup changes for 2 cores, and running the motorBike, I get these results:
- snappyhexmesh works fine.
- if I try to run potentialFoam, I get a 'no MRF file' error
- when not running potentialFoam, but just running simpleFoam, it runs much too quickly, but finishes.
- then, in paraview, it only goes up to time step 3, and there is no p or U data.


Basically, the question is: which setup files need to be adjusted to account for just 2 cores? I thought I knew, but obviously not.

[erickmartinez]

Can you share your "Allrun" script you are using and the decomposeParDict and controlDict file scripts?

[boffin5]

Thanks Erick,
Here is my command sequence:
-cp motorBike.obj.gz into trisurface
-surfaceFeatures
-blockMesh
-decomposePar
-snappyHexMesh (should this be in parallel?)
-mpirun -np 2 potentialFoam -noFunctionObjects -parallel (gives 'no MRF files' message)
-mpirun -np 2 simpleFoam -parallel (quit here because it ran too fast)

controlDict file:
application simpleFoam;
startFrom latestTime;
startTime 0;
stopAt endTime;
endTime 500;
deltaT 1;
writeControl timeStep;
writeInterval 100;
purgeWrite 0;
writeFormat binary;
writePrecision 6;
writeCompression off;
timeFormat general;
timePrecision 6;
runTimeModifiable true;
functions
{ #include "streamLines"
#include "cuttingPlane"
#include "forceCoeffs" }


decomposeParDict file:
numberOfSubdomains 2;
method simple;
simpleCoeffs {
n (2 1 1);
delta 0.001; }


Thanks, I am open to (actually desparate for) suggestions!

[erickmartinez]

Does the case run normally if ran with a single processor? If you would like to share a link to your files I can check it out. It just seems like a small mistake somewhere. If it works well with a single processor then there is an issue with the decomposition and running in parallel.

[Yann]

Originally Posted by boffin5

Thanks Erick,
Here is my command sequence:
-cp motorBike.obj.gz into trisurface
-surfaceFeatures
-blockMesh
-decomposePar
-snappyHexMesh (should this be in parallel?)
-mpirun -np 2 potentialFoam -noFunctionObjects -parallel (gives 'no MRF files' message)
-mpirun -np 2 simpleFoam -parallel (quit here because it ran too fast)

Yes, snappyHexMesh sould be run in parallel OR you should decompose your domain after running snappyHexMesh.

With this workflow you are basically running simpleFoam on your blockMesh mesh, which is probably why it is quite fast!


Cheers,
Yann

[boffin5]

Erick, I sent you a private message with a dropbox link. Thanks for the help!
boffin5

[Yann]

Hello Boffin5,

I suggest you to post here rather than sending private messages in order to share your findings with the community.

You have to use the "-overwrite" option with snappyHexMesh if you want to overwrite the original mesh (from blockMesh) with the new mesh generated by snappyHexMesh.

If you don't use the -overwrite option, snappyHexMesh will write the meshes in new time directories. It write 3 meshes corresponding to the 3 major steps of the mesh generation: castellated, snap and addLayers. You will have to manually copy the final mesh in (processor*/)constant/ in order to replace the original mesh and to run your solver on your final mesh.

Cheers,
Yann

[boffin5]

Yann informed me that I had made 2 errors: I need to run snappyHexMesh in parallel, and and I also need to add the -overwrite flag. Now the motorBike case runs awesome! Thanks for the help, Yann. Also thanks to Erick Martinez for volunteering to help.



I had resorted to private messages, because when I tried to put screen captures of my files in the post, I kept exceeding the post size limit.
But I see lots of posts with really big file images, so there must be a way to do it.


Any ideas on that would be appreciated as well.

[boffin5]

Well, maybe I spoke too soon.


Yesterday I was chuffed that I was finally able to run the motorBike case;
today I tried to run it again, snappyHexMesh went fine, but when I entered the command
mpirun -np 2 potentialFoam -noFunctionObjects -parallel
it came back with the failure message:


cannot find patchField entry for motorBike_frt-fairing


This is after I coped the motorBike.obj.gz file from the tutorials/resources/geometry folder.


Could it be that the tutorial file has become corrupted?

[Yann]

Originally Posted by boffin5

cannot find patchField entry for motorBike_frt-fairing

This means there is a boundary condition missing for the patch motorBike_frt-fairing in one of the file (if not all) in processor*/0/


This should not be related to the copy of motorBike.obj.gz file from the tutorials/resources/geometry folder but to something else in the workflow. Did you clean up the case before running it again?


Cheers
Yann

[boffin5]

Yes, I cleaned it. Here are the U files that resulted from snappyhexmesh-parallel, including the error file that comes after running potentialFoam.
btw, my command list:
surfaceFeatures
blockMesh
decomposePar
mpirun -np 2 snappyHexMesh -np 2 -overwrite -parallel
mpirun -np 2 potentialFoam -np2 noFunctionObjects -parallel


The error message refers to all the boundary condition lines in the U files, but I don't know how to interpret.



This is confounding, since today's procedure was identical to the one that was successful yesterday.


Yann, thanks for your help to date, and I hope can help again with this one!

[DominikMuetter]

The error message refers to all the boundary condition lines in the U files, but I don't know how to interpret.

This means that the boundary conditions for motorBike_frt-fairing are missing in the velocity dictionary, specification is done like with all the others (inlet, outlet, lowerWall etc.).

Example (NOT! the correct code):
boundaryField
{
...
motorBike_frt-fairing
{
type movingWallVelocity;
value $internalField;
}
...
}


I hope this is a helpful answer

[Yann]

The boundary conditions related to the motorbike geometry are missing in your U file, this is what the solver complains about: there is not boundary condition defined for "motorBike_frt-fairing" hence the solver cannot run. You will have the same problem with every patch related to the motorbike geometry since they are all missing in your U file (as well as for the other variable files)

Have a look at the processor*/constant/polyMesh/boundary file. You will find there all the boundaries in your domain and of course, all boundaries need a boundary condition.

By default, if a 0 directory exists, decomposePar will decompose the fields according to the current mesh. When you run blockMesh then decomposePar, it will decompose only the boundary conditions related to the initial blockMesh and nothing related to the motorbike geometry since it does not exist yet in the mesh. This is why you get this error.

Check the original Allrun file in the motorbike tutorial to find how to solve this error. Depending on the OpenFOAM version you are using, it can be either "decomposePar -copyZero" (OpenFOAM 8) or "restore0Dir" (OpenFOAM v2012)

Cheers
Yann

[boffin5]

Yes Yann,
I checked the Allrun file, and saw that decomposePar has -copyZero after it.
When I tried it this way, the darn thing ran okay!
Note to self: always heed the Allrun file!
I am cautiously optimistic, since I have seen that results can be unpredictable, and am looking forward to escaping the newbie phase, to grapple with more challenging foulups!

[Ship Designer]

Hi Alan,

I suggest to run decomposePar always with the -force option. This will ensure that you don't need to delete the processorN files manually but even more importantly, that nothing is left over from previous runs which might cause errors or unexpected results. When you run decomposePar -force, it will first delete all the processorN folders you might have in your case and then it will proceed to decompose first the polyMesh and then the field files, including the 0 folder. In my experience it is not necessary to specify -copyZero explicitly for that but it surely doesn't hurt either, except if your controlDict has a startTime other than 0. In that case the 0 folder is not copied so you might want to keep an eye on that.

[boffin5]

Thanks Claudio, fantastic suggestion! I hope you realize that in all likelihood, I will come back and bug you with more questions