There seems to be an issue regarding pimpleCentralFoam with wedge domains. To replicate, please run the attached case. This is a standard benchmark case for supersonic compressible solvers. The grid is uniform and is wedge type. Using rhoCentralFoam the solution is correct. Using pimpleCentralFoam, there is an odd spurious jet type phenomenon along the central axis.

The issue is independent of flux scheme (have tried VanLeer and VanAlbada) as well as local time stepping, Euler or backward time stepping, or significant changes in CFL. This indicates to me it is a bug in the flux formulation when dealing with the wedge (empty) central axis boundary.
CDNozzleValidation.tar.gz

I am running this suite of solvers with OpenFOAM 6.

Question concerning

psiU_nei depends on psi_nei, should it not be affected by this correction? Just wondering while looking through the code...

hi!
I have the following error when try to compile it for OF2306:

dima@DESKTOP-VDH9855:~/solvers/Sources$ ./Allwmake
wmake libso (pimpleCentral)
make: *** No rule to make target '/usr/lib/openfoam/openfoam2306/src/OpenFOAM/lnInclude/FieldBase.H',
needed by 'Make/linux64GccDPInt32Opt/kappaFunctions/kappaFunction/kappaFunction.C.dep'. Stop.

• wmake

Hei!

I have some challenges to run a simple 2.25 Mach nozzle problem since the solver crashes with negative Temperature/Pressure fields.
I observe similar behavior for Ansys Fluent with the same setup, but in Fluent its solvable just by settings of the min/max density and pressure. I looked over the code and don't see any limiting factors or, I just missed something?
In practice, it will be useful to have this option to be configurable in the solver's settings.

Thanks, Dmitry

I have modified version 4.1 of these solvers so that they may work with version v1706.

Most important changes come from the need to use some orientedType variables. In particular cSf_own.setOriented(true) and cSf_nei.setOriented(true) in createCommonCentralFields; aSf.setOriented(false) after the second call to updateKappa.H in reactingPimpleCentralFoam.C.

dQ and Sh have been supressed (Sh is now Qdot, dQ has dissapeared).

There has been also some changes in capital letters of the names of some thermodynamic variables and betaSolidIO.headerOk() has been replaced by
betavSolidIO.typeHeaderOk(true) in createSolidFields.H.

Hello
I tried this solver with geometry and BC of pitzDaily from rhoPimpleFoam, it seems it does not work with this a little bit more complex geometry. I have changed mesh complexity and yet there are points where high pressure appears some where in the geometry (before flow development, attached photo) and do not let the air to flow within. Do you have any idea? have you tried this with a high quality mesh?

Hello,

I have successfully implemented the solver pimpleCentralFoam and chtPimpleCentralFoam in Openfoam version 18.12. Then I tested the pimpleCentralFoam solver using the attached forwardStep tutorial. The simulation does not crash with a serial calculation. Strangely, the simulations in parallel calculations crash due to negative temperatures. I've attached the tutorial case and the solver. It can be seen in the log file that within one time step the temperature becomes negative.
Do you know what the problem is?

ForwardStep.tar.gz

I am trying to couple pimplrCentralFoam with adjointShapeOptimization in openfoam, after replacing the default simple solver (defined inside adjointShapeOptimizationFoam.C) with pimpleCentral solver and compile it successfully, I have some problems to choose the right solver for pa (adjoint pressure) and Ua (adjoint velocity). In original fvSolution file in adjointShapeOptimizationFoam it looks like:
"(p|pa)"
{
solver GAMG;
tolerance 1e-08;
relTol 0.01;
smoother GaussSeidel;
}

"(U|Ua|k|epsilon)"
{
    solver          smoothSolver;
    smoother        GaussSeidel;
    nSweeps         2;
    tolerance       1e-08;
    relTol          0.1;
}

with simple algorithm.
The question is in which way can i define the right solvers inside adjoint solver which can calculate and simulate sonic flow without errors? I receive an error that i think is because of sudden temperature drop, although i have temperature limit between 299-300 K in fvOption.
enclosed i included the fvSolution i already used, and an errorLog i receive during running this foam.
I appriciate your help in this regard.

fvSchemes.txt
fvSolution.txt
errorLog.txt

Is there a pisoCentral in of6-dev branch or it will be included later on for OF6? Thanks

