[olesen]

Originally Posted by nimasam

i used following steps:

1) add to main solver
#include "scalarIOList.H" //add

2) add to creatFields.H

scalarIOList jump
(
IOobject(
"jump",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::NO_WRITE
),
label(1.0));

3) update

jump[0] = myvalue;

4) in boundary condition i add :

const scalarIOList& jump =
db().lookupObject<scalarIOList>("jump");

but i faced following strange!!!!! error

lookup of jump from objectRegistry region0 successful
but it is not a scalarList, it is a scalarList ???????????

From function objectRegistry::lookupObject<Type>(const word&) const
in file ...../OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 121.

Generally doesn't look too bad. Do you still get complaints with this type of code?

 
const scalarList& jump = db().lookupObject<scalarList>("jump");
Info<< "jump = " << jump[0] << endl;

Also note there is no reason to use a float and cast it in the constructor. Just use a label (which is more-or-less an int) directly:

// create a list of size 1
scalarIOList jump
(
    IOobject
    (
        "jump",
        runTime.timeName(),
        mesh
    ),
    1
);

[nimasam]

hi
i used ur command

const scalarList& jump = db().lookupObject<scalarList>("jump");
Info<< "jump = " << jump[0] << endl;

but i received following errors:

/home/sam/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C: In member function ‘const Type& Foam:bjectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::List<double>]’:
heatFanFvPatchFields.C:55: instantiated from here
/home/sam/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C:121: error: ‘typeName’ is not a member of ‘Foam::List<double>’
heatFanFvPatchFields.C:55: instantiated from here
/home/sam/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C:137: error: ‘typeName’ is not a member of ‘Foam::List<double>’
/home/sam/OpenFOAM/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude/objectRegistryTemplates.C:137: error: ‘typeName’ is not a member of ‘Foam::List<double>’

[olesen]

With this bit of code I have no errors:

#include "argList.H"
#include "Time.H"
#include "scalarIOList.H"
using namespace Foam;
void dolookup(const objectRegistry& db)
{
    const scalarIOList& jump = db.lookupObject<scalarIOList>("jump");
    Info<<"jump => " << jump << endl;
}
 
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
int main(int argc, char *argv[])
{
#   include "setRootCase.H"
#   include "createTime.H"
    scalarIOList jump
    (
        IOobject
        (
            "jump",
            runTime.timeName(),
            runTime
        ),
        2
    );
    jump[0] = 3.14;
    jump[1] = 10.5;
    dolookup(runTime);
    Info<< "end" << endl;
}

This looks similar to what you had before, I don't know how/why you ran into problems with your first attempt.

[nimasam]

however i could not rid of it! i liked to have a neat code but it seems some times you need to be dirty
i used an inefficient method! i used volScalarField! instead of IOscalarList! then i read just one array of volScalarField in BC

[marupio]

I've created a now IO object that makes this process simpler. See my post:

http://www.cfd-online.com/Forums/ope...tml#post319949

Share and enjoy!

[Katl]

I tried to use the work-around described above, but I get the following error:

"abflussWehrUS.C: In member function ‘virtual void Foam::abflussWehrUS::updateCoeffs()’:
abflussWehrUS.C:201: error: passing ‘const Foam::IOdictionary’ as ‘this’ argument of ‘void Foam::dictionary::set(const Foam::word&, const T&) [with T = int]’ discards qualifiers
make: *** [Make/linux64GccDPOpt/abflussWehrUS.o] Fehler 1"

for the code:
200 const IOdictionary& sonderBw = db().lookupObject<IOdictionary>("sonderBw");
201 sonderBw.set("sonderBwUS", sonderBwUS);

[marupio]

If you do a lookup through the object registry you only get a const reference. It doesn't let you change anything. It looks like you are looking up an IOdictionary and trying to use .set(), which changes it.

[Katl]

ok. thanks. seems obvious now.

I also tried your IOReferencer, but got these errors:

