[mabinty]

Dear all!!

I changed the procedure of parallelising with chtMultiregionFaom as described in the previous post a bit:

3) use the 0.001/air directory as initial directory 0/
4) run "decomposePar" => processor<n> has now a 0/ and constant/ directory
5) put processor<n>/constant/polyMesh and heater/ into processor<n>/0/air and processor<n>/0/ respectivly and copy the system/ directory into each processor<n>/ directory
6) run "mpirun.openmpi -np 4 chtMultiRegionFoam -parallel"

The simulation runs but aborts during the first time step of the solid calculation:

************************************************** *****
Region: air Courant Number mean: 0 max: 0
Region: air Courant Number mean: 0 max: 0
deltaT = 0.001199041
Time = 0.00119904

Solving for fluid region air
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for h, Initial residual = 1, Final residual = 3.867589e-07, No Iterations 15
Min/max T:min(T) [0 0 0 1 0 0 0] 100 max(T) [0 0 0 1 0 0 0] 632.0841
GAMG: Solving for pd, Initial residual = 1, Final residual = 0.08695774, No Iterations 3
GAMG: Solving for pd, Initial residual = 0.03317856, Final residual = 0.002205762, No Iterations 3
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (air): sum local = 0.0002709278, global = -2.734944e-05, cumulative = -2.734944e-05
GAMG: Solving for pd, Initial residual = 0.6863633, Final residual = 0.03345041, No Iterations 3
GAMG: Solving for pd, Initial residual = 0.0922989, Final residual = 8.175851e-07, No Iterations 13
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (air): sum local = 6.847878e-06, global = 9.906124e-08, cumulative = -2.725038e-05

Solving for solid region heater
DICPCG: Solving for T, Initial residual = 1, Final residual = 3.015545e-07, No Iterations 1
3 additional processes aborted (not shown)
************************************************** ****************

with the following error message:

************************************************** *****************
aa@lws16:~/OpenFOAM/aa-1.5.x/run/chtMultiRegionFoam/simpleRegionHeaterParall02$ mpirun.openmpi -np 4 chtMultiRegionFoam -parallel > log.chtMultiRegionFoam
[0] #0 Foam::error:rintStack(Foam::Ostream&)[3] #0 Foam::error:rintStack(Foam::Ostream&) in "/home/aa/OpenFOAM/O in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[0] #1 Foam::sigSegv::sigSegvHandler(int)penFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[3] #1 Foam::sigSegv::sigSegvHandler(int) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[0] #2 in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[3] #2 ???? in "/lib/l in "/lib/libc.so.6"
[0] #3 ibc.so.6"
[3] #3 Foam::tmp<Foam::Field<Foam::typeOfSum<double, double>::type> > Foam:perator+<double, double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[3] #4 Foam::tmp<Foam::Field<Foam::typeOfSum<double, double>::type> > Foam:perator+<double, double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #4 Foam::solidWallMixedTemperatureCoupledFvPatchScala rField::evaluate(Foam::Pstream::commsTypes) in "/home/aa/OpenFOAMFoam::solidWallMixedTemperatureCoupledFvPa tchScalarField::evaluate(Foam::Pstream::commsTypes )/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[3] #5 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #5 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[3] #6 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #6 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libfiniteVolume.so"
[0] #7 in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libfiniteVolume.so"
[3] #7 Foam::lduMatrix::solverPerformance Foam::solve<double>(Foam::tmp<Foam::fvMatrix<doubl e> > const&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #8 Foam::lduMatrix::solverPerformance Foam::solve<double>(Foam::tmp<Foam::fvMatrix<doubl e> > const&)main in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[3] #8 in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #9 __libc_start_main in "/lib/libc.so.6"
[0] #10 main in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[3] #9 __libc_start_main in "/lib/libc.so.6"
[3] #10 _start in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[lws16:06857] *** Process received signal ***
[lws16:06857] Signal: Segmentation fault (11)
[lws16:06857] Signal code: (-6)
[lws16:06857] Failing at address: 0x3e800001ac9
[lws16:06857] [ 0] /lib/libc.so.6 [0x7f5b913ab0a0]
[lws16:06857] [ 1] /lib/libc.so.6(gsignal+0x35) [0x7f5b913ab015]
[lws16:06857] [ 2] /lib/libc.so.6 [0x7f5b913ab0a0]
[lws16:06857] [ 3] chtMultiRegionFoam(_ZN4FoamplIddEENS_3tmpINS_5Fiel dINS_9typeOfSumIT_T0_E4typeEEEEERKNS_5UListIS4_EER KNSA_IS5_EE+0x68) [0x435108]
[lws16:06857] [ 4] chtMultiRegionFoam [0x431f78]
[lws16:06857] [ 5] chtMultiRegionFoam(_ZN4Foam14GeometricFieldIdNS_12 fvPatchFieldENS_7volMeshEE22GeometricBoundaryField 8evaluateEv+0xc6) [0x44ed26]
[lws16:06857] [ 6] /home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libfiniteVolume.so(_ZN4Foam8fvMatrixIdE5solveERNS_ 7IstreamE+0x19f) [0x7f5b933a1dcf]
[lws16:06857] [ 7] chtMultiRegionFoam(_ZN4Foam5solveIdEENS_9lduMatrix 17solverPerformanceERKNS_3tmpINS_8fvMatrixIT_EEEE+ 0x50) [0x44a2e0]
[lws16:06857] [ 8] chtMultiRegionFoam [0x440eec]
[lws16:06857] [ 9] /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5b91396466]
[lws16:06857] [10] chtMultiRegionFoam [0x41c019]
[lws16:06857] *** End of error message ***
mpirun.openmpi noticed that job rank 0 with PID 6854 on node lws16 exited on signal 15 (Terminated).
************************************************** ****

