[CFDUser_]

Hi All,

I wanted to define a define a something like this

IOdictionary foo
(
IOobject
(
"foo",
runTime.timeName(),
runTime,
IOobject::READ_IF_PRESENT,
IOobject::NO_WRITE
),
scalar( "foo", dimless, foo_inf )
);

which is something similar to

volScalarField p
(
  IOobject
  (
    "p",
    runTime.timeName(),
    mesh,
    IOobject::READ_IF_PRESENT,
    IOobject::AUTO_WRITE
  ),
  mesh,
  dimensionedScalar( "p", dimless, p_inf )
);

but ended dith following error

Making dependency list for source file hello.cpp
SOURCE=hello.cpp ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam230/src/finiteVolume/lnInclude -g -IlnInclude -I. -I/opt/openfoam230/src/OpenFOAM/lnInclude -I/opt/openfoam230/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/hello.o
hello.cpp: In function ‘int main(int, char**)’:
hello.cpp:36:33: error: expression list treated as compound expression in functional cast [-fpermissive]
hello.cpp:36:33: warning: left operand of comma operator has no effect [-Wunused-value]
hello.cpp:36:33: warning: right operand of comma operator has no effect [-Wunused-value]
hello.cpp:37:1: error: no matching function for call to ‘Foam::IOdictionary::IOdictionary(Foam::IOobject, Foam::scalar)’
hello.cpp:37:1: note: candidates are:
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:84:9: note: Foam::IOdictionary::IOdictionary(const Foam::IOobject&, Foam::Istream&)
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:84:9: note:   no known conversion for argument 2 from ‘Foam::scalar {aka double}’ to ‘Foam::Istream&’
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:81:9: note: Foam::IOdictionary::IOdictionary(const Foam::IOobject&, const Foam::dictionary&)
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:81:9: note:   no known conversion for argument 2 from ‘Foam::scalar {aka double}’ to ‘const Foam::dictionary&’
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:78:9: note: Foam::IOdictionary::IOdictionary(const Foam::IOobject&)
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:78:9: note:   candidate expects 1 argument, 2 provided
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:54:7: note: Foam::IOdictionary::IOdictionary(const Foam::IOdictionary&)
/opt/openfoam230/src/OpenFOAM/lnInclude/IOdictionary.H:54:7: note:   candidate expects 1 argument, 2 provided
make: *** [Make/linux64GccDPOpt/hello.o] Error 1

can somebody help me?

Regards,
CFDUser_

[tomislav_maric]

which is something similar to

You are guessing how a IOdicitonary constructor looks like, based on how the constructor of the GeometricField looks like.


Don't guess - look at the code and find out.


Find IOdictionary.H and take a look at the public class interface, and you will see the compilers and their signatures. You can use only those declared there.

[CFDUser_]

Originally Posted by tomislav_maric

You are guessing how a IOdicitonary constructor looks like, based on how the constructor of the GeometricField looks like.


Don't guess - look at the code and find out.


Find IOdictionary.H and take a look at the public class interface, and you will see the compilers and their signatures. You can use only those declared there.

Dear Tomislav,

I know both the definitions. Unfortunately I need to define such a IOdictionary for some advanced postprocessing purpose. Since READ_IF_PRESENT for IOdictionary is already defined, I am scared to change its constructor.

I have something in my mind that is not straight forward to overcome this problem. So, just looking for better suggestions if some people may already overcome this problem.

Thank you,

Regards,
CFDUser_

[tomislav_maric]

Do you need an object that has a scalar and has a IOdictionary?

You should never change the classes to make them run the way you want - use object oriented principles. Either inherit or compose classes.

What you could do is to write a new class that has an IOdictionary attribute and a scalar attribute.

Waning: the code below I typed, I didn't test it:

class enhancedScalar
{
    IOdictionary dict_; 
    scalar value_; 

    public: 

         enhancedScalar(const IOdictionary& io, scalar s)
             :
                 dict_(io), 
                 value(s)
        {}
}

And then in the client code:

enhancedScalar es (
    IOdictionary
    (
          ... parameters
    ), 
    scalar (11)
);

You can also inherit from IOdictioanry if the new class should behave like IOdictionary.

There are multiple options - the real question is: what exactly do you want to do?

If you answer this question without using class names, I may be able to help you.

[alexeym]

Hi,

unfortunately "I wanted to define a define a something like this" does not quite describe what you are trying to achieve. Would you like to set scalar foo to certain value if there is no dictionary?

