[romain.h]

Originally Posted by m_f

...

You're totally right... I will begin to learn how create a solver.

You should probably start with this topic : http://www.cfd-online.com/Forums/ope...egionfoam.html as someone did already worked on an incompressible version of chtMultiRegionFoam.

Romain

[mirx]

Hello,

did anyone of you successfully run chtMultiRegion(Simple)FoamTensorK? I tried it and the simulation runs properly, but the results are not as expected.

I used different KValues. I thought the vector would represent conductivity values in x, y and z. But they don't. It seems more like a polar definition rather than a cartesian. Furthermore I am not able to change the orientation. Changing the values of coordinateSystem doesn't effect the results. It seems not to be recognized by the solver, as spelling mistakes don't raise error.

Thank you in advance!

[richpaj]

I encountered the same problems as mirx. Am wondering whether to attempt my own customized definition for the relevant field of tensorial K.

Rgds,

Richard K.

[mirx]

Hello,

do you think the problem is only related to the definition of tensor K in solidThermophysicalProperties? Would we get the expected behaviour, if tensor K was defined properly?
How the tensor has to look like, so that we are able to define the conductivity in x-/y-/z-direction and is it possible to define the tensor somewhere else?
Richard, do know, how to implement this into the solver?

Regards

[richpaj]

I've only just encountered the problem today so haven't had much time to think about it. But for sure it would make use of the interpolation approach currently employed in directionalKSolidThermo and related classes.

At the bug report site it seems they might overhaul the approach in any case in the next upgrade to openFOAM.

Regards,

Richard K.

[richpaj]

I just realised that I was using an old version of OF21, it's quite possible that this procedure is updated in later versions of OF21x

[richpaj]

seems to be working now, though have yet to satisfy myself with the output.
Good luck

Richard K.

[mirx]

Do you mean it works with the newest version 2.1.x from git?

[richpaj]

certainly from early November. So yes the latest git will provide a fix for you.

[mirx]

Today I compiled the new git version 2.1.x and recompiled chtMultiRegionSimpleFoamTensorK but it doesn't change anything. I still get the same unexpected results as described in post #22 of this thread.
coordinateSystem is ignored and KValues don't behave like in a cartesian x, y, z definition.

Richard, do you get good results with chtMultiRegion(Simple)FoamTensorK?

[richpaj]

I seem to get what I expect. For example in solidThermophysicalProperties if I use

{
..
KValues ( (4 10 25) (4 10 25) );

coordinateSystem
{
origin (0 0 0);
//
coordinateRotation
{
type axes;
e1 (1 0 0);
e3 (0 0 1);
}
}
}

Inserting an Info statement into the code now yields

(4 0 0 10 0 25) which agrees with the format


( "xx", "xy", "xz", "yy", "yz", "zz" )

as specified in "/src/OpenFOAM/primitives/SymmTensor/symmTensor/symmTensor.C". Previously, a "..not isotropic tensor" error would be emitted at this stage.

I must admit, however, I haven't tried alternative alignments as our geometry is already aligned
to the above. Presumably you're having trouble interacting with the 'coordinateSystem'
in the above subdictionary?

Rgds,

Richard

[mirx]

Where in the code did you insert the info statement?

[richpaj]

I put the following in "setRegionSolidFields.H"

Info<<"setRegionSolidFields.H:: kappa = "<<kappa<<endl;

after:

//tmp<volScalarField> tkappa = thermo.K();
tmp<volSymmTensorField> tkappa = thermo.directionalK();

//const volScalarField& kappa = tkappa();
const volSymmTensorField& kappa = tkappa();

Rgds,

Richard

[mirx]

Thank you very much!
It seems that my tensor is not calculated correctly.

I have the following dict:

KValues ((10 100 10) (10 100 10));

coordinateSystem
{
origin ( 0 0 0);
coordinateRotation
{
type axes;
e1 (1 0 0);
e3 (0 0 1);
}
}

But my tensor field looks like this:
...
(22.4138 31.03449 0 87.5862 0 10)
(63.11475 44.2623 0 46.88525 0 10)
(63.11475 -44.2623 0 46.88525 0 10)
(22.4138 -31.03449 0 87.5862 0 10)
(22.4138 31.03449 0 87.5862 0 10)
...

The *z-values are correct. Everything else is messed up.

This simulation was run with the latest git 2.1.x, chtMultiRegionFoamTensorK_v2 and multiRegionHeaterDirectionalSolid. I just changed the solidThermophysicalProperties.

