CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   private boundary condition in controlDict strange behaviour (http://www.cfd-online.com/Forums/openfoam-programming-development/69379-private-boundary-condition-controldict-strange-behaviour.html)

markc October 21, 2009 05:55

private boundary condition in controlDict strange behaviour
 
2 Attachment(s)
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 October 22, 2009 04:59

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 October 22, 2009 06:57

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 October 22, 2009 07:15

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 June 23, 2010 03:53

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 April 4, 2011 09:01

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 April 5, 2011 02:51

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

sixwp April 5, 2011 02:58

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

Aerospace June 30, 2011 04:33

Quote:

Originally Posted by Rickard.Solsjo (Post 302237)
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 June 30, 2011 04:49

Hey
Can you upload the case?

Aerospace November 10, 2011 12:38

Quote:

Originally Posted by Rickard.Solsjo (Post 314186)
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 November 18, 2011 15:59

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 November 23, 2011 11:18

Quote:

Originally Posted by mkh_sakr (Post 332720)
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


All times are GMT -4. The time now is 15:19.