The data file, as i understand, takes scalar values, and not vector values, i cant write
t,U => 0.001 (1200 200 0). In that case actually it rakes a scalar 0.001 1200 and sets U[0] to the value. How can i set U[1], U[2]?

if you want the data file to be present in the root, (as i like it) then simply replace in the file:
finiteVolume/fields/fvPatchFields/derived/timeVaryingUniformFixedValue/timeVaryi ngUniformFixedValueFvPatchFields.C
the line in the constructor
timeDataFileName_(fileName(dict.lookup("timeDataFi leName")).expand()),

with

timeDataFileName_(this->db().time().path()/fileName(dict.lookup("timeDataFileNam e")).expand()),

compile finiteVolume with wmake libso

[johndeas]

Hi, in order to simulate a turbulent inlet I identified two solutions, the first is to use a single domain and, with the help of directMapped, translate and copy a profile from inside the flow to the boundary, thus computing a developed periodic flow at the same time as the real flow. The other solution is to use a periodic inlet channel which boundary profiles will be saved/loaded on the disk for the real calculation, the two calculations being completed sequentially.

I am currently using the second solution, to keep calculations domain as small as possible, and to be able to reuse easily the turbulent inlets. So far I am only calculating the channel flow to attain a developed state. But, I have some doubts concerning the pressure at the boundary, since using timeVaryingMappedFixedValue for velocity will force me to use zeroGradient for the pressure. However, physically, there would be no such condition inside the flow, with a non-zero pressure gradient along the flow direction. Here you can find a graphical sum-up of the situation:


I would like to know, if I am supposed to get into trouble. My first thought was that, although this condition is not physical regarding a real channel, the flow is mainly advective, so the error induced at the inlet would be small, for the flow shows little modification along the boundary normal.

Details about my calculation are: unstationnary DNS, Re=11000 base on mean velocity and hydraulic diameter.

Regards,

JD

[christoph_heinrich]

Hi all,

I'd like to change the type of the boundary condition at one patch from "tractionDisplacement" to "fixedValue" from within my solver. How can I do that? And then how can I set the value of my fixedValue-BC to a given vectorField from within the solver?

Thanks in advance

Regards,
Christoph

[ngj]

Hi Christoph,

I do not know how you change the type of the boundary condition from within the solver, but at least you can do the following.

label patchID = mesh.boundaryMesh().findPatchID("bcName");
U.boundaryField()[patchID] == userDefinedVectorField;
U.correctBoundaryCondition();

Please note the double=: "=="!

Hope it helps, otherwise please ask.

- Niels

[christoph_heinrich]

Hi Niels,

thanks a lot! Can you tell me what "U.correctBoundaryConditions();" exactly does? Is it necessary? Because when using this command I get an error message:
--> FOAM FATAL ERROR :
request for volTensorField grad(U) from objectRegistry solid failed
available objects of type volTensorField are

0
(
)


From function objectRegistry::lookupObject<type>(const word&) const
in file /home/mch10300/OpenFOAM/OpenFOAM-1.4.1-dev/src/OpenFOAM/lnInclude/objectRegistry Templates.C at line 142.

FOAM aborting

Aborted


Christoph

[ngj]

Hmmm, that sounds strange. Though what is your type for the boundary on the patch, where you specify the value?
If it is presently not 'fixedValue' try to set it to that type.
I have not seen that kind of error before, thus I cannot help you more explicitly.

Best regards,

Niels

[kenson70]

Hi All,

I just recently started using OpenFOAM. I have some experience writing CFD solvers, but not using C++. I would like to validate the Incompressible solver using an analytic (2-D) solution. I have velocity and pressure as a function of time an space, i.e., u=u(x,y,t,mu),v=v(x,y,t,mu), p=(x,y,t,mu) (where mu is the physical viscosity).

I would like to run a case where I can call a function for u,v and p (with x,y,t and mu given)that computes the values, to be used as boundary data. (Ideally I would also like to use the functions to initiate the flow as well).

I found a note on this by Bernhard Gschaider on Monday, October 09, 2006 - 09:20 am:

''Or if you know your BC as a f(t,x,y,z) (this time x,y being he coordinates) you just write a new BC with a fitting updateCoeffs-method.''

I would be greatful for constructive comments on how to do this in practise (I assume many people have already solved this in a simple way).

Best regards Ken

[christoph_heinrich]

Hi Niels,
the type is "tractionDisplacement" in my 0/U file. In my code I would like to shift from tractionDisplacement to fixedValue and back, because sometimes I need tractionDisplacement and sometimes fixedValue in the same timestep.
Perhaps I should try to define two different U-fields, one with tractionDisplacement and the other with fixedValue.

Best regards,
Christoph

[grtabor]

Hi Ken.

I often think the easiest (although not the most elegant) way of doing this is just to set the boundary to be fixedValue and then grab the data and modify it inside the code. Thus, you can get the patch face centre points thus:

vectorField inletFaceCentres(mesh.C().boundaryField()[patchNo]);