When I decompose the domain into 4 subdomains, subdomain 0 and 3 have no interface with the solid region; whereas with 2 subdomains, both share patches with the solid region, the calculation aborts at the same time as before but the error message looks different:

************************************************** ******
aa@lws16:~/OpenFOAM/aa-1.5.x/run/chtMultiRegionFoam/simpleRegionHeaterParall$ mpirun.openmpi -np 2 chtMultiRegionFoam -parallel > log.chtMultiRegionFoam
[0] #0 Foam::error:rintStack(Foam::Ostream&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[0] #1 Foam::sigFpe::sigFpeHandler(int) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/lib/linux64GccDPOpt/libOpenFOAM.so"
[0] #2 ?? in "/lib/libc.so.6"
[0] #3 double Foam::max<Foam::fvPatchField, double>(Foam::FieldField<Foam::fvPatchField, double> const&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #4 Foam::dimensioned<double> Foam::max<double, Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #5 main in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[0] #6 __libc_start_main in "/lib/libc.so.6"
[0] #7 _start in "/home/aa/OpenFOAM/OpenFOAM-1.5.x/applications/bin/linux64GccDPOpt/chtMultiRegionFoam"
[lws16:05764] *** Process received signal ***
[lws16:05764] Signal: Floating point exception (8)
[lws16:05764] Signal code: (-6)
[lws16:05764] Failing at address: 0x3e800001684
[lws16:05764] [ 0] /lib/libc.so.6 [0x7f4208af70a0]
[lws16:05764] [ 1] /lib/libc.so.6(gsignal+0x35) [0x7f4208af7015]
[lws16:05764] [ 2] /lib/libc.so.6 [0x7f4208af70a0]
[lws16:05764] [ 3] chtMultiRegionFoam(_ZN4Foam3maxINS_12fvPatchFieldE dEET0_RKNS_10FieldFieldIT_S2_EE+0x160) [0x44f7c0]
[lws16:05764] [ 4] chtMultiRegionFoam(_ZN4Foam3maxIdNS_12fvPatchField ENS_7volMeshEEENS_11dimensionedIT_EERKNS_14Geometr icFieldIS4_T0_T1_EE+0x20) [0x4806e0]
[lws16:05764] [ 5] chtMultiRegionFoam [0x441761]
[lws16:05764] [ 6] /lib/libc.so.6(__libc_start_main+0xe6) [0x7f4208ae2466]
[lws16:05764] [ 7] chtMultiRegionFoam [0x41c019]
[lws16:05764] *** End of error message ***
mpirun.openmpi noticed that job rank 0 with PID 5764 on node lws16 exited on signal 8 (Floating point exception).
************************************************** ****************

I greatly appreciate your comments!! Thx in advace,

Aram

[sven82]

i got the same problem?

[cvv]

Can anyone comment on the difference in the methods of the chtMultiRegionFoam solver where each region is solved per timestep with boundary conditions being exchanged vs. the method of Hrvoje which this thread is based on? As I understand it the latter is based on the multiprocessor methodology where data is also exchanged during the inner iterations of the timestep.

Is the one method significantly faster than the other? I am planning to test it, maybe it is so obvious that it does not matter?

