QA: pre-v2006
Tutorials - as of 05.06.2020
- incompressible/simpleFoam/turbineSiting - decomposePar - epsilon - inlet patch missing value
- lagrangian/reactingParcelFoam/verticalChannelLTS - solver - unallocated autoPtr of type N4Foam9Function1IdEE
- lagrangian/simpleReactingParcelFoam/verticalChannel - solver - unallocated autoPtr of type N4Foam9Function1IdEE
- incompressible/pisoFoam/LES/motorBike - pisoFoam -
[7] --> FOAM FATAL ERROR:
[7] There are 0 outstanding send requests and you are asking for i=0
Maybe you are mixing blocking/non-blocking comms?Compilation - as of 09.06.2020
- SPDP - atmNutkWallFunctionFvPatchScalarField.C: nutw = max(nutw, 0.0)
- General - quite a lot of unused variables in chtMultiRegionFoam (setRegionFluidFields.H)
- VoFphaseCompressibleTurbulenceModels seems not available while compiling compressibleInterIsoFoam - maybe sequence?
Known issues (to be left as unresolved/unresolvable)
- avalanche failures (all cases) due to use of std::regex, which does not work on older gcc. Reported as issue.
- external-solver failure for pipeOneD - uses the hypre solver, which may (or may not) be available with the petsc compilation.
Child items
0No child items are currently assigned. Use child items to break down this issue into smaller parts.
- !370v2006
Activity
Will look at the pisoFoam. To do with the non-blocking MPI_IAllreduce. Fixed in aa956f4b
Edited by Mattijs Janssensmentioned in commit 003ec000
turbineSiting : uses atm bcs but does not have
libs (atmosphericModels);mentioned in commit 6a8dab00
commit c712abad should fix the problem of the double entry for surfaceTension table. "Taking out sampledInterface FO from sampling lib and adding it to geometricVoF" With this change the reactingEuler tut should run.
The change from direction to normal entry in planeImplicit function have different meaning. (opposite direction) Thus, I did not made it backwards compatible as users (like me) can get confused. I changed the normal in tut/verification cases for icoReacting..Foam and interCond..Foam for the Stephan problems
mentioned in merge request !370 (merged)
mentioned in commit c21c5e07
@andy (release notes in the web)
-
Improved thermal baffle
In the example for the BC the entries mixture, radiation and extrude are missing. If it is too long we can cut the radiation dictionary, but the extrude model should be kept for reference.
-
Interface height The second and third paragraphs are the same key entry.
-
Module-OpenQBMM tested on 17 June
- Application reconstructPar - case diluteVdfTransportFoam/bubbleColumn
- Application polydisperseBubbleFoam - case polydisperseBubblyFoam/angledMixer-nutkWallFunctionFvPatchScalarField
- Application compressiblePbeTransportFoam - case compressiblePbeTransportFoam/forwardStep:FOAM FATAL ERROR-Operator - is undefined for unoriented and oriented types
- Application diluteVdfTransportFoam - case diluteVdfTransportFoam/bubbleColumn:FOAM FATAL ERROR-equest for surfaceScalarField phi.water from objectRegistry region0 failed available objects of type surfaceScalarField are 3(ghf alphaRhoPhi.water alphaPhi.water)
- Application vdfTransportFoam - case diluteVdfTransportFoam/rotatingCylinder:FOAM FATAL ERROR-Entry 'd' not found in dictionary
- Application mixingTransportFoam - case mixingPopulationBalance:FOAM FATAL ERROR-cannot find file
- ApplicationApplication blockMesh - case pbeFoam/aggregationBreakup:FOAM FATAL ERROR
- Application blockMesh - case pbeFoam/pureGrowth:FOAM FATAL ERROR
Edited by PraveenJagnathan_01Module-External solevr tested on 18 June
- Application simpleFoam - case incompressible/simpleFoam/pitzDailyFoam:dictionary:subOrEmptyDict
Edited by PraveenJagnathan_01@Prashant Regarding
General - quite a lot of unused variables in chtMultiRegionFoam (setRegionFluidFields.H)
chtMultiRegionFoam/fluid/initContinuity.H chtMultiRegionFoam/chtMultiRegionTwoPhaseEulerFoam/fluid/initContinuityErrs.H
Before these files are called the fluid fields have already been assigned, hence the warning when trying to re-assign them again. Only the mesh field is required to instantiate the continuity error for each reagion. See the following patch.
Edited by Aitor Atxutegimentioned in commit 15d6febe
Tutorials failing as of 25.06.2020
- multiphase/compressibleInterFoam/laminar/climbingRod - solver diverge
- multiphase/reactingMultiphaseEulerFoam/laminar/mixerVessel2D - solver diverge
Following tutorials seem are not reachable by 'Allrun' at incompressible/adjointOptimisationFoam
- incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012
- incompressible/adjointOptimisationFoam/shapeOptimisation/sbend
Edited by Sergio Ferraris/tutorials/incompressible/adjointOptimisationFoam/Allrun: foamRunTutorials -skipFirst
It does not run several cases in recursive folders. Tried: foamRunTutorials , cases run fine, didn't look at all of them but they reached completion.
climbingRod runs fine now. Reduced the endTime as it does not do much
mixerVessel2D runs further but not guaranteed completion. It behaves bad in an oscillatory way, thus I reduced the order of schemes and so, still some staggered pattern so it might crash later in time.
Module OpenQBMM
- Tutorial compressiblePbeTransportFoam/forwardStep/ FOAM FATAL ERROR:Operator - is undefined for unoriented and oriented types
Edited by Mark OLESENAdditional failures :log.error
- Added support for
scaleinstead ofconvertToMeterin 2008 (4c3c2385) so could/should be change to scale, but can continue to ignore it. -
functionObjectLibslooks slightly ugly, but can ignore it.
@albertop - looks like issue in surface field not setting its orientation:
log.compressiblePbeTransportFoam: Operator - is undefined for unoriented and oriented typesRelated?
log.diluteVdfTransportFoam: [0] --> FOAM FATAL ERROR: [0] request for surfaceScalarField phi.water from objectRegistry region0 failed available objects of type surfaceScalarField are 3(ghf alphaRhoPhi.water alphaPhi.water)This looks like a change in syntax?
/diluteVdfTransportFoam/rotatingCylinder: log.vdfTransportFoam: Entry 'd' not found in dictionary "populationBalanceProperties.velocityCoeffs.collisionKernel": populationBalanceProperties.velocityCoeffs.collisionKernel- Added support for
@mark the latter is an error in the Allrun: it uses vdfTransportFoam instead of diluteVdfTransportFoam. Both can be used if d and rho are uncommented in populationBalanceProperties. It is corrected in the linked branch on GitHub.
I need to investigate the other two. Particularly the problem with orientation because it happens with fields that are calculated internally, so I would not expect it (e.g. line 137 of ~/OpenQBMM/applications/solvers/compressible/explicitRhoFoam/compressibleSystem/fluxFunctions/HLLCFlux/HLLCFlux.C and all the other flux functions). Is there a difference between how .org and .com deal with orientation? I can run the code on the original OF where it was developed (OF.org 7), so this would seem to be the case.
Edited by Alberto Passalacqua
-
@andy - please a quick note for Alberto about handling of orientedType?
We introduced the
orientedflag for surface fields to discriminate between flux fields that are oriented, i.e. where the sign depends on owner->nbr connectivity, and plain interpolated fields, e.g. pressure on faces.If you apply a field operation that includes the area vector field
Sf()the resultant field becomes oriented; similarly, taking, e.g. themag()of an oriented field makes it 'unoriented'. The rules applied when dealing with [un]oriented fields also gives us an extra layer of protection/verification that the mathematics is consistent.If the field is constructed without using field operations and it is a flux field, you should set the oriented type to
true.Is there a way to globally disable the check locally in a solver/library?
What would be the difference in terms of result of the operations?
I am looking at https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/compressible/rhoCentralFoam/rhoCentralFoam.C , where
surfaceScalarField phiv_pos("phiv_pos", U_pos & mesh.Sf()); // Note: extracted out the orientation so becomes unoriented phiv_pos.setOriented(false); surfaceScalarField phiv_neg("phiv_neg", U_neg & mesh.Sf()); phiv_neg.setOriented(false);does not seem right, because phiv_pos and phiv_neg are indeed oriented (they have been oriented with upwinding and they do have the orientation of the face normal). Also, in the same solver:
surfaceVectorField phiU(aphiv_pos*rhoU_pos + aphiv_neg*rhoU_neg); // Note: reassembled orientation from the pos and neg parts so becomes // oriented phiU.setOriented(true);phiU is set to oriented (correct), but the reassebled orientation is implicit (none of the fields used in the sum were?)
In the flux functions in OpenQBMM (https://github.com/OpenQBMM/OpenQBMM/tree/master/applications/solvers/compressible/explicitRhoFoam/compressibleSystem/fluxFunctions) the situation is analogous, but with more points where the issue shows up. For example, when multiplying the reconstructed pressure pOwn or pNei for the normal and, in the AUSM+ flux, also when computing the auxiliary fields. Explicitly setting orientation requires to split out the operation, then set the orientation, so being able to revert at least locally to the previous behavior would make sense (and would be the expected mathematical behavior, since setting orientation by hand seems to be arbitrary, at least if I understand it correctly).
Edited by Alberto Passalacqua
OK, I'll look into it more, but the flux is automatically oriented and any reconstructed field is unoriented if not dotted with the surface normal vector. Basically, now we have to manually troubleshoot operations that involve both types of fields? It seems redundant...
What is the ETA for the release?
TestLoop results 1912 vs 2006
Expected minor differences in the following solvers( due to updates on the solvers)
- IsoVector solvers
- icoReactingMultiPhaseInterFoam and condensatingEvaporatingFoam
- Reacting Euler solvers with boiling Wall BC
- atm BC
- AMI (but this test was done before the AMI merge)
- Anyone other change which can affect tutorial results by other team members?
Major results differences:
-
twoPhaseReactingEulerFoam cases seem to have general changed, (not sure why so far) The difference results are not large but there quiet consistent in all cases. Ideally we'd want some benchmark for ReactingEuler solvers.
-
Lagrangian cases tend to differ on different runs.
-
The rest of the red flags are withing reasonable values.
I encountered the same oriented and unoriented operation issue and reported it here. I wanted to bring it to your attention again. Also I agree with @albertop's comment saying "...the flux is automatically oriented and any reconstructed field is unoriented if not dotted with the surface normal vector". Maybe this "extra layer of protection" is backfiring.