/home/h17_2/student2/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude/IOReferencer.C:31: error: expected primary-expression before ‘template’
/home/h17_2/student2/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude/IOReferencer.C:31: error: expected `;' before ‘template’

[marupio]

The error basically says: "there's a problem *just before* you include IOreferencer".

[JBUNSW]

I have read all the posts in this thread, but none of them address my problem.

Originally Posted by marupio

If you do a lookup through the object registry you only get a const reference. It doesn't let you change anything. It looks like you are looking up an IOdictionary and trying to use .set(), which changes it.

What if I need to change the value of the object?!
First I have to familiarise you with my problem:
I am developing a thermophysical model in which I need to update M scalarFields of size N in every iteration of my solver loop. For convenience, I have packed these scalarFields into a PtrList Qi in this way:

PtrList<scalarField> Qi(M);
for (label k = 0; k < M; k++)
{
    Qi.set
    (
        k,
        new scalarField(N, 0.0)
    );
}

Then I fill it up with their initial values which themselves depend on some parameters I read from a dictionary, viz.

for (label k = 0; k < M; k++)
{
    some code here ...
    for (label j = 0; j < N; j++)
    {
        Qi[k][j] = some code here;
    }
}

I extract N and M from an external dictionary on hard disk. These Qi's will represent my input for the first time step, i.e. the first iteration of the solver's loop. Then inside the thermophysical library I am developing, I will update Qi's with their new values based on their values I have from previous iteration. I have put all these initialisation commands in an H file (createMyFields.H) and included this file after "main" keyword of my solver.

To ring the bell in your head, I can say that this is very similar to what we usually do for flow variables such as velocity or pressure in the H file "createFields.H" in conventional solvers such as dieselFoam or icoFoam. The only difference is that for such traditional variables, we add them to the objectRegistry of OpenFOAM as volScalarFields via an IOobject command which initialises these variables from hard disk and stores them on the mesh which will be accessible, later on, in the library codes via the bojectRegistry pool. This means they are conveniently accessible in the libraries you develop, not only for reading, but also for modifying, just by invoking their name, i.e. p or U.

My problem, furthermore, is that my variables, unlike p or U, are not stored on the mesh. Their size is N which is not equal to the number of cells in the mesh. So I can not store them using conventional IOobject command which is mesh dependent. Also, if I declare them in the library functions scope, every time the corresponding function from library, that is responsible for updating Qi's, is invoked from the solver, the values from previous iteration will be reset to zero and lost. So I can not update them based on their previous values from previous iteration.

Therefore, I took refuge to the solutions David and Mark suggested. I haven't tried Mark's solution, to be honest, because it is a bit difficult to be extended to the ptrLists. However, I did try David's IOReferencer solution. I could not get beyond the compilation step of my solver which is a customised version of dieselFoam. To sum it up I included the following H file at the beginning of my solver:

#include "IOReferencer.H"

some code here to extract M and N and some other parameters from a dictionary file on hard disk

PtrList<scalarField> Qi(M);
 for (label k = 0; k < M; k++)
 {
     Qi.set
     (
         k,
         new scalarField(N, 0.0)
     );
 }
 
for (label k = 0; k < M; k++)
 {
     some code here ...
     for (label j = 0; j < N; j++)
     {
         Qi[k][j] = some code here;
     }
 }

IOReferencer<PtrList<scalarField>> myObjectRef
    (
        IOobject
            (
                "QiJalal",
                runTime.constant(), // can be anything
                runTime,            // can be anything
                IOobject::NO_READ,  // can be anything
                IOobject::NO_WRITE  // must be NO_WRITE
            ),
        Qi
    );

Upon issuing wmake command to compile the solver, I get some strange errors which I relate to that #include preprocessor at the beginning, because when I comment the lines corresponding to IOReferencer, I get no error and my code will run and has no bugs:

FOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/jbDieselFoam.o
In file included from createMyFields.H:1,
from jbDieselFoam.C:64:
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.H: In function ‘int main(int, char**)’:
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.H:79: error: ‘namespace’ definition is not allowed here
In file included from /home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.H:137,
from createMyFields.H:1,
from jbDieselFoam.C:64:
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.C:31: error: expected primary-expression before ‘template’
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.C:31: error: expected ‘;’ before ‘template’
createFields.H:51: warning: unused variable ‘psi’
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude/initContinuityErrs.H:37: warning: unused variable ‘cumulativeContErr’
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude/readTimeControls.H:38: warning: unused variable ‘maxDeltaT’
jbDieselFoam.C:179: error: expected ‘}’ at end of input
make: *** [Make/linux64GccDPOpt/jbDieselFoam.o] Error 1

As you can see, some of errors are completely out of question and strange! Here's my questions:

1. Am I doing anything wrong in using this IOReferencer?
2. If I could fix this problem, is there a way to use IOReferencer with a non-constant reference to my variables Qi? Because I need to update them inside the objectRegistry pool when my thermophysical model library is invoked in every iteration.
3. Is there any other solution to my problem?

I would be truly grateful if anyone could help me out of this predicament.

[marupio]

Originally Posted by JBUNSW

What if I need to change the value of the object?!

Don't you make that face at me...

An object created at the top level (i.e. createFields.H, or in main) cannot be changed from within a library without some special accommodations. Either you can change it at the top level, or you can change it in the library, but not both. To do both, you need to get a little fancy. You need to pass a non-const reference to your instantiated library object somehow, or pass a reference back from the library object to the solver.

Originally Posted by JBUNSW

First I have to familiarise you with my problem:
I am developing a thermophysical model in which I need to update M scalarFields of size N in every iteration of my solver loop.

How custom is this thermophysical model? If you are building your own framework, you can have a reference to your scalarFields as a constructor parameter... if you are working within an existing framework... this may not be possible.

Originally Posted by JBUNSW

Then I fill it up with their initial values which themselves depend on some parameters I read from a dictionary, viz.

You are initializing these fields with every iteration? Would it be possible to move all that initialization into your library? That way the solver never needs to change it, and you can simply give the data to your custom thermophysical class. This would solve all your problems, if it was possible.

Originally Posted by JBUNSW

To ring the bell in your head, I can say that this is very similar to what we usually do for flow variables such as velocity or pressure in the H file "createFields.H"... This means they are conveniently accessible in the libraries you develop, not only for reading, but also for modifying, just by invoking their name, i.e. p or U.

They can't actually change any object they lookup in the registry. Boundary conditions can change their field values because a non-const reference is built directly into the construction.

Originally Posted by JBUNSW

My problem, furthermore, is that my variables, unlike p or U, are not stored on the mesh. Their size is N which is not equal to the number of cells in the mesh. So I can not store them using conventional IOobject command which is mesh dependent.

IOobject does not depend on the mesh. An IOobject needs a parent objectRegistry, but this can be runTime or mesh. The fact that you associate it with the mesh does not mean it must have the same size as the mesh. There are several IOobjects you could look into using, such as IOList, IOField, or any object that inherit these.

Originally Posted by JBUNSW

Also, if I declare them in the library functions scope, every time the corresponding function from library, that is responsible for updating Qi's, is invoked from the solver, the values from previous iteration will be reset to zero and lost.

Don't declare them within the functions... declare them as a member variable of your custom library class. That is in the .H file. Build them in the constructor, and only use them in the function.

Originally Posted by JBUNSW

However, I did try David's IOReferencer solution. I could not get beyond the compilation step of my solver which is a customised version of dieselFoam. To sum it up I included the following H file at the beginning of my solver...

In file included from createMyFields.H:1,
from jbDieselFoam.C:64:
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.H: In function ‘int main(int, char**)’:
/home/jalal/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/IOReferencer.H:79: error: ‘namespace’ definition is not allowed here

The #include "IOReferencer.H" should go with the rest of the header includes, before "int main" in your solver, or before "class" in your custom library header file, depending on where you intend to use it. #includes appearing after "int main" are frequently used code snippets.

But as I said before, IOReferencer won't give you a non-const reference.

I hope this gives you some insights!

-Dave

[JBUNSW]

Thanks David for your meticulous reply. I will try your fruitful recommendations and post back the outcome here accordingly.

[JBUNSW]

Originally Posted by JBUNSW

Thanks David for your meticulous reply. I will try your fruitful recommendations and post back the outcome here accordingly.

First of all, my sincere thanks goes to David who his post above provided me with a deep insight to find the following solution for my problem. So hereby, I pay back to the community of Foamers:

As David said, his IOReferencer solution does not provide non-const access to the object. To have a PtrList (or any other object type) that is modifiable in both solver and library scope, I declared my PtrList in the base class of my library. I did so because I had the access to an object of this class's derived class in the solver domain. So this bridged the gap between solver and library. I declared the PtrList as a protected data member of the base class. Then I included a public inline function that returns a non-const reference to this protected data member of the base class. I could not initialise this PtrList in the .C file of the base class, because the size of the PtrList was dependent on a variable that was not accessible at this basic scope.

So I created a custom createMyFields.H macro and included it at the top of my solver at a point where I am safely sure that the bridge I told you has been successfully established. Then I read my custom dictionary file in and initialised the PtrList.

Afterwards, the subsequent future values of the PtrList is updated inside my thermoPhysical model inside the library. In this way, I could update the values of the PtrList inside my library source code at each iteration without losing the values from previous iteration. Furthermore, I could initialise my variable in the solver scope from values extracted from my costum dictionary file. Note that the size of my arrays were not the same as the mesh. So I could not use the conventional volScalarFields solution.

Thanks again to David...

[Arnoldinho]

Hi there,

I am right now facing a similar problem as discussed: I have a variable (stored in a volScalarField) that is calculated within a modified kOmegaSST turbulence model from other quantities in the turb. model. At each time step in the calculation I'd no like to get the value of that variable in my custom flow solver (modified interDyMFoam). The variable is read only there, so modification just takes place in the turbulence model!

Unfortunately I'm not familiar with object registry, so could someone give me a hint on how to implement this? I tried it in the way described above, but without success - maybe because it is described the way round...

Thanks in advance,
Arne

[Arnoldinho]

Ok, I played a bit around and I think I already got a solution:

In kOmegaSSTx.H (in the public section):

volScalarField wallStress_;

In kOmegaSSTx.C (in the constructor):

wallStress_
(
    IOobject
    (
        "wallStress_",
        runTime_.timeName(),
        mesh_,
        IOobject::NO_READ,
        IOobject::NO_WRITE
    ),
    mesh_,
    dimensionedScalar ("wallStress_", dimensionSet(0, 2, -2, 0, 0, 0, 0), scalar(1e-10))
),

The wallStress_ field is then modified within the turbulence model.
In the solver (in main loop), I made an entry of

volScalarField wallStress2 = U.db().lookupObject<volScalarField>("wallStress_");

At least from comparison of entry values, wallStress_ seems to be correctly called.
Can someone confirm if the implementation above is right?

Greetings,
Arne

[JBUNSW]

Hi Arne,

Sorry for late reply. Was on a vacation...

Yes, you are almost right. The only thing that you have to take into account carefully is that with the current commands you reported here, two things happen:

1. The volscalarField wallStress_ is created in the komega class scope for internal calculations purposes. Since you have used NO_READ and NO_WRITE flags.

2. Then by this,

Originally Posted by Arnoldinho

The wallStress_ field is then modified within the turbulence model.
In the solver (in main loop), I made an entry of

volScalarField wallStress2 = U.db().lookupObject<volScalarField>("wallStress_");

you are creating a duplicate of the original wallStress_ in the solver scope. I don't like duplicates, because it's just a waste of memory resources. This volscalarField, anyway, is initialised by the values from the original wallStrees_, but any further changes you make to it in the solver domain will not be reflected in the version at komega class scope.

If you didn't want them to be the same thing, then it's ok.

But if you want them to refer to a common memory address, then you have to modify your piece of code in the solver to the below:

volScalarField& wallStress2 = U.db().lookupObject<volScalarField>("wallStress_");

This means whatever change you make to the wallStress2 in the solver scope will be "referred" to the original wallStress_ volscalarField in the komega class scope.

Cheers,
Jalal

[Arnoldinho]

Hi Jalal,

thanks for your reply. I hope you had a nice vacation .
You are of course right - I did not care about resources at that time and therefore did not implement it as a reference. For my case this is nevertheless still more 'save' as I do not want to modify the wallStress_ but only use it for further calculations.

Greetings,
Arne

[chyczewski]

Brent et al,

I have followed the procedure outlined in an earlier post (quoted at bottom) to update the boundary value in the course of a run and seem to have it working. But I get a warning message that is troubling me and I'd like to eliminate it. Here is the warning:

--> FOAM Warning :
From function Field<Type>::Field(const word& keyword, const dictionary&, const label)
in file /....../Field.C at line 262
Reading "myDict" from line 0 to line 0
expected keyword 'uniform' or 'nonuniform', assuming deprecated Field format from Foam version 2.0.

Here is my coding:
The dictionary is created in createFields.H:

IOdictionary myDict
(
     IOobject
     (
        "myDict",
        runTime.constant(),
        mesh,
        IOobject::NO_READ,
        IOobject::NO_WRITE
        )
);

The variable is set in my main loop

myDict.set("myValue",aeq[m][n]);

Finally, refValue is assigned the value of this variable in updateCoeffs() (I copied inletOutletFvPatchField and customized)

const dictionary& myDict = this->db().objectRegistry::lookupObject<IOdictionary>("myDict");
this->refValue() = Field<Type>("myValue",myDict,this->refValue().size());

If I print the value of refValue over the patch it changes appropriately with changes in m and n (used in the set command). So I think it is working properly. Does anyone know how to eliminate the warning or if it can be ignored? If it can be ignored, how do I suppress printing it? I took a look at line 262 of Field.C and get lost when it appears to be using a scalar as a boolean. Any help would be appreciated. Thanks.

Originally Posted by brent_craven

Yes. The methodology discussed by David above (http://www.cfd-online.com/Forums/ope...tml#post309556) worked well for me:

1. Declare the scalar as an IOobject
2. Calculate the scalar in your solver
3. Update the new scalar value with: scalarDict.set("nameOfScalar", valueOfScalar);
4. Access the new scalar value in your BC via a "db().lookupObject<IOdictionary>" (e.g., http://www.cfd-online.com/Forums/ope...tml#post309443)

[chyczewski]

(I just posted this and it seems to have gone to another thread. So I'm trying again. Sorry for any duplication).

I have followed the procedure outlined in an earlier post (quoted at bottom) to update the boundary value in the course of a run and seem to have it working. But I get a warning message that is troubling me and I'd like to eliminate it. Here is the warning:

--> FOAM Warning :
From function Field<Type>::Field(const word& keyword, const dictionary&, const label)
in file /....../Field.C at line 262
Reading "myDict" from line 0 to line 0
expected keyword 'uniform' or 'nonuniform', assuming deprecated Field format from Foam version 2.0.

Here is my coding:
The dictionary is created in createFields.H:

IOdictionary myDict
(
     IOobject
     (
        "myDict",
        runTime.constant(),
        mesh,
        IOobject::NO_READ,
        IOobject::NO_WRITE
        )
);

The variable is set in my main loop

myDict.set("myValue",aeq[m][n]);

Finally, refValue is assigned the value of this variable in updateCoeffs() (I copied inletOutletFvPatchField and customized)

const dictionary& myDict = this->db().objectRegistry::lookupObject<IOdictionary>("myDict");
this->refValue() = Field<Type>("myValue",myDict,this->refValue().size());

If I print the value of refValue over the patch it changes appropriately with changes in m and n (used in the set command). So I think it is working properly. Does anyone know how to eliminate the warning or if it can be ignored? If it can be ignored, how do I suppress printing it? I took a look at line 262 of Field.C and get lost when it appears to be using a scalar as a boolean. Any help would be appreciated. Thanks.

[cfd.with.openfoam]

Hello,

My problem seems to be similar to what Jalal was doing but it is quite tricky to understand what he actually did.

I am working on two BCs right now - one for Velocity and the other one for Temperature and I need to transfer a lot of information from the Vel. BC to the Temp. BC.

So, if I create the IOobject inside the Vel. BC it is not accessible from the Temp. BC. And if I create it in the solver (e.g createFields.H) then it is not possible to write data from the Vel. BC to it so that it can be looked up by the Temp. BC.

For information - I want to transfer a no. of things between the BCs e.g scalars, vectors, scalarFields and VectorFields as well.

I have also tried writing the data to disk from the Vel. BC and then picking it up from the Temp. BC but that is also not working for some reason, if I use the IOdictionary work around. But if I use basic C++ functions to read and write from file then it works atleast for scalars - but with C++ it might be messy to look up the OpenFOAM scalar/vector-fields, beyond that I want to avoid writing to disk during the run as well.

Any comments? Jalal, David, Mark and other Foamers......

Thank you very much