There already was an attempt to guess the reason you'd like to create the dictionary your way, it was not quite successful, maybe you can describe your problem in more details?

Upd. It seems I was writing the post too long

[CFDUser_]

Originally Posted by tomislav_maric

Do you need an object that has a scalar and has a IOdictionary?

You should never change the classes to make them run the way you want - use object oriented principles. Either inherit or compose classes.

What you could do is to write a new class that has an IOdictionary attribute and a scalar attribute.

Waning: the code below I typed, I didn't test it:

class enhancedScalar
{
    IOdictionary dict_; 
    scalar value_; 

    public: 

         enhancedScalar(const IOdictionary& io, scalar s)
             :
                 dict_(io), 
                 value(s)
        {}
}

And then in the client code:

enhancedScalar es (
    IOdictionary
    (
          ... parameters
    ), 
    scalar (11)
);

You can also inherit from IOdictioanry if the new class should behave like IOdictionary.

There are multiple options - the real question is: what exactly do you want to do?

If you answer this question without using class names, I may be able to help you.

Thats awesome will try this weekend.
In between, I have few IOdictionary objects in some time directories.
let me show one of such object.

FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "1e-3";
object foo;
}

foo 34
(
1
2
3
.
.
.
34
);

Note it is not there in all time dir's.

If I define a IOdictionary foo(... READ_IF_PRESENT....), It will throw an error if file is not there in time dir.
That is the reason i wanted something like Geom field.

One more, is there any option like push_back in OpenFoam? If so please describe with simple example.

Thank you

Regards,
CFDUser_

[tomislav_maric]

I agree with alexey, let us know what your actual goal is - it might be that the implementation you have in mind will not work or is not the best one, discussing the actual goal is allways better than implementation details.

Don't try to implement the example that I proposed unless that is really what you need. This is only valid if your new class should compose both IOdictionary and a scalar.

For instance, if you want the new object to be modifiable at run-time, then I would propose you inherit from IOobject instead.

What are you conceptually trying to accomplish?

[CFDUser_]

I am trying to collect the lagrangian particles information in a defined region.
Hope this description will clear what i am trying to do.

Regards,
CFDUser_

[tomislav_maric]

Originally Posted by CFDUser_

I am trying to collect the lagrangian particles information in a defined region.
Hope this description will clear what i am trying to do.

Regards,
CFDUser_

Cool, thanks for the info, it helps a lot.

You store the lagrangian particles information as dictionaries? So that each particle has a dictionary and then a scalar, a vector, or whatever else you want the particle to carry?

[CFDUser_]

Originally Posted by tomislav_maric

Cool, thanks for the info, it helps a lot.

You store the lagrangian particles information as dictionaries? So that each particle has a dictionary and then a scalar, a vector, or whatever else you want the particle to carry?

exactly

[tomislav_maric]

My first impression is that using dictionary for this causes an unnecessary overhead. Lookup operations on millions of particles will destroy your efficiency, and dictionary is a heap based data structure - which means that heap allocations will then put the last bullet in the forhead of the efficiency of your code.

Before proceeding, note that I have 0 experience in working with lagrangian stuff in OpenFOAM, all what follows comes from browsing the code.

If you take a look at :

/src/lagrangian/basic

you'll find a file called 'indexedParticle.H' and inside it:

Class
    Foam::indexedParticle

Description
    Adds label index to base particle

and

