[Tobermory]

I have a really odd bug in a simple application for OF v8 that I have written to calculate some initial fields. The code updates some values in constant/thermophysicalProperties using:

IOdictionary thermoDict(
    IOobject(
        "thermophysicalProperties", 
        "constant", 
        mesh, 
        IOobject::MUST_READ, 
        IOobject::AUTO_WRITE
    )
);
thermoDict.subDict("mixture").subDict("equationOfState").set("rho0",abl.rho0);
thermoDict.regIOobject::write();

This generally works fine ... except that it changes the class entry in the header of the thermophysicalProperties file from dictionary to volScalarField! This then causes all sorts of warnings and odd behaviour in the solver.

Can anyone give me a hint as to why the class is changed on rewriting the dictionary?

[dlahaye]

Apologies for being in the thick mist by your question.

Q1: who/what changes the class entry ?

Q2: what is the correct type, i.e., why is volScalarField not the desired type?

[Tobermory]

I should have been clearer in my first post Domenico. At the top of every foam file is a header with something like the following text:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      thermophysicalProperties;
}

with what I have since found is a IOobject::headerClassName_, which should be "dictionary" for thermophysicalProperties, since the file is a dictionary file. It would be volScalarField for the p file, volVectorField for U etc.

Now what is bizarre is that I open thermophysicalProperties, adjust some of the contents and then write it out, and suddenly the headerClassName changes from dictionary to volScalarField.

I tried moving just the lines above into a new app, and the bug doesn't happen (!), so there must be something subtle going on. I'll keep testing.

[dlahaye]

Very sorry to say that I am still in the mist.

Are you running an application that creates constant/thermophysicalProperties
for you?

I am happy to keep read attentively whatever you send across.

[Tobermory]

Ok - weirder and weirder ... I am now printing out the contents of headerClassName:

Info << thermoDict.regIOobject::headerClassName()  << endl;

and it is still dictionary, i.e. correct, even though it writes volScalarField. Grrr.

[Tobermory]

Originally Posted by dlahaye

Are you running an application that creates constant/thermophysicalProperties
for you?

Yes - or rather it updates some of the values as well as setting up the initial fields. I am slowly narrowing down what the cause is - the good old fashioned way of comment everything out, and slowly uncomment until the problem occurs, and voila - you have found your culprit.

[Tobermory]

Well, I have found the culprit. I needed to pull out the value of kappa from the wall boundary, to use in the initial fields calculation, but rather crudely I had opened the nut file as a IOdictionary rather than a volScalarField. For some reason this then caused thermoDict, opened later as a IOdictionary, to write as a volScalarField! Very odd, but a problem of my making I guess.

I'll need to find another way of stripping out kappa from the nut file.