[lumpor]

Am I understanding the object registry right, in it being an inter-class database that can be accessed from any class with access to the mesh?


I'm trying to figure out how the viewFactor radiation model works.


1. viewFactor.C's Ru() and Rp() functions return IOobjects with value zero, meaning it gives no contribution to the energy equation radiation term. From what I understand, it instead calculates the boundary heat flux, qr_, for which it creates an IOobject "qr" for boundary condition equations to read.


But in viewFactor.calculate() it never changes qr_ (only relaxes it). Instead it changes the q and qrp fields, but these are not connected to any IOObject. So what does viewFactor actually do? How does it send the flux to the solvers?


2. In openfoam v2012, there's a library for modelling sunlight called solarLoad. It works as a standalone radiation model, but also, FvDOM and viewFactor radiation models are able to include it in their own modeling.


They create an instance of the solarLoad class called solarLoad_, and then call solarLoad.calculate() like so:

void Foam::radiation::viewFactor::calculate()
{
    // Store previous iteration
    qr_.storePrevIter();

    if (useSolarLoad_)
    {
        solarLoad_->calculate();
    }


...


}

solarLoad::calculate() changes the Ru_ variable inside the solarLoad object, like so:

Ru_[cellI] +=
                        (
                            reflectedFaces_->qreflective(bandI).
                                boundaryField()[patchID][i] * sf[i]
                        )/V[cellI];

But, how will the solver ever get access to this value?


solarLoad_.Ru() is never called from viewFactor. Does solarLoad_.calculate() store it in the "Ru" IOObject in the object registry? But when viewFactor.Ru() is called, it returns a new "Ru" IOObject with value zero. Won't that overwrite the old value?


3.
If I have a variable T_, assigned by T_(IOObject("T", ...)) and then change T_ (for example, by adding 5 to it), will that change automatically register in the Object registry? Because that seems to be the only way solarLoad_ calculate (called from viewFactor.C or FvDOM.C) could have any effect on the radiation term.


Thanks!


Edit:
Looking further into solarLoad.C, I see more examples of variables that are only ever assigned values, but never read. For example, qrBf. It's modified in solarLoad.C multiple times, but never read. It isn't read in ratiationModel.C either, however it is read in viewFactor.C. But they should still be in different scopes, no? Since viewFactor.C creates a pointer to a solarLoad object instead of including the file directly.

[Mirza8]

Hi Fabian,

1- I think you are right about the object registry.
About your first question, you are right Ru() and Rp() are zero in viewFactor model, so the source term in EEqn will be zero. It makes sense, because in veiw factor model, we are not solving any equation inside the domain, but we can only estimate the radiative heat flux at the boundaries.

In the veiwFactor.C file, the qrBf is defined as a reference to the boundary field of qr_ with the following code:

volScalarField::Boundary& qrBf = qr_.boundaryFieldRef();

So whenever you change the qrBf value, you are in fact changing the qr_ boundary field values. And the solvers have access to the qr_ field and its boundary values. To find an example of how solvers can use this boundary value, you can first take a look at the multiRegionHeaterRadiation tutorial case (I am using OF6, and it might be a little different in other versions). Go to 0/bottomAir and check the G and qr fields to find what boundaries are used for these two fields. Finally in the 0/bottomAir/T you can find out how the qr field is related to the boundary condition of temperature (which will be used in EEqn.H):

"bottomAir_to_.*"
    {
        type            compressible::turbulentTemperatureRadCoupledMixed;
        value           $internalField;
        Tnbr            T;
        kappaMethod     fluidThermo;
        qrNbr           none;
        qr              qr;
    }

In the code above, we set the name of the qr field (which is "qr" here) and when the solver solves the EEqn.H and updates the temperature boundary condition, looks for a volScalarField named "qr" in the object registry and uses that. You can read the code of "turbulentTemperatureRadCoupledMixed" boundary condition to find how qr is used in this specific BC.

2- You can take a look at the radiationModel.C and radiationModel.H to find your answer. The solvers (e.g. chtMultiRegionFoam) use radiationModel::Sh() in the EEqn.H. viewFactor class is derived from radiationModel class and inherits all of its functions, including Sh() function. The Ru() and Rp() are used in the Sh() function to calculate the source term.

3- I think if you change the volScalarField T, it automatically updates its value in object registry. But I believe none of the radiation models would directly change the T field! They can only affect the solution either through the source term in EEqn or through the boundary conditions as mentioned above.

I hope this answers your questions.
Best regards,
Morteza

[lumpor]

Hi Morteza,



Thanks for your answers, I understand the object registry and viewFactor better now, I didn't realize what boundaryFieldRef() did.



There is however something unclear to me regarding question 2. Like you said, the solver calls the radiationModel::Sh() function, which viewFactor inherited from radiationModel. The Sh() function then calls on the Ru() function (and the Rp() function), which should refer to its own functions (since there is no solarLoad:: before the call or anything like that).


Since viewFactor::Ru() looks like this:

Foam::tmp<Foam::DimensionedField<Foam::scalar, Foam::volMesh>>
Foam::radiation::viewFactor::Ru() const
{
    return tmp<DimensionedField<scalar, volMesh>>::New
    (
        IOobject
        (
            "Ru",
            mesh_.time().timeName(),
            mesh_,
            IOobject::NO_READ,
            IOobject::NO_WRITE,
            false
        ),
        mesh_,
        dimensionedScalar(dimMass/dimLength/pow3(dimTime), Zero)
    );
}

Won't it mean that whatever Ru value existed previously is overwritten? It seems like the solarLoad value will be ignored.


Edit: Nevermind, I think I connected the dots. solarLoad has the branch

if (includeMappedPatchBasePatches[patchID])

Where it either adds its contribution to qrBf or Ru. I suspect that when viewFactor includes the solarLoad model it ignores the Ru components and only cares about the qr contribution from solarLoad, while solarLoad's contribution to Ru is only used when solarLoad is the main radiation model.