BUG: Tutorial case failure

Multiphase:

• reactingTwoPhaseEulerFoam/RAS/wallBoiling
• reactingTwoPhaseEulerFoam/laminar/fluidisedBed
• reactingTwoPhaseEulerFoam/laminar/mixerVessel2D

combustion

• fireFoam/les/oppositeBurningPanels (missing boundaryRadiationProperties file)

heatTransfer

• chtMultiRegionFoam/windshieldDefrost

incompressible

• simpleFoam/rotorDisk (snappyHexMesh failure)

lagrangian -MPPICFoam/column (undefined applyLimiting)

• MPPICFoam/cyclone (undefined applyLimiting, Allrun parallel compatible command)
• icoUncoupledKinematicParcelFoam/hopper/hopper* (undefined flux(U) )

mesh

• parallel/cavity/log.redistributePar.reconstruct
• foamyHexMesh/simpleShapes/log.surfaceBooleanFeatures (issue #124 (closed))

@Sergio @Mattijs

Ran parallel/cavity/log.redistributePar.reconstruct and replicated crash. Changed Make/options and no crash. Reverted Make/options and no crash.

mentioned in commit e826c66748301d29f8afe4c9e156f97574d273c8

/home/alex2/prashant/QA/MEDIUM_TESTS/combustion/XiDyMFoam/annularCombustorTurbine

@wyldckat

Using latest tutorial file from Foundation-dev, "reactingTwoPhaseEulerFoam/RAS/wallBoiling" was successful in rebased OpenFOAM+develop branch. However other two tutorials fail.

• reactingTwoPhaseEulerFoam/laminar/fluidisedBed
• reactingTwoPhaseEulerFoam/laminar/mixerVessel2D

Could you please confirm if they are working till completion in Foundation code?

reactingTwoPhaseEulerFoam/laminar/fluidisedBed seems to work in develop branch

@Prashant I have confirmed that the two tutorials you've asked about, namely:

• multiphase/reactingTwoPhaseEulerFoam/laminar/fluidisedBed
• multiphase/reactingTwoPhaseEulerFoam/laminar/mixerVessel2D

run till completion without any error messages with a recent commit from the Foundation's OpenFOAM-dev repository, commit 477d40f0a23cab.

By Bruno Santos on 2016-06-08T16:18:57 (imported from GitLab project)

Thanks Bruno for your testing and comments.

chtMultiRegionFoam/windshieldDefrost MPPICFoam/cyclon icoUncoupledKinematicParcelFoam/hopper/hopper*

Work fine

mentioned in commit e9eb77bd56ede993f1e6e773e7556d6908a255e6

Fixed the shm failure of the rotorDisk tutorial in e9eb77bd56ede993f1e6e773e7556d6908a255e6

mentioned in commit 8a19f43a52f4a88775566d6e5e159a986086f03f

home/alex2/prashant/QA/MEDIUM_TESTS/combustion/XiDyMFoam/annularCombustorTurbine.

It works in develop

Prashant: The annularCombustorTurbine failed in our cluster using develop as well ?. Can you run it using the master branch. Thanks

Prashant: Does this tutorial take so long? chtMultiRegionFoam/windshieldDefrost still running on Alex.

/home/alex2/prashant/QA/MEDIUM_TESTS/combustion/XiDyMFoam/annularCombustorTurbine/log.XiDyMFoam3 (failed with master on muttley)

windshieldDefrost : yes, I'm also surprised to see it so long. (Estimated to take approx. 6 days) Somehow I seem to miss this case from our last test.

windshieldDefrost: I modified some settings. Run it in parallel and let's check how long it takes to reach completion (600 sec)

Status changed to closed

mentioned in commit c52766db8d61a9c4883aa5ff94d4b6c5022e6b0a

Above commit fixes wallBoiling case. Needed more underrelaxation on the mass transfer.

for_sergio_fluidised_bed.ogv

Sergio, I think the 0/T.* should have temperature 600 on the inletOutlet. It is the reverse flow which causes a dramatic temperature shock which on muttley might just be a bit worse?

Status changed to reopened

Yes, changing T for particles the tutorial runs until completion.

I observed dependency on writeControl

/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/multiphase/reactingTwoPhaseEulerFoam/laminar/

You could see

• mixerVessel2D-increasedWriteControl/ with writeInterval=1 -> completes successfully
• mixerVessel2D (unchanged settings, i.e. wirteInterval= 0.1 -> crashed after 1.1 sec

Should there be system dependency?

It is not the writing per se but the timestep adjustment to make the writeInterval (since 'writeControl adjustableRunTime')

Correct, but just wondering is this timeStep adjustment is system dependent?

It is a tiny bit system dependent because of numerical tolerances. Same way muttley might have different residuals to e.g. preston.

However the case should probably not be this sensitive to timestep changes - it might be good to have a look at it.

@Prashant , can you upload the two log files with the same settings on different machines?.

log-files.tgz

Attached log files from muttley and from alex (from your area)

I can't see any problem in these logs.

These are on alex :? mixerVessel2D-increasedWriteControl/ with writeInterval=1 -> completes successfully mixerVessel2D (unchanged settings, i.e. wirteInterval= 0.1 -> crashed after 1.1 sec

If so I could run the problematic case on Alex wirteInterval= 0.1. Probably it is what happens on Mutley.

Status changed to closed