[oevermann]

Hi everybody,

I have written a new boundary condition (a new FvPatchField) for a time dependent inlet velocity. Everything with running the solver works fine. However, when I do a foamToVTK I get the following error

--> FOAM FATAL IO ERROR : keyword U is undefined in dictionary "/home/oevermann/OpenFOAM/oevermann-1.1/run/tutorials/myTurbFoam/blende/3.6e-05/ U_0::inlet"

Actually, I have no idea were to look first and what's going wrong here.
I don't see fundamental difference in terms of the output files if I run the solver just with a fixedValue inlet or my own routine.

Any ideas from the experts here? Thanks!

Michael

[hjasak]

Your input and output functions are not compatible: the stuff that you wrote into the dictionary is not consistent with read in in the constructor from the dictionary.

Hrv

[oevermann]

Hrvoje,

that's what I assumed. However, I don't see the inconsistency. The constructor from the dictionary looks

harmonicInletOutletFvPatchVectorField::harmonicInl etOutletFvPatchVectorField
(
const fvPatch& p,
const vectorField& iF,
const dictionary& dict
)
:
mixedFvPatchVectorField(p, iF),
UInf_(dict.lookup("U")),
pInf_(readScalar(dict.lookup("p"))),
omega_(readScalar(dict.lookup("omega"))),
phase_(readScalar(dict.lookup("phase")))
{
if (dict.found("value"))
...


and the write function

// Write
void harmonicInletOutletFvPatchVectorField::write(Ostre am& os) const
{
fvPatchVectorField::write(os);
writeEntry("value", os);
}

Do I need to write all private data read in by the constructor? If yes, how can I do that (just writeEntry("UInf_",os) ?)

Greetings

Michael

[hjasak]

Well, (excuse the tone) you are dealing with a compiler, not a crystal ball: how would the write() function know that it needs to write out U, p, omega and phase? There is nothing anywhere in the software to tell the compiler this needs to be done, so it is not. If you look at the offending boundary dictionary, you will see that the data is not there.

You need some lines like:

amplitude_.writeEntry("amplitude", os);

Please adjust as necessary - I've picked this one from a similar piece of code.

Enjoy,

Hrv

[oevermann]

Hi Hrvoje,
thanks for the hint! Some lines like
os.writeKeyword("U") << UInf_ << token::END_STATEMENT << nl
have fixed the problem.

I don't think that my initial problem/question had anything to do with the compiler (and/or my knowledge about compilers which might or might not not be as good as yours) - it is just a matter of how the classes in Foam are designed. It is not obvious at all that the write routine of a patch should write exactly the data read and indeed, the solver has no problems with it. It is the postprocessing requiring that and it is not documented anywhere (well, it might be documented but I didn't find it).

Greetings from Berlin

Michael

[hjasak]

Hi Michael,

Hmm, on C++ knowledge I rate myself somewhere up there with Yoda, so I will take up the challenge:

If I design a class in a hierarchy and add an unknown number and type of private data into a final derived class, which may be in a form of a value member, a static or a reference, can you create a form of the base class (which clearly does not see the derived private argument types) to handle derived class I/O automatically?

The only form I can suggest is to template on the base with member types as arguments, which brings in the story of elipsis in the template argument list, and that's definitely not standard C++.

The post-processing requirement is a "value" entry in the patch field dictionary, which is indeed handled automatically, by calling the write function from the virtual base.

Can you enlighten me?

Hrv

[oevermann]

Hrvoje,
sorry, but I cannot enlighten you :-(
Your last sentence was just the answear I hoped for in my initial question. Your class design makes perfect sense and I agree there is no solution for
automated class I/O here.