[richpaj]

Actually I never used "chtMultiRegionFoamTensorK_v2", I just edited the original OF solver and renamed it "myChtMultiRegionDirectionalKsimpleFoam".

I wonder if that might account for the different in behaviours we're observing?

[mirx]

Now I used my newly under ubuntu 12.04 compiled git version 2.1.x., copied the original solver and changed the two lines in setRegionSolidFields.h:

//tmp<volScalarField> tkappa = thermo.K();
tmp<volSymmTensorField> tkappa = thermo.directionalK();

//const volScalarField& kappa = tkappa();
const volSymmTensorField& kappa = tkappa();

Then I compiled this new solver as myChtMultiRegionDirectionalKSimpleFoam. But I still get the same results. I'm absolutely puzzled. If I use the same KValues for x/y/z, i.e. (10 10 10), then the tensor is (10 0 0 10 0 10). But if I have different values, it calculates a completely wrong tensor (except for z-component). coordinateSystem values are still not recognized. Maybe this is related to my problem. Did I miss something in the solver code?

[richpaj]

What about your boundary condition I wonder? I use


Solid4_to_Solid5
{
type compressible::turbulentTemperatureCoupledBaffleMix ed;
value uniform 300;
neighbourFieldName T;
K directionalSolidThermo;
KName none;
}

and if that looks fine what about the cood system of the mesh?

Otherwise, it looks like you'll have to track the bug in the class library directionalKSolidThermo.

I should add that my test case was 2D cylindrically symmetric.

Regards,

Richard K.

[mirx]

My boundary conditions are the same and I never touched settings for the global coordinate system.
Could it be possible, that you didn't notice this problem because of your 2D setup? If you had some time, I would be grateful if you could run a simple 3D case with your solver. In this thread is a modified version of multiRegionHeater tutorial (post #12). I guess, you just have to modifiy the solver in controlDict to let it run and use some anisotropic values as KValues.

Regards

Michael

[richpaj]

I tried ((10 20 30) (10 20 30)) for the heater and generated:
92
(
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(19.28367 -2.578796 0 10.71633 0 30)
(19.91499 -0.9180551 0 10.08501 0 30)
(19.91499 0.9180551 0 10.08501 0 30)
(19.28367 2.578796 0 10.71633 0 30)
..

(15.90164 4.918033 0 14.09836 0 30)
(10.82569 2.752294 0 19.17431 0 30)
(11.37931 3.448276 0 18.62069 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
(10 0 0 20 0 30)
)

presumably, the principal values are being transformed in regions of this mesh. I think
you'll have to track through the directionalK.. class library to see the details of this.

I'll probably be revisiting this problem in the next couple of weeks but have to now
move onto something completely different.

In the meantimes, good luck,

Richard K.

[mirx]

Hello,

I think I found the answer to our problem. I had a look at directionalKSolidThermo.C and debuged it with info statements. I recognized, that the definition of coordinateSystem for the cells and patches is very strange. They all get a local coordinate system that points to the origin of the defined global coordinate system. This results in a sphirical definition of KValues.
Another problem is that the functions, which should read the coordinateSystem values out of thermoPhysicalProperties dict, are not used. That's why directionalKSolidThermo ignores the coordinateSystem definition and always uses the default coordinateSystem.

I was able to fix these issues as follows:
(This fix is only tested with versions 2.1.1 and 2.1.x)

In directionalKSolidThermo.C in member function Foam::directionalKSolidThermo::init() (line 135)

Remove

KValues_ = Field<vector>(subDict(typeName + "Coeffs").lookup("KValues"));

and replace it with

read();

This function reads the dict values KValues AND coordinateSystem.

Than in the forAll(mesh_.C(), cellI) loop remove

vector dir = mesh_.C()[cellI] - coordSys_.origin();
dir /= mag(dir);

and replace the coordinate system definition so that it looks like this:

        coordinateSystem cs
        (
            "cc",
                coordSys_.origin(),
                coordSys_.e3(), 
                coordSys_.e1() 
        );

Than in forAll(mesh_.C().boundaryField(), patchI) in forAll(tc, i) remove

            vector dir = patchC[i] - coordSys_.origin();
            dir /= mag(dir);

and again change the coordinate system definition to

        coordinateSystem cs
        (
            "cc",
                coordSys_.origin(),
                coordSys_.e3(), 
                coordSys_.e1() 
        );

I attached the modified file directionalKSolidThermo.C to this post.