I'm currently try to compile pimpleCentralFoam on openfoam v1912 and i receive errors regarding -lpisoCentral, or something. i found the pimpleCentral folder for v1912 a little bit disordered. like there is no pimpleCentralFoam.C for this version. can anyone help?
https://photos.google.com/share/AF1QipPCJzUh3tNCRMd58VS6FT9gk253k51eC68txPeuewwumJaL3dEW8z5lwPHZz6dUgQ?key=dUF0eVVIZWxWVUZYY29nejQwMlotWExDZU5VeWhR

Hi,

I have seen the implementation of different Schmidt numbers in QGDFoam which is an intersting feature. How can it be implemented in reactingPimpleCentralFoam? Because I am not very familiar with programming. Thank you in advance.

Regards.

Hi
I intended to use this class in OpenFOAM v7, but since there're massive changes in ACMI classes between OF v4 and v7, it becomes really difficult to modify the original code. Is there anybody who can help me with this problem?

If it would help, I did some minor changes as follows:

• change const cyclicACMIFvPatch& acmiNeiPatch = acmiPatch.neighbPatch();
  to const cyclicACMIFvPatch& acmiNeiPatch = acmiPatch.neighbFvPatch();
• change label nonOverlapOwnID = acmiOwnPatch.nonOverlapPatchID();
  to const fvPatch& nonOverlapOwnID = acmiOwnPatch.nonOverlapFvPatch();
• and change label nonOverlapNeiID = acmiNeiPatch.nonOverlapPatchID();
  to const fvPatch& nonOverlapNeiID = acmiNeiPatch.nonOverlapFvPatch();
• Also I tried to change nei_field.boundaryFieldRef()[acmiOwnPatch.index()] +=(1.0 - acmiOwnPatch.AMI().srcWeightsSum())*nei_field.boundaryField()[nonOverlapOwnID];
  to nei_field.boundaryFieldRef()[acmiOwnPatch.index()] +=(1.0 - acmiOwnPatch.AMIs().srcWeightsSum())*nei_field.boundaryField()[nonOverlapOwnID];
  but because the output of acmiOwnPatch.AMIs() has become a pointer list in contrast as what it was in OF v4, it doesn't have srcWeightsSum() member anymore! Also because I changed the type of nonOverlapOwnID it doesn't fit in nei_field.boundaryField()[nonOverlapOwnID] anymore!

Hello,
I ran a high-speed combustion case in parallel successfully with reactingPimpleCentralFoam on OpenFOAMv1912. Now I need to run it on v2212 for further work. I get an error. (*** Error in `reactingPimpleCentralFoam': malloc(): memory corruption: 0x0000000007cece30 ***). When I run it with a serial calculation, there is no error. I also tested it with reactingFoam(v2212) and pimpleCentralFoam(v2212) in parallel, there is no error. Do you know how to solve it?
Here is my case with the error log.
case.zip

This is for OF6 branch and Ubuntu 18.04.
I faced problems using wallHeatFlux utility for the chtMultiRegionCentralFoam solver for provided tutorial case (superSonicCone). I am wondering is it doesn't support this utility or perhaps if am not using it right. How do I calculate the heat flux on the solid surface?

I tried following but doesn't work with any variations: e.g.
chtMultiRegionCentralFoam -postProcess -func wallHeatFlux

--> FOAM FATAL ERROR:
Wrong number of arguments, expected 0 found 1
Invalid option: -postProcess
Invalid option: -func

OR postProcess -func wallHeatFlux

--> FOAM FATAL ERROR:
Cannot find file "points" in directory "polyMesh" in times "0" down to constant

From function virtual Foam::IOobject Foam::fileOperation::findInstance(const Foam::IOobject&, Foam::scalar, const Foam::word&) const
in file global/fileOperations/fileOperation/fileOperation.C at line 871.

FOAM exiting

OR, alternatively: included the following snippet in the controlDict:
functions {#includeFunc wallHeatFlux}

Starting time loop

--> FOAM Warning :
From function bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 746
Caught FatalError
--> FOAM FATAL ERROR:

request for objectRegistry region0 from objectRegistry superSonicCone_v1.3 failed
available objects of type objectRegistry are

2
(
fluid
solid
)

From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
in file /home/ubuntu/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 193.

This is true for MachNo as well. Could you please clarify about this?
Thanks

I am wanting to simulate hypersonic flow (Mach 6) past a winged vehicle. Will hybridCentralSolvers handle such high Mach numbers? If not, will the QGDSolvers handle such?

Thanks.