Regards
Carel

[ouafa]

hi aram,
i've the same problem with chtMultiRegionFoam solver so i can't run it in parallel even after decompositing correctly the solid and fluid region by a little modified decomposePar routine. the error seems to be related to the fact that OF can't find "instance" the polyMesh/points file directly in processor*/constant path. in my case, there is two regions in the processor*/constant: fluid and solid witch contain a polyMesh subdirectory.
do you have some idea to help me if you have already run succefully the solver?
thank's in advance.

[benk]

Are all isues with conjugateHeatFoam sorted out? I'm using 1.5-dev

I'm trying to use a modified version of conjugateHeatFoam but I'm running into some issues with the solution. I'm getting strange behaviour between the two coupled regions and I'm not able to reproduce the solution that I get from Comsol.


My problem at the moment is fairly basic: Two steady-state diffusion equations on a 1D domain where the diffusion coefficient changes by 2 orders of magnitude at the interface between the two regions. So I have:

Region 1:
laplacian(Dleft,c) + 0.1 = 0 (at x=0 c=100)

Region 2:
laplacian(Dright,c) + 0.1 = 0 (at x=1 c=0)

I've done this for 2 cases with the profile of c vs x in the figures below:
Case 1: Dleft=10^-5, Dright=10^-4
Case 2: Dleft=10^-5, Dright=10^-3

They both give problems at the interface between the two regions (at x=0.5). This is my solver: multiRegionFoam.tgz.

Can anybody provide input on this?

Case 1:


Case 2:


Clearly I'm getting some sort of a discontinuity at the interface of the two regions. Any help would be much appreciated!

[benk]

I was able to solve this problem using chtMultiRegionFoam:



I'd still like to know if there's anything that can be done to fix my conjugateHeatFoam model though.

[mabinty]

hi ouafa,

since I ve used OF-1.6. there are no problems to run chtMultiRegionFoam in parallel. which version are you using? did you tried the tutorials? didi they work?

aram

[benk]

Originally Posted by benk

Are all isues with conjugateHeatFoam sorted out?

With some help I found that my problem was only in the interpolation scheme. When I specify harmonic in the laplacian of the fvSchemes file it works:

[r2d2]

Hi, I am using conjugateHeatFoam in order to simulate the cooling of a fuel cell plate. The setup is alright cause the solver runs but the trouble is that it reaches the maximum number of iterations in solving "T+T" whatever solver I choose out of smoothSolver/BiCGStab with any preconditioner. The solid part of the case has also a couple of GGI interfaces to deal with my non-conformal mesh of the various volumes that form the plate. Thing is that the same solid part with laplacianFoam runs much faster. Am I missing/messing something? Any idea much appreciated.
Radu

[dinonettis]

Dear all,

I'm using a DNS in-house code to validate conjugateHeatFoam. The testcase is a sphere in crossflow at low Re (=28). I'm solving with axisimmetric BCs (wedge) due to the physics of the flow.
The thermal diffusivities (k/rho*Cp) are set as follows:
air: DT=5.6e-5 m^2/s
solid: DT=8.1e-6 m^2/s
The inlet temperature, of the duct surrounding the sphere increases linearly in time, starting from 323K till 623K. The sphere initial temperature is also 323K.
Now, according to DNS (and to experimental results as well) the temperature of the sphere should vary non linearly in the beginning with an increasing deltaT with respect to the flow inlet temperature. Then a costant deltaT is reached between sphere and flow, i.e. also the temperature rise in the solid became linear.
Summarizing I obtain as final temperature for the solid 593K (final deltaT=30K).
Of course I'm not saying that there is a difference between temperature on both sides of the fluid/solid interface. But between the solid and the flow several diameters far from the it.
With conjugateHeatFoam, the temperature of the solid (at least at the interface) corresponds within 0.5K to the flow temperature far from it.
It seems like the temperature of the solid is adjusted after that one of the fluid is evalueted, although I know the 2 matrix are solved at the same time!
I also tried to decrease the DT of the solid (8e-8) or to let the flow start with a higher T (353K) than the solid initial one.
Nothing changes, that is very strange most of all in the latter case!! In the former one the only effect is a greater deltaT between the center of the sphere and the interface, as it should be since the conduction is slower.
But the temperature at the sphere/flow interface it's always very close to the inlet one.

Which could be the reason of such strange behaviour?!?!?
Suggestions are very welcome.
Thanks in advance for your help.

Regards,

Dino

[dinonettis]

