[student666]

Hi,

I would like to use the postProcess utility, but I can't set up properly the control dict file... I think.

I'm following what is written on the userGuide at chapter 6.2.2.

I've modified the controlDict file into multiRegionHeaterRadiation into chtMultiregionSimpleFoam case tutorial:

functions 
    {
        #includeFunc flowRatePatch 
    }

I also added the flowRatePatch configuration dict file, but I can't see the post process folder inside my case folder, only the time folder up to 1800.

Can someone explain me how to set it up properly for a multiregion case?
How to set up for a parallel one?

thanks a lot.

Regards.

[student666]

I'm using opebfoam 4.x on bluCFD CORE 2016—1

Sent from my ASUS_X008D using CFD Online Forum mobile app

[student666]

Hi,

this is a initial warning when I execute chtMultiRegionSimpleFoam:

Create time

Create fluid mesh for region bottomAir for time = 0

Create fluid mesh for region topAir for time = 0

Create solid mesh for region heater for time = 0

Create solid mesh for region leftSolid for time = 0

Create solid mesh for region rightSolid for time = 0

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

    request for objectRegistry region0 from objectRegistry multiRegionHeaterRadiation failed
    available objects of type objectRegistry are

5
(
bottomAir
rightSolid
heater
topAir
leftSolid
)


    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
    in file db/objectRegistry/objectRegistryTemplates.C at line 193.

I can't understand why OF asks for region0...


This is the FOAM warning I face when I execute

postProcess -func "flowRatePatch(name=maxX)" -region topAir

------

Create mesh topAir for time = 0

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

    request for objectRegistry region0 from objectRegistry multiRegionHeaterRadiation failed
    available objects of type objectRegistry are
1(topAir)

    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
    in file db/objectRegistry/objectRegistryTemplates.C at line 193.

Time = 0

Reading fields:


Executing functionObjects

Time = 300

Reading fields:
    surfaceScalarFields: phi


Executing functionObjects

Time = 600

[wyldckat]

Greetings student666,

Oh, so it was you who reported this issue: https://bugs.openfoam.org/view.php?id=2535

I've written on the bug report a brief solution so far and I've written another solution for yPlus here: OF 4.0 multiregion case calculate yPlus

Essentially in your situation, the solution steps to your question is as follows:

1. Modify the entry you have to use the contents "functions" block to this:
   

   functions
   {
       flowRatePatch
       {
         name    maxX;
         region  topAir;
   
         #includeEtc "caseDicts/postProcessing/flowRate/flowRatePatch.cfg"
       }
   }

2. Then run:
   

   chtMultiRegionSimpleFoam -postProcess

And it should work.


If by any chance you ran the "Allrun-parallel" script in the case, then it will not work as intended, due to a weird issue regarding field reconstruction.


Best regards,
Bruno


edit: I've diagnosed the issue in the bug report and the conclusion that I reported there was that this is already fixed in commit 168b29e2cfc8062867ed30928d824188e0858630 in the original OpenFOAM 4.x development line: https://github.com/OpenFOAM/OpenFOAM...824188e0858630

Therefore, this bug/feature is still missing in blueCFD-Core 2016-1. I will try to release an update for blueCFD-Core this month, so that this and other issues are fixed too.

[student666]

Hi Bruno,

thanks, for supporting; your comments helped me lot!

By my point of view, it solved the problem: if you add more functions you can monitor more regions at the same time.

functions
	{
		flowRatePatchTop
		{
		  name    maxX;
		  region  topAir;

		  #includeEtc "caseDicts/postProcessing/flowRate/flowRatePatch.cfg"
		}
		flowRatePatchBott
		{
		  name    maxX;
		  region  bottomAir;

		  #includeEtc "caseDicts/postProcessing/flowRate/flowRatePatch.cfg"
		}
		
		probesBott
		{
			fields (p U);
			probeLocations
				(	
					(0.08 -0.02 0)
				);
			
			region	bottomAir;

		  #includeEtc "C:\Program Files\blueCFD-Core-2016\OpenFOAM-4.x\etc\caseDicts\postProcessing\probes\probes.cfg"
		}
		
		probesTop
		{
			fields (p U T);
			probeLocations
				(	
					(0.08 0.02 0)
				);
			
			region	topAir;

		  #includeEtc "C:\Program Files\blueCFD-Core-2016\OpenFOAM-4.x\etc\caseDicts\postProcessing\probes\probes.cfg"
		}
		
		residualsTop
		{
			#includeEtc "caseDicts/postProcessing/numerical/residuals.cfg"
			fields (p U h);
			region	topAir;
		}
		
		residualsBottom
		{
			#includeEtc "caseDicts/postProcessing/numerical/residuals.cfg"
			fields (p U h);
			region	bottomAir;
		}
	}

I think that your proposal works for parallel-run as well, but you have to modify polyMesh for bottomAir, e.g.:

Changing minX and maxX to patch into polyMesh & for 0 folder update BC copying the values from topAir BC, gave me same results as for running in serial...

In any case, here follows some rows from the residuals dict; I can't understand why h field is not written, even if it's evaluated during the run.

# Residuals   
# Time        	p             	Ux            	Uy            	Uz            	h             
1             	1.0000000e+000	1.0000000e+000	7.6580260e-001	1.0000000e+000
2             	2.3807090e-001	2.7913900e-001	4.7209300e-001	3.9264110e-001
3             	1.9652420e-001	7.4250930e-001	2.3415060e-001	4.0435020e-001
4             	2.5728580e-001	5.9696150e-001	1.1835710e-001	4.7225250e-001
5             	2.3035000e-001	1.7290490e-001	1.2102510e-001	3.5757170e-001
6             	1.7255480e-001	4.9877770e-001	1.2496940e-001	2.6702590e-001
7             	1.3139860e-001	3.4717330e-001	6.8449320e-002	2.1177800e-001
8             	7.1993590e-002	2.4930500e-001	5.2033030e-002	1.7529060e-001

Can you help me with this?

Thanks.

Regards

Michele.

[wyldckat]

Greetings Michele,

My apologies for the late reply. This does look like it's another bug, because I tested this with OpenFOAM 4.x and OpenFOAM-dev on Linux and the same problem occurred.

Please report this issue at https://bugs.openfoam.org

Best regards,
Bruno

[student666]

Sure I will.

Regards

Sent from my ASUS_X008D using CFD Online Forum mobile app

[wyldckat]

Hi Michele,

My apologies, I only noticed sometime today that the "p" field exists but it's not solved in an equation. Unfortunately I didn't have enough time to come by the bug tracker to write what I had figured out, before the report was closed.

The correct name is "p_rgh", which is the field that is being solved, from the list of pressure fields.


There is still a bug, namely that even though the "p" field is registered, it is not being solved for. But since it's registered as a valid field, it shows up on the header of "residuals.dat", but it never gets any residual values for it. Therefore, the problem was not that the "h" field was missing, it was that the "p" field did not have any residuals assigned to it.

Technically, it can be considered that this is a missing feature and not exactly a bug, namely that it should only output the residuals for the fields that are being iteratively solved.

Best regards,
Bruno