class indexedParticle
:
    public particle
{
    // Private data

        label index_;

So you can see that in order to have a particle that has an index, composition is used for the particle class - label is composited into it. The same can work for you, if your particles have scalars, vectors, or whatever.

The thing that you want to compose - say particleProperty you should also encapsulate into a class. This way you'll be able to store different things, as with the dictionary, without the additional heap allocation + lookup costs. (heap allocation within the dict - not sure what data structure is used to store particles in lagrangian, I never touched it)

You should IMHO then statically at compile time choose the particle property and have an efficient code. You could theoretically add runtime selection to the particleProperty, again, at costs of efficiency. I would not do that.

Anyway, since you are thinking about extending particles with additional information, the way above is how it is done in OF, and how I would do it if I were you. I would go away from dictionaries.

Good luck!

Hope this helps

[CFDUser_]

Originally Posted by tomislav_maric

My first impression is that using dictionary for this causes an unnecessary overhead. Lookup operations on millions of particles will destroy your efficiency, and dictionary is a heap based data structure - which means that heap allocations will then put the last bullet in the forhead of the efficiency of your code.

Before proceeding, note that I have 0 experience in working with lagrangian stuff in OpenFOAM, all what follows comes from browsing the code.

If you take a look at :

/src/lagrangian/basic

you'll find a file called 'indexedParticle.H' and inside it:

Class
    Foam::indexedParticle

Description
    Adds label index to base particle

and

class indexedParticle
:
    public particle
{
    // Private data

        label index_;

So you can see that in order to have a particle that has an index, composition is used for the particle class - label is composited into it. The same can work for you, if your particles have scalars, vectors, or whatever.

The thing that you want to compose - say particleProperty you should also encapsulate into a class. This way you'll be able to store different things, as with the dictionary, without the additional heap allocation + lookup costs. (heap allocation within the dict - not sure what data structure is used to store particles in lagrangian, I never touched it)

You should IMHO then statically at compile time choose the particle property and have an efficient code. You could theoretically add runtime selection to the particleProperty, again, at costs of efficiency. I would not do that.

Anyway, since you are thinking about extending particles with additional information, the way above is how it is done in OF, and how I would do it if I were you. I would go away from dictionaries.

Good luck!

Hope this helps

Unfortunately you understand me in a wrong way I guess.

Thing is that now I have good enough postprocessing stuff which will do all these calculations at runtime and as you said efficient way to do.

But what I am trying now is postprocessing available results. I have loads of results to analyze and I need such a IOdictionary to make things easy.

Regards,
CFDUser_

[vitors]

Hello all,

I suppose this thread is a good place to ask this question: how does READ_IF_PRESENT works?

http://openfoamwiki.net/index.php/In...IOobject_class
says "It reads the object from Istream if Istream exists, otherwise doesn't. An error message is produced only if Istream exists but can't be read."

So, my problem: I added a source-term for chtMultiRegionSimpleFoam and I want is the solver tries to read Q file. If the file is there the solver reads the file. This works fine.

However, I have cases where the file will not be present and, in this case, I wish to create a volScalarField of zeros and I'll have no source-term.

To achieve this idea, I'm trying to use this code:

        IOobject Qfile
        (
            "Q",
            runTime.timeName(),
            solidRegions[i],
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        );

Well, if the file is there in directory 0, everything goes ok. If not, the solver stops with:

--> FOAM FATAL IO ERROR: 
cannot find file

file: /home/vitors/workspace/tutorials/acople1/0/fuel/Q at line 0.
...

I'm obviously missing something about READ_IF_ORESENT. Anybody has some hint?

Thanks a lot!

Vitor

[CFDUser_]

Originally Posted by vitors

Hello all,

I suppose this thread is a good place to ask this question: how does READ_IF_PRESENT works?

http://openfoamwiki.net/index.php/In...IOobject_class
says "It reads the object from Istream if Istream exists, otherwise doesn't. An error message is produced only if Istream exists but can't be read."

So, my problem: I added a source-term for chtMultiRegionSimpleFoam and I want is the solver tries to read Q file. If the file is there the solver reads the file. This works fine.

However, I have cases where the file will not be present and, in this case, I wish to create a volScalarField of zeros and I'll have no source-term.

To achieve this idea, I'm trying to use this code:

        IOobject Qfile
        (
            "Q",
            runTime.timeName(),
            solidRegions[i],
            IOobject::READ_IF_PRESENT,
            IOobject::AUTO_WRITE
        );

Well, if the file is there in directory 0, everything goes ok. If not, the solver stops with:

--> FOAM FATAL IO ERROR: 
cannot find file

file: /home/vitors/workspace/tutorials/acople1/0/fuel/Q at line 0.
...

I'm obviously missing something about READ_IF_ORESENT. Anybody has some hint?

Thanks a lot!

Vitor

this was the doubt i raised too ...
problem is IOobject is designed in such a way that it should always look for the variable you wanted to read.
use some basic c++ language to find the directory/file we wanted to read. if present continue else break.

below link will give you some hint
http://stackoverflow.com/questions/2...-change-output

[vitors]

Thank you very much CFDUser.

Actually, I could solve my problem. But I am always wondering when use OpenFOAM classes or std C++ library. I always start thinking using OpenFOAM classes is the best option since I'm inside OpenFOAM. But its classes are always so "tight" conceived (try to instantiate a volScalarField of zeros, or use istream to read a file or check if it existes, or use OpenFoam's fileName to get the file string...).

I'm always pushed to use std C++ after struggling with OpenFOAM classes...

Cheers,

Vitor