[markc]

Hello All,

I wrote a private boundary condition which I want to use in interFoam-like solvers. Instead of adding the library in the interFoam - options file, I tried to add a line in controlDict:
>>>
libs ("libBoundaryConditions.so");
<<<
This works but when using some utilities, e.g. foamToVTK (and some others as well) the utility fails with an error message like:

>>>
request for uniformDimensionedVectorField g from objectRegistry region0 failed
available objects of type uniformDimensionedVectorField are

0
(
)
<<<
Uncommenting the lib in controlDict makes the utility to work fine. This behavior is not with all utilities, e.g. checkMesh, setFields work fine in all cases.
Adding a private library to a solver without rebuilding is a very nice solution, however in this cases it is a bit inconvenient and I wonder what is going wrong here. Is it a bug or am I doing something wrong?

I attach two folders:
1. waveBCdev, the BC in question (which generates surface waves). Put in user/applications and do: wmake libso
2. waveTank, a testcase. Do: blockMesh, setFields and interFoam. commenting/uncommenting the line in question in controlDict will show the behavior.

Note that the files are intended for OF1.6, however this behavior was already noted in OF1.5.

Any help is appreciated.

Best regards,

Mark

[eugene]

Hi Markc,

Your problem is the following:

Your new boundary uses the gravity vector "g" which is normally loaded into the object registry from the environmentalProperties dictionary by the top level code. If the top level code does not explicitly load the variable into the database, then it will not be available to the boundary condition. foamToVTK for example does not load environmentalProperties so when the boundary is initialised it cannot find the correct field "uniformDimensionedVectorField g".

Note that the variable is only required when the field the boundary is used for is initialised. Thus setFields and checkMesh do not trigger this error because they do not create the field that uses the boundary.

[markc]

Hello Eugene,

Thanks for taking the time looking at my case. Your answer is perfectly clear. The workaround now seems to be to load a gravity vector in a way which is independant of the object registry. Instead of:
>>>
const uniformDimensionedVectorField& g =
db().lookupObject<uniformDimensionedVectorField>(" g");
<<<
I will try something like:
>>>
uniformDimensionedVectorField g
(
IOobject
(
"g",
this->db().time().constant(),
this->db(),
IOobject::MUST_READ,
IOobject::NO_WRITE
)
);
<<<

Once again thanks for your reply,

Brgds,

Mark

[eugene]

Hi Markc,

What you propose is one option, but it would require disk access every timestep, which is costly.

Rather I would suggest you create g as an autoPtr<uniformDimensionedVectorField> and then initialise it with the lookup version if available. If g does not exist in the database, you could either read it from file or just ignore it, print a warning and not update the boundary values.

[Rickard.Solsjo]

I realize it was a long time ago since you started this thread.
I have the same problem with the uniform.......field g. If it is not loaded by the enviromentalproperties how do you fix it? Im using rhoPisoFoam and I copied the enviromentalproperties file from another and put it into the constant folder.
Do I add some line in the fvSchemes, Solution, controlDict or similar ?

Tx
R

[sixwp]

Hi Rickard,

I had exactly the same problem (with icoFoam but anyway, still). I just managed to solve it.

In my case, the BC were the problems. For, p I had buoyantPressure BC for a wall and it wasn't fitted for icoFoam (with a zeroGradient, it's fine).
I will suggest to have a look at your BC, carefully!

Hope that can help you

[Rickard.Solsjo]

Thx for the reply!
But I fixed my problem some 8months ago =)

[sixwp]

Yeah I realised your message was old after writing the reply ^^
Anyway, that may help someone else :-)

[Aerospace]

Originally Posted by Rickard.Solsjo

Thx for the reply!
But I fixed my problem some 8months ago =)

Hi Rickard,

I'm doing a heatTransfer problem and I have the same error using the new version, OF 2.0. Could you tell me how do you solve the problem in your case without change the BCs?

Best regards.

[Rickard.Solsjo]

Hey
Can you upload the case?

[Aerospace]

Originally Posted by Rickard.Solsjo

Hey
Can you upload the case?

I'm sorry i dind't see your post. I'm trying to employ decomposePar with uniformDensityHidrostaticPressure as BC for p_rgh (buoyantBoussinesqSimpleFoam solver) but this error message appears:

request for uniformDimensionedVectorField g from objectRegistry region0 failed
available objects of type uniformDimensionedVectorField are

0
(
)

Do you know how to fix it?

Thankyou very much!!

[mkh_sakr]

hi,
i try to use uniformDensityHydrostaticPressure with simpleFoam and I face the same problem (uniformDimensionVectorField g is not included )how can i solve it

[Aerospace]

Originally Posted by mkh_sakr

hi,
i try to use uniformDensityHydrostaticPressure with simpleFoam and I face the same problem (uniformDimensionVectorField g is not included )how can i solve it

I solved it employing the buoyantPressure BC at the outler, it works like the uniformDensityHydrostaticPressure for buoyant solve.

If your are working with a solver which doesn't employ bouyancy the uniformDensityHydrostaticPressure is not needed.

Regards