and the X, Y and Z components of the velocity as

scalarField UInletX(U.boundaryField()[patchNo].component(vector::X));
scalarField UInletY(U.boundaryField()[patchNo].component(vector::Y));
scalarField UInletZ(U.boundaryField()[patchNo].component(vector::Z));

You can then manipulate the values in these scalarFields (the ordering is the same), and then replace them

U.boundaryField()[patchNo].replace(vector::X,UInletX);

To do this more elegantly you would derive your own boundary condition, but this might be easier if you just want to get some results quickly.

Gavin

[ngj]

Hi Christoph

There a call types() in geometricBoundaryField, see [1], which return a list of types on the different patches. So you could try, if the following routine could change the actual type:

U.boundaryField()[patchID].types() = "fixedValue";

If it does, please let me know

Best regards,

Niels

P.S. Making two different U-files sound a bit heavy both with respect to memory usage and the fact that you would need two matrix equations, one for U1 and one for U2. Thus I would recommend to find a more elegant way.

[1]: http://foam.sourceforge.net/doc/Doxygen/html/classFoam_1_1GeometricField_1_1Geom etricBoundaryField.html

[fw407]

Hi everyone,

I am trying to simulate a pressure pulse, and am trying to use "timeVaryingUniformFixedValue". the inlet pressure boundary conditions looks like(/0/p):

inlet
{
type timeVaryingUniformFixedValue;
timeDataFileName "inlet.dat";
value uniform 0;
}

as I only need to generate a pressure pulse, I think I only need to input the pressure value within a short time peroid in the "inlet.dat" field, and the pressure value at the rest of the time is by default set as 0, is that right?

when I am trying to run the case, I get the same errors (By Nishant Singh on Friday, April 11, 2008 - 07:12 am: Edit Post), complaining the "*.dat" file can not be found. in the post By Iyer Arvind Sundaram on Friday, May 16, 2008 - 09:47 pm, he said:
"the data file must be at the location from where are launching the solver"

I admit I don't haven't got him completely and still no idea where I should put the "*.dat" file,Could someone give me some hints?

Kind regards

feng

[pi06jl6]

Please advice,

I am currently working with a moving boundary, the U velocity have to change with the movement of the solid, i have the current solution,

1. Assign U ( with == ) at faceCentres to the displacement of solid at given point / delta t

2. Update mesh

3. U.correctBoundaryCondition

Does this do the thing as expected?

[hjasak]

Why don't you just use the movingWallVelocity boundary condition - it will update the surface-normal velocity component to correspond o mesh motion. Also, it is much more accurate than doing it by hand, because the motion velocity is calculated from the volume swept by a face in motion.

Enjoy,

Hrv

[pi06jl6]

Thank you Dr Hrvoje Jasak for the response, this is exactly what i am looking for, thats is no slip condition for updated mesh. However, when i implemented i got FATAL FOAM error, telling me that U field for the specified moving boundary cannot be used for the calculatedpatchField

What i did is the following, i assumed U on moving patch is calculated from cellDisplacement, then using calculated on U/patch/moving boundary, i then used MovingWallVelocity on the cellDisplacement, btw i am using displacementlaplacian solver, would like to keep it that way.

I tried also,

U/movingpatch/MovingWallVelocity
celldisplacement/fixedValue

Same result...

Would appriciate help with the input.

[christoph_heinrich]

Thanks Niels,

with
Info << U.boundaryField()[patchID].type() << endl;
I can read the type of the boundary condition. But when I try to set it with
U.boundaryField()[patchID].type()="fixedValue";
I get the error message
error: passing 'const Foam::word' as 'this' argument of 'void Foam::word::operator=(const char*)' discards qualifiers

Any idea?

Regards,
Christoph

[pi06jl6]

I am sorry but presented wrong input, this was the input for the FATAL FOAM error, btw the same used in similar code for moving boats for U file, they using solid solver for the update of the mesh,

U:

MovingBoundary {
type MovingWallVelocity;
value uniform ( 0 0 0 );
}

CellDisplacement:

MovingBoundary {
type fixedValue
value uniform ( 0 0 0 );
}

pointDisplacement {
calculated
}

Then in the cellDisplacement i have tested MovingWallVelocity.

Would truly appriciate help on this.

The main solver is icoFoam where i have changed mesh to dynamic and change the boundary values accordince to input vector. The prescribed motion is excellent although i could get the no slip condition right for the moving part. This is precisely the reason i was setting displacement/delta as prescribed motion, exactly in same procedure as done for icofsiFoam.

Best Regards

Johan

[ngj]

Hi Christoph

Sorry, I have run out of ideas.

/ Niels

[hjasak]

type MovingWallVelocity;

This is your problem: it must start with a lowercase "m":

type movingWallVelocity;

What happened is that an unknown b.c. type is found, and you get calculated instead, which cannot be used.

[pi06jl6]

Thank you again! (embarrased here) Now i got a minor nuissance, as a consequence the solver ask for phi file, little surprised since i assume its internally resolved in the icoFoam.