[DanAndrea87]

Hi,

I'm trying to change the thermal conductivity and heat capacity in a solid region, depending on position. I've already create the file Kappa and Cp in the 0/solid directory with the command:

setFields -region solid

Now I'm changing the solver.
The first idea was to simply import these quantities, with this code, in the createSolidFields.H file

KappaSolid.set
(
    i,
    new volScalarField
    (
        IOobject
        (
            "Kappa",
            runTime.timeName(),
            solidRegions[i],
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        ),
        solidRegions[i]
    )
);

And it works for the solid, but there is a problem in coupling with fluid region.
The problem is that the coupling fvPatch read the solid thermal conductivity from thermo.kappa().
So now my goal is to replace the thermo.kappa() with the readed values, directly in the file createSolidFields.H.
I've tried booth these codes, without results:

KappaSolid.set
(
    i,
    new volScalarField
    (
        IOobject
        (
            "Kappa",
            runTime.timeName(),
            solidRegions[i],
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        ),
        solidRegions[i]
    )
);
thermos[i].kappa() = KappaSolid[i];

thermos[i].kappa() = IOdictionary
(
    IOobject
    (
        "Kappa",
        runTime.timeName(),
        solidRegions[i],
        IOobject::MUST_READ,
        IOobject::AUTO_WRITE
    )
);

Any ideas?
Thanks for the help

[tomislav_maric]

Which solver and which OF version are you using?

[DanAndrea87]

Thanks for reply!
I'm using OF-2.2.1 and the solver is a modified version of chtMultiregionFoam (see attachment).

[tomislav_maric]

I have zero experience with multiregion coupling, but I'll give you a few hints code-wise.

For a start, this line:

 PtrList<solidThermo> thermos(solidRegions.size());

States that 'thermos' is a list of pointers to 'solidThermo' objects. When you try to do this:

//    thermos[i].kappa() = KappaSolid[i];

you are assigning a volumeScalarField to a temporary object. The 'kappa' member function comes inherited from the 'basicThermo' class:

                        virtual tmp<volScalarField> kappa() const = 0;

And you can see here that the implementation of this pure virtual member function will return a temporary volScalarField. As a result, your expression has no effect.

What is it you are trying to do actually? Providing more background on the actual idea would make it easier for someone to help you...

[DanAndrea87]

Well, the idea was to replace the volScalarField in kappa with the volScalarField readed from the IOobject.
But, if I've well understood, kappa is not a volScalarField. The volScalarField is generated every time the member function kappa() is called.
Is it right?
Thanks for the help.

[tomislav_maric]

The 'kappa()' member function generates a temporary volume scalar field.

If you are searching for a way to set such a field for an object of the 'solidThermo' class, you can easily find out if the class stores such a field:

