[Bob Tipton]

Running a case on a linux cloud server and WSL on Win 10.
Running both with and without mpi.


simpleFoam takes one step, writes out all expected outputs, all values look good and no warnings.


It stops.


If I run it again, it takes another step and the values still look good. That repeats for the 5 steps I tested.


The system and 0 dict were copied from a prior case which ran to completion at 1500 steps.


I replaced the dicts to to sure - the problem persists.

In the prior case I replaced the controlDict with one from an other case and the problem went away.


It appears to be related to a system state not a case state. All cases are now affected. In the last case they all cleared up at the same time and the problem didn't repeat for weeks.

I'm using V-1912.



******************* controlDict *****************
FoamFile
{
version 2.0;
class dictionary;
format ascii;
location "system";
object snappyHexMeshDict;
}
castellatedMesh true;
snap true;
addLayers true;
geometry
{
Main.stl
{
type triSurfaceMesh;
name Main;
includedAngle 120.0;
}
Mid.stl
{
type triSurfaceMesh;
name Mid;
includedAngle 120.0;
}
RefineCone1.stl
{
type triSurfaceMesh;
name RefineCone1;
includedAngle 120.0;
}
RefineCone2.stl
{
type triSurfaceMesh;
name RefineCone2;
includedAngle 120.0;
}
RefineCone3.stl
{
type triSurfaceMesh;
name RefineCone3;
includedAngle 120.0;
}
RefineEdge.stl
{
type triSurfaceMesh;
name RefineEdge;
includedAngle 120.0;
}
RefineLip.stl
{
type triSurfaceMesh;
name RefineLip;
includedAngle 120.0;
}
}
castellatedMeshControls
{
locationInMesh (0.251325 3.013165 3.131);
refinementSurfaces
{
Main
{
level ( 5 5 );
patchInfo
{
type wall;
}
}
Mid
{
level ( 5 5 );
patchInfo
{
type wall;
}
}
}
refinementRegions
{
RefineCone1
{
mode inside;
levels ((1.0E30 2));
}
RefineCone2
{
mode inside;
levels ((1.0E30 2));
}
RefineCone3
{
mode inside;
levels ((1.0E30 2));
}
RefineEdge
{
mode inside;
levels ((1.0E30 7));
}
RefineLip
{
mode inside;
levels ((1.0E30 7));
}
}
limitRegions
{
}
features
(
);
maxLocalCells 500000;
maxGlobalCells 40000000;
nCellsBetweenLevels 6;
maxLoadUnbalance 0.1;
minRefinementCells 2;
resolveFeatureAngle 15.0;
allowFreeStandingZoneFaces false;
}
snapControls
{
tolerance 1.0;
nSmoothPatch 3;
nSolveIter 500;
nRelaxIter 5;
nFeatureSnapIter 10;
implicitFeatureSnap true;
explicitFeatureSnap true;
multiRegionFeatureSnap true;
nFaceSplitInterval 5;
}
addLayersControls
{
layers
{
Main
{
nSurfaceLayers 5;
expansionRatio 1.15;
firstLayerThickness 0.1;
}
Main_patch0
{
nSurfaceLayers 5;
expansionRatio 1.15;
firstLayerThickness 0.1;
}
Mid
{
nSurfaceLayers 5;
expansionRatio 1.15;
firstLayerThickness 0.1;
}
Mid
{
nSurfaceLayers 5;
expansionRatio 1.15;
firstLayerThickness 0.1;
}
}
relativeSizes true;
minThickness 0.001;
firstLayerThickness 1.0E-4;
expansionRatio 1.15;
nGrow 0;
featureAngle 180.0;
maxFaceThicknessRatio 0.5;
nSmoothSurfaceNormals 5;
nSmoothThickness 10;
minMedialAxisAngle 90.0;
maxThicknessToMedialRatio 0.5;
nMedialAxisIter 100;
nSmoothNormals 3;
slipFeatureAngle 30.0;
nRelaxIter 5;
nBufferCellsNoExtrude 0;
nLayerIter 50;
nRelaxedIter 20;
detectExtrusionIsland true;
}
meshQualityControls
{
maxNonOrtho 65.0;
maxBoundarySkewness 20.0;
maxInternalSkewness 4.0;
maxConcave 80.0;
minVol 1.0E-14;
minTetQuality 1.0E-20;
minArea -1.0;
minTwist 0.02;
minTriangleTwist -1.0;
minDeterminant 0.01;
minFaceWeight 0.05;
minVolRatio 0.01;
minVolCollapseRatio 0.1;
nSmoothScale 4;
errorReduction 0.75;
relaxed
{
maxNonOrtho 75.0;
}
}
mergeTolerance 1.0E-6;
debug 0;

[Bob Tipton]

Found it!!

The cloud service stopped the run by setting:

stopAt writeNow;


// If that had been spelled rightNow, I would have spotted it sooner.

When I downloaded the result from the cloud service this flag persisted into the next runs.

simpleFoam DOES NOT reset this flag at start - that counts as a design bug IMO.
So, it does one run and stops right now because it thinks it was aborted.

The correct setting should be



stopAt endTime;

Resetting to that value gets the run working again.

[Tobermory]

Just in case you had missed this, it's not spelled "writeNow" out of laziness or dyslexia ... it means stop now (ie at the end of the iteration) and write out the fields, as opposed to noWriteNow which means stop now but don't write out fields.

[Bob Tipton]

As a life long, native speaker of standard American English - that's ambiguous at best and and wrong at worst.


"When should we stop?"
"Write now"


Would cause the person asking the question to grab a pen and paper and start writing - it has no implication of 'stopping' the run.


If writing a file is involved, that would count as a side effect.


Anyway - it's fixed.


I think the cloud service corrected their error so the input file isn't mysteriously modified.

[Tobermory]

Glad it's sorted, and yes, agreed - it would have been clearer (if a little more clumsy) to make this writeAndStopNow or something similar. There are a few things in OF that are legacy curiosities, but the online manual has a lot of good info in it (I am sure that you know this already, but here is the link anyway - https://cfd.direct/openfoam/user-guide/v6-controldict/), and my suggestion is make copious notes - I rely heavily on them!