[Yongqiang66]

Dear Openfoam exporters,

I am confused about the Openfoam field creation. Just as the following script, when the volscalarfield is defined. Its name is declared as A. While in the IOobject, the file name is "B".

So in the case files, the "B" file is read into as the volscalarfield A? And in all the settings of fvscheme and fvsolution files, the variable is needed to set for A instead of B. Is it correct?

volScalarField A
(
IOobject
(
"B",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh
);

[crubio.abujas]

Originally Posted by Yongqiang66

Dear Openfoam exporters,

I am confused about the Openfoam field creation. Just as the following script, when the volscalarfield is defined. Its name is declared as A. While in the IOobject, the file name is "B".

So in the case files, the "B" file is read into as the volscalarfield A? And in all the settings of fvscheme and fvsolution files, the variable is needed to set for A instead of B. Is it correct?

volScalarField A
(
IOobject
(
"B",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh
);

Hi Yongqiang66,


There is a concept inside OpenFoam called register A register will store the reference of different objects, such a de volScalarField, with whatever name you assigned to it. In your particular example the name inside the register is B. In this case, the mesh is acting as a register.

The important thing to have in mind is that your volScalarField, the real data, is living in a particular memory address. The register knows how to link a particular label (B) to this memory space, so you can recall it whenever you like.

To avoid being calling the register multiple times you can store these address in a "variable". In your example "A". "A" knows where the data is (memory space) and how to deal with it (class type), so it has no need to call the register any further to manipulate this data. The fact is that the name of the variable is only important in your specific code, the name is not linked with the register label. It is just a convenient name for you to manipulate along the coding procedure. Once you finished, on the compiling process, this variable name will be vanished and substituted by the memory address.

Inside OpenFoam, other manipulation has to be done with their fields: accesing the data, reading, writing... and for that purpose it uses the register. So when you want to access that information from other program, what prevalence is the label assigned to the register, not the variable name. Inside your boundaryCondition, fvScheme of fvSolution you shall be using the register label (B) and never the variable name (A).

I hope that help you understanding what is going on.


Good luck!

[Yongqiang66]

Originally Posted by crubio.abujas

Hi Yongqiang66,


There is a concept inside OpenFoam called register A register will store the reference of different objects, such a de volScalarField, with whatever name you assigned to it. In your particular example the name inside the register is B. In this case, the mesh is acting as a register.

The important thing to have in mind is that your volScalarField, the real data, is living in a particular memory address. The register knows how to link a particular label (B) to this memory space, so you can recall it whenever you like.

To avoid being calling the register multiple times you can store these address in a "variable". In your example "A". "A" knows where the data is (memory space) and how to deal with it (class type), so it has no need to call the register any further to manipulate this data. The fact is that the name of the variable is only important in your specific code, the name is not linked with the register label. It is just a convenient name for you to manipulate along the coding procedure. Once you finished, on the compiling process, this variable name will be vanished and substituted by the memory address.

Inside OpenFoam, other manipulation has to be done with their fields: accesing the data, reading, writing... and for that purpose it uses the register. So when you want to access that information from other program, what prevalence is the label assigned to the register, not the variable name. Inside your boundaryCondition, fvScheme of fvSolution you shall be using the register label (B) and never the variable name (A).

I hope that help you understanding what is going on.


Good luck!

Hi Crubio,

Thank you very much. It is really helpful.
So during the programming of the solver, the variable name can be called. Here it is "A". "A" can be called in the equations.
While running the case, the register should be used. That refers to "B". The name of "B" needs to appear in fvscheme and fvsolution. Is it correct? I am not very confident about my understanding.

Best Regards,
Yongqiang

[crubio.abujas]

Originally Posted by Yongqiang66

So during the programming of the solver, the variable name can be called. Here it is "A". "A" can be called in the equations.

Yes, when you create a IOobject it also creates a reference of it in the register.

volScalarField A
    (
             IOobject
    (
        "B",  // This is label asigned to the object in the register.
                     runTime.timeName(),   // This is the place where the object will be saved 
                     mesh,  // This is the object which will act as register.
                     IOobject::NO_READ,  // Reading options (in case it founds a file named "B" do not read it")
                     IOobject::AUTO_WRITE // Writing options
    ),
    mesh  // This is used to "size" the field to mesh domain.
    );

The code is executed from inside to outside. So it first create the IOobject, and with that IOobject it will be asigned to a volScalarField object called A. So you use "A" to manage this scalarField inside the solver code.

Originally Posted by Yongqiang66

While running the case, the register should be used. That refers to "B". The name of "B" needs to appear in fvscheme and fvsolution. Is it correct?

Basically, yes. It is correct. In any other piece of code, there is no reference to the object "A" so in the code shall be some line like:

volScalarField& AA = mesh().lookupObject<volScalarField>("B");

Which basically tells to mesh (the register), "ey, give me the memory address of the volScalarField called 'B', I'll reference this address inside the variable AA".
So now I can access the same data, as register is referring to the same memory address, in a different code. Think as AA as an "alias" to this memory address. The name of this "alias" is only important inside the piece of code itself. Other codes can handle the same data, with different aliases.

Inside OF there are plenty of code files, some of them rely on the files you mentioned (fvScheme, fvSolution...). So it uses the register as a way to share this data accross the different parts.

I hope that makes it a little bit more clear.

[Yongqiang66]

Hi Crubio,

Thank you for the kind replies. It really helps. My code and cases can run successfully now. Very appreciate the help!

Regards,
Yongqiang