class solidThermo
:
    public basicThermo
{

protected:

    // Protected data

        //- Density field [kg/m^3]
        //  Named 'rhoThermo' to avoid (potential) conflict with solver density
        volScalarField rho_;

or if it's parent class 'basicThermo' stores it:

class basicThermo
:
    public IOdictionary
{

protected:

    // Protected data

        //- Phase-name
        const word& phaseName_;


        // Fields

            //- Pressure [Pa]
            volScalarField& p_;

            //- Temperature [K]
            volScalarField T_;

            //- Laminar thermal diffusuvity [kg/m/s]
            volScalarField alpha_; // This might be your candidate right here.

And then you can extend the solidThermo by deriving from it and provide a public member function that modifies such a field - if it exists. If not and you need that - derive from solidThermo, add the field you want to modify and the member function that does the modification.

One thing though - looking at 'createSolidFields.H', I have noticed that the solidThermo objects are set by constructing new objects using run-time selection:

        Info<< "    Adding to thermos\n" << endl;
        thermos.set(i, solidThermo::New(solidRegions[i]));

The 'New' selector is defined in 'basicThermoTemplates.C':

template<class Thermo>
Foam::autoPtr<Thermo> Foam::basicThermo::New
(
    const fvMesh& mesh,
    const word& phaseName
)
{
    IOdictionary thermoDict
    (
        IOobject
        (
            phasePropertyName(dictName, phaseName),
            mesh.time().constant(),
            mesh,
            IOobject::MUST_READ_IF_MODIFIED,
            IOobject::NO_WRITE,
            false
        )
    );

    typename Thermo::fvMeshConstructorTable::iterator cstrIter =
        lookupThermo<Thermo, typename Thermo::fvMeshConstructorTable>
        (
            thermoDict,
            Thermo::fvMeshConstructorTablePtr_
        );

    return autoPtr<Thermo>(cstrIter()(mesh, phaseName));
}

And it seems to read a dictionary (as usual) and select the object.

So the next question is: why are you trying to do the object modification afterwards, using the volume fields, when this is not done in the original solver?

Your answer:

Well, the idea was to replace the volScalarField in kappa with the volScalarField readed from the IOobject.

does not help me understand what you are trying to do - it doesn't explain what you are trying to do conceptually. Your explanation already describes the way you have decided to implement your idea. What is the actual idea, what are you trying to achieve? Explain it without using class names.

[DanAndrea87]

Ok, i will try to explain better: the problem is in the coupling between solid and fluids regions. In particular the coupling boundary condition (compressible::turbulentTemperatureCoupledBaffleMix ed) takes into account the conservation of heat flux between patches as follow:

kappa_fluid*d(T_fluid)/dn = kappa_solid*d(T_solid)/dn

where n is the vector normal to the contact surface.
The problem is that kappa_solid is taken form the thermophysicalProperties file in constant/solid (in which the thermal conductivity is a constant for the whole solid), while I need to use the value taken from the IOobject (because my solid has different thermal conductivity, depending on position).
At this point, probably, it's more convenient to modify the fvPatchScalarField library...

[tomislav_maric]

Originally Posted by DanAndrea87

In particular the coupling boundary condition (compressible::turbulentTemperatureCoupledBaffleMix ed) takes into account the conservation of heat flux between patches as follow:

kappa_fluid*d(T_fluid)/dn = kappa_solid*d(T_solid)/dn

where n is the vector normal to the contact surface.

The problem is that kappa_solid is taken form the thermophysicalProperties file in constant/solid (in which the thermal conductivity is a constant for the whole solid)...

(because my solid has different thermal conductivity, depending on position).

...

Thank you for describing the problem on the conceptual level.

I'll describe how I would approach this problem. Beware, I'm using pseudocode to describe the idea, the code below is not something you should copy and paste + compile.

I would suggest you to think about first implementing a heat conduction model that computes thermal conducitivity depending on position.

When you do that properly, the model will be run-time selectable.

Make sure that the selection of the conductivity model is dictionary based.

Extend the turbulentTemperatureCoupledBaffleMixed boundary condition into a BC that makes use of a modeled thermal conductivity and not a constant. Make the BC contain the model and select it during run-time. Make the 'updateCoeffs' delegate the conductivity calculation to the model : constant or variable, depending on the sub-dict entry.

The dictionary entry of your new ('turbulentTemperatureCoupledeBaffleMixedModel') boundary condition should contain a sub-dictionary

turbulentTemperatureHowEverYouNameYourBc
{
    conductivityModels {
        solid  spatiallyVariable someFunctionName; 
        fluid  constant 0.007;
     } 
    // Whatever other parameters go with the original BC.
}

This way, you don't have to touch the original solver at all.

Your new model will be contained within your new BC class (depending on the OF smart pointer you decide on for the run-time selection):

class turbulentTemperatureBlah
{
    private:
        autoPtr<spatiallyVariableThermalConductivityModel> modelPtr_;

    public: 
        turbulentTemperatureBlah(IOobject const & io)
        :
            modelPtr_ = transportModel::New(io.subdict(" .... 
};

So, in the end, you have a new BC that replaced the line:

    kappa_fluid*d(T_fluid)/dn = kappa_solid*d(T_solid)/dn

with something like:

     modelPtr->kappa_fluid()*d(T_fluid)/dn = modelPtr->kappa_solid()*d(T_solid)/dn

And the 'kappa_fluid' and 'kappa_solid' can be either constants (if you select a 'constant' model) or variable values - in whatever way you want to vary them - you just write a new variable model.

Note: No solver application is touched, and you have a small library that you can share with anyone that is using OF.

You'll have to understand RTS in OF to do this, there is a great page about that in the OF Wiki.

[DanAndrea87]

Thanks for the help and sorry for the late I answer you.
This way seems to be easier than modifying the thermophysical model, and your explanation was very clear.
I will try to make it on next week. I will write again in case of problems
Thanks again

[tomislav_maric]

Np, glad to be of help! Good luck with the work!