|
[Sponsors] |
postProcess: Run-time data processing for multiRegion case |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 29, 2017, 17:30 |
postProcess: Run-time data processing for multiRegion case
|
#1 |
Senior Member
|
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: Code:
functions { #includeFunc flowRatePatch } 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. |
|
April 30, 2017, 02:03 |
|
#2 |
Senior Member
|
I'm using opebfoam 4.x on bluCFD CORE 2016—1
Sent from my ASUS_X008D using CFD Online Forum mobile app |
|
May 1, 2017, 03:47 |
|
#3 |
Senior Member
|
Hi,
this is a initial warning when I execute chtMultiRegionSimpleFoam: Code:
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. This is the FOAM warning I face when I execute Code:
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 |
|
May 1, 2017, 16:54 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
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:
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.
__________________
|
|
May 1, 2017, 18:28 |
|
#5 |
Senior Member
|
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. Code:
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; } } 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. Code:
# 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 Thanks. Regards Michele. |
|
May 8, 2017, 19:21 |
|
#6 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
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 |
|
May 9, 2017, 00:35 |
|
#7 |
Senior Member
|
||
May 9, 2017, 18:54 |
|
#8 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Other] Contribution a new utility: refine wall layer mesh based on yPlus field | lakeat | OpenFOAM Community Contributions | 58 | December 23, 2021 02:36 |
Run time post processing is crashing pimpleDyMFoam for a plunging airfoil | pruthvi1991 | OpenFOAM Post-Processing | 2 | September 4, 2015 00:31 |
Is Playstation 3 cluster suitable for CFD work | hsieh | OpenFOAM | 9 | August 16, 2015 14:53 |
[Commercial meshers] fluentMeshToFoam multidomain mesh conversion problem | Attesz | OpenFOAM Meshing & Mesh Conversion | 12 | May 2, 2013 10:52 |
calculation diverge after continue to run | zhajingjing | OpenFOAM | 0 | April 28, 2010 04:35 |