ps: I tried to reduce the physical time of the simulation till I achieved the expected deltaT between the sphere and the inlet of the duct. I had to reduce it by a factor of 400x!!

[mabinty]

Hi Dino!

I experienced some problems with axisymmetric set-ups giving me unphysical results. I had to play around with the BCs to solve it. How did you set up your axisymmetric case (BCs ??).

Cheers,
Aram

[dinonettis]

Dear Aram,

the result of the simulation, at least the uncoupled flow around the sphere, seems to be ok in terms of pressure and velocity. However when I couple the solid part to start the CHT analysis the problem consists in the short time needed for the temperature to propagate in the solid. I don't know if it can be related with the BCs??
However this is the testcase:

http://rapidshare.com/files/393717776/sphere.tar.html

My only doubt is that in the solid mesh there is no axis declared as SimmetryPlane. In fact I had to create the mesh in Gambit in this case, and it was not possible to do that.
Let me know what you think about?
Thanks for your availability.

Dino

[dinonettis]

no idea??
dino

[maddalena]

Originally Posted by henrik

Yes, you can solve on three regions, but you need to duplicate the flow physics which is not natural unless the physics is actually different, e.g. turbulent on one side and visco-elastic on the other.

I suggest you try this (think of a sandwich):

1 fluid mesh with two regions: The toast
1 solid mesh: The stuff between the toast

Then cook using coupledFvScalarMatrix TEqns(2);

Henrik

Hi Henrik, how is going there?
I would like to have a conjugateHeatFoam version handling n number of solids and fluids. From what you said above, this would require to copy the physics for n times. Is that still true? That is an old post, thus I think something changed meanwhile...
Thank you for your time,

mad

[albem]

Originally Posted by Pierpaolo

Maria,
thank you very much for your reply.
I would have banged my head against my desk for days without your help.
A posteriori, I can say that a more careful reading of the thread on my part (#65 and #92) would have been advisable.

Pier

Hi Pier

Could you please post your files for the conjugateCavity and heatedBlock problem, when I ran conjugateHeatFoam I just obtained results for the conjugateCavity it seems that heatedBlock is not being resolved

Thanks

Alberto

[albem]

Originally Posted by hjasak

You have to specify the regionCouple patches by hand. Move the boundary file somewhere, create the meshes using blockMesh and then edit the two boundary files to specify the coupling. You've got the example - it is in the current boundary file.

I am still looking to sort out the user interface, but at least the solver is working properly.

Enjoy,

Hrv

Hi

I have installed OpenFOAM-1.6-ext on my Mac, I could compile conjugateHeatFoam solver but when I ran it I got

--> FOAM FATAL ERROR:
Attempt to cast type wall to type lduInterface

From function refCast<To>(From&)
in file /Users/hjasak/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/typeInfo.H at line 115.


It is strange to me because the directory /Users/hjasak/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude

does not exist in my Mac

Any help is welcome

Alberto

[albem]

Hi Professor Hjasak

I am simulating the dynamic and heat transfer behaviour between 2 concentric square ducts with a certain duct wall thickness and when I run my solver I got

--> FOAM FATAL IO ERROR:
Unable to set reference cell for field p2
Please supply either p2RefCell or p2RefPoint

have two fluid domains: the core flow and flow between the ducts, I have tried to modify

label p2RefCell = 0; For other values
scalar p2RefValue = 0.0;

but it is not recognize when I run the code, also I have put the same value at my fvSolution file

PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 0;
pRefCell Other Value;
pRefValue 0;

}


any help is welcome

Thank you Alberto

Originally Posted by hjasak

Sure, no problem - you can have one fluids region (wih as many bits as you like, one solid region (again, in bits if you wish) and as many interfaces as you want.

If you'd like to have multiple solids and fluids for whatever reason, please let me know.

Hrv

[albem]

My questions is simpler

How can I deal with to driven cavity flows sorrounding the heated block, I have tried to include a second solveFluid. H subroutine but I got segmentation faul in my code when I ran this case

Starting time loop

Time = 0.001

Courant Number mean: 0 max: 0 velocity magnitude: 0
DILUPBiCG: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for p, Initial residual = 0.108226751719, Final residual = 8.51046489737e-11, No Iterations 211
time step continuity errors : sum local = 1.13409612376e-24, global = 9.40734577639e-25, cumulative = 9.40734577639e-25
DICPCG: Solving for p, Initial residual = 0.238853085434, Final residual = 7.52846140614e-11, No Iterations 212
time step continuity errors : sum local = 2.33840162539e-24, global = 2.67278696463e-25, cumulative = 1.2080132741e-24
FLUID 2
Segmentation fault


My main files is

Info<< "\nStarting time loop\n" << endl;

for (runTime++; !runTime.end(); runTime++)
{
Info<< "Time = " << runTime.timeName() << nl << endl;

# include "solveFluid1.H"
# include "solveFluid2.H"
# include "solveEnergy_whole.H"

runTime.write();

Info<< "ExecutionTime = "
<< runTime.elapsedCpuTime()
<< " s\n\n" << endl;

}


and for solveFluid2.H I have


Info<< "FLUID 2 "<< endl;

fvVectorMatrix UEqn2
(
fvm::ddt(U2)
+ fvm::div(phi2, U2)
- fvm::laplacian(nu, U2)
);


solve(UEqn2 == -fvc::grad(p2));

// --- PISO loop

for (int corr2 = 0; corr2 < nCorr; corr2++)
{
volScalarField rUA2 = 1.0/UEqn2.A();

U2 = rUA2*UEqn2.H();
phi2 = (fvc::interpolate(U2) & meshLiquid2.Sf())
+ fvc::ddtPhiCorr(rUA2, U2, phi2);

adjustPhi(phi2, U2, p2);

for (int nonOrth2 = 0; nonOrth2 <= nNonOrthCorr; nonOrth2++)
{
fvScalarMatrix pEqn2
(
fvm::laplacian(1.0/UEqn2.A(), p2) == fvc::div(phi2)
);

pEqn2.setReference(p2RefCell, p2RefValue);

pEqn2.solve();

if (nonOrth2 == nNonOrthCorr)
{
phi2 -= pEqn2.flux();
}
}

# include "continuityErrs.H"

U2 -= fvc::grad(p2)/UEqn2.A();
U2.correctBoundaryConditions();


}


I declare a field phi2 in createFields.H as

Info<< "Reading field phi2\n" << endl;
surfaceScalarField phi2
(
IOobject
(
"phi2",
runTime.timeName(),
meshLiquid2,
IOobject::NO_READ,
IOobject::NO_WRITE
),
phi
);


but clearly something is wrong when the code tried to solve the second fluid domain,

Is there any example or forum which could be useful?

Any help is welcome,

Thank you

Alberto

Originally Posted by srinath

Thanks Professor Jasak

What if the constitutive relations change for the 2 fluids on either side of the solid?
For example suppose there is supersonic flow, outside an engine and reactive multiphase flow inside the engine.

How would i modify the conjugate heat transfer solver for that?
I guess 'dt' determination is now a headache as there are 2 vastly different flow regimes, on either side of the solid.
I am just starting to learn OpenFoam and i thought that would be a good excercise for me to code and learn more.

Thanks
Srinath

[albem]

Hi Mike

Could you please uploaded the sample dictionary used to pull the data points out, again?, the link is not available !


Thanks

Alberto

Originally Posted by mike_jaworski

Hrv,
Thanks much for the quick response.

I was using the solver provided and the tutorial files as provided with only modification being mesh refinement. This could also be some artifact, maybe, of how the sample utility works?

I did the above analysis on the provided tutorial files (original mesh) and here's the graph:
https://netfiles.uiuc.edu/mjaworsk/s...OAM/course.png

I also sampled the DT field to check that one as well.

The discontinuity is more obvious which is why I went to mesh-refinement before posting anything.

However, when I checked the patch values using sampleSurface, they line up exactly. This is very confusing.

I've also uploaded the sample dictionary used to pull the data points out:
https://netfiles.uiuc.edu/mjaworsk/s...OAM/sampleDict

I'm, of course, open to every possibility that I'm using sample or the solver wrong, since I'm new to FOAM, it's about all I can do to try and keep up with much of this.

Also, I constructed a very simple case to look at pure conduction by setting the moving wall boundary condition to (0 0 0) velocity. Keeping all other constants from the original tutorial files the same, in theory, this should just be a straightline across the screen and there's some funny business, it seems, at the interface.

https://netfiles.uiuc.edu/mjaworsk/s...AM/conduct.png
Here's the paraFoam view of it and you can see the change in slope at the beginning and end of the paraview probes:
https://netfiles.uiuc.edu/mjaworsk/s...conduction.png

At the same time, however, if I fit a single line at the start of one region, it runs right through and provides the correct solution.

Thanks for the help,
Regards,
Mike J.