I am interested in implementi
 

I am interested in implementing time varying boundary conditions for a transient simulation. I wish to read in a series of pressure values from a text file, and update the boundary at each timestep.

Is it possible to do this without modifying and recompiling the standard solver? I noticed the "timeVaryingUniformFixedValueFvPatchField" class on the Doxygen notes--- can this be used with any standard solver directly?

Thanks,
Jarrod

Looks like timeVaryingUniform
 

Looks like timeVaryingUniformFixedValueFvPatchField is exactly what you need - have a look at the timeVaryingUniformFixedValueFvPatchField.C file for the details of what the class actually does. If this is what you want, you can use it on any variable with any application you choose. However, I wouldn't be suprised if there are no examples on how to set it up (and this is not supported by FoamX), but reading error messages carefully and editing the file by hand should do the trick.

Incidentally, the whole idea of foam is to provide a toolkit and example applications, which allow you to configure the code to do precisely what you want it to do, no more and no less. In my opinion, yoiu cannot get far using foam unless you start editing files by hand (FoamX is nowhere near flexible enough...) and compiling your own customised executables.

Enjoy,

Hrv

The timeVaryingUniformFixedVa
 

The timeVaryingUniformFixedValueFvPatchField BC I wrote will probably do what you want. It interpolates in time (but not space, it assumes the profile across the patch is uniform) the table of values you supply. It can be used with any OpenFOAM application and if you would like to be able to use it from FoamX it would be quite easy for you to add support for it via the FoamX configuration files as for the other BCs.

Thanks for the support so far-
 

Thanks for the support so far--- I've tried to apply the boundary condition using the icoFoam solver, but am having some trouble getting it working. I've specified an input file for the pressure value of a boundary patch. The initial field is defined as (/0/p):

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

Is this correct? When I try to run the case, it faults and gives the following error:

Starting time loop

Time = 1e-06

Max Courant Number = 2.11578e-05
BICCG: Solving for Ux, Initial residual = 1, Final residual = 1.38595e-10, No Iterations 1
BICCG: Solving for Uy, Initial residual = 1, Final residual = 2.02749e-10, No Iterations 1
BICCG: Solving for Uz, Initial residual = 1, Final residual = 2.20734e-10, No Iterations 1


--> FOAM FATAL ERROR : gradientInternalCoeffs cannot be called for a calculatedFvPatchField.
You are probably trying to solve for a field with a calculated or default boundary conditions.

Function: calculatedFvPatchField::gradientInternalCoeffs() const
in file: fields/fvPatchFields/basicFvPatchFields/calculated/calculatedFvPatchField.H at line: 174.

FOAM exiting

Do you have any suggestions?

What boundary condition have
 

What boundary condition have you specified for the pressure on the other patches?

I think I have worked out wha
 

I think I have worked out what is going on. The timeVaryingUniformFixedValue BC is defined in the cfdTools library which is not linked into icoFoam so you end up using a default BC which is equivalent to "calculated". Add the line

EXE_LIBS = -lcfdTools

to the Make/options file in icoFoam and recompile and your case should run.

Thanks Henry, it works well n
 

Thanks Henry, it works well now. Just to let others know, the format for the time series text file is:

(
t0 p0
t1 p1
t2 p2
....
tN pN
)

To use the derived total pressure boundary condition with timeVaryingUniformFixedValue, would I have to create a new mixed boundary condition?

It would probably be best to
 

It would probably be best to start from the totalPressure fvPatchField type in OpenFOAM-1.0.2/src/OpenFOAM/fields/fvPatchFields/derivedFvPatchFields/totalPressure
Copy those files and rename them as say timeVaryingUniformTotalPressureFvPatchScalarField and do a search/replace for that name in both the H and C file and then add the code which handles the data interpolation from the timeVaryingUniformFixedValue BC in OpenFOAM-1.0.2/src/cfdTools/derivedFvPatchFields/timeVaryingUniformFixedValue

Henry, Would it be a good
 

Henry,

Would it be a good idea to add timeVaryingUniform to the value field, rather than on a boundary type? If so, the available fixedValue options would be "uniform", "nonuniform", "timeVaryingUniform".

That's two very different thi
 

That's two very different things. The "uniform" and "nonuniform" you refer to are helpers for writing out the Field class, i.e. if there is only one value for the complete field you will only write it once.

Those are available for ALL things derived from field, e.g. internal field, cell volumes etc. and not just for the boundary condition you are looking at.

Hope this helps - we are talking about class organisation, not just hacking the I/O format.

Hi Hrv, Sorry if this is i
 

Hi Hrv,

Sorry if this is irrelevant to thread, I had sent you an email and was wondering did you receive it? Regards.

Jarrod, It would be possib
 

Jarrod,

It would be possible to add timeVaryingUniform to the type of field but not necessarily a good idea. In fact this form is just one option from a much larger set of possibilities which would need a function interpreter to handle, e.g. boundary distributions given as functions of time and/or space which are evaluated on the mesh at run time. Some years ago I made a big effort to write a near-complete C++ interpreter for this and other purposes; it would also allow the top-level FOAM codes to run as scripts and interactive field manipulation in the pre/post processing, but the most important use would be for more flexible boundary condition specification. When I get some time/money I will go back to the interpreter and finish off at least to the point that it can fulfill this last requirement but I cannot promise when this will happen.

Would this also work with a ve
 

Would this also work with a velocity inlet and how would the inlet.dat look in this case?

The same as for a scalar field
 

The same as for a scalar field but it assumes the velocity is positive inwards and in a direction normal to the patch.

I tried the transient bounary
 

I tried the transient bounary for a scalar (pressure) and everything works fine. But if I use the same inlet.dat file for an velocity inlet, I get the following error:

FOAM FATAL IO ERROR : IOstream::check(const char* operation) : error in IOstream "inlet.dat" for operation Istream::operator()

file: inlet.dat at line 1.

Function: IOstream::check(const char* operation) const
in file: db/IOstreams/IOstreams/IOcheck.C at line: 54.

FOAM exiting


What does it mean?

Are you sure the file is in th
 

Are you sure the file is in the correct location?

It is at the same location whe
 

It is at the same location where it worked with the pressure inlet. In this case it worked all fine.

I just changed the inlet from an pressure inlet to an velocity inlet.

What message do you get if you
 

What message do you get if you remove the file?

I am sorry, the file was at th
 

I am sorry, the file was at the wrong place.

But I am still confused why there was no error message with the pressure boundary, since I didn't change file location when I switched from pressure boundary to velocity boudary.

Thanks anyway!!

Dear Henry, a followup on thi
 

Dear Henry,
a followup on this thread...
My problem is the following:
On one boundary I need to set all fields into two states, similar to a shock tube problem, but it describes the exact motion of a shock and hence is time dependent (linear interpolation between two the two states is valid). So it seems that I need to use timeVaryingUniformFixedValueFvPatchField
without the uniform. Is this correct? Or can I use the timeVaryingUniformFixedValueFvPatchField without modification?
Otherwise, can one specify one boundary to be computed? How does one resolve this in the code? I guess that in that case one constructs a special code for a specific application, which I don't mind doing, but I'm not too familiar with OpenFoam programming.
best regards

Hello, Is it possible to si
 

Hello,

Is it possible to simply change the boundary in the solver itsself? I tried to modify the boundary for the velocity in this way:

...
vectorField & UBoundaryField = U.boundaryField()[patchID]
...
UBoundaryField[i]=vec;

I tried this with a Couette-flow, setting the boundary to change to fixed (hmm) value but after some time steps the solution diverges, and the results obtained in the first timesteps are not those I expected. I want to set up time and space varying boundary-condtions which I get from another calculation, so It doesn't seem that the solutions mentioned above are favorable in my case!?

Thanks,
Dennis

Hi Dennis, Does your variab
 

Hi Dennis,

Does your variable profile change in time or is it fixed? If fixed, you might be better off setting it up at the beginning of the calculation as a part of the initial condition.

Yes, it is possible (and should be easy) to set up the value of the boundary condition from the code itself. For a fixedValue boundary, the best way would be something like

U.boundaryField()[patchI] == blah blah;

where the double equals sign enforces the assignment irrespective of what the boundary condition actually is. Beware, since the fixedValue b.c. (for example) wants to be fixed, operator=() for it will do nothing!

However, you have to be careful to do this in the right place in the code, because you need to make sure that your (say) inlet fluxes are consistent with the inlet velocities AND that the continuity is satisfied. If this is not the case, the solution will diverge.

As a first step, try taking a simple solver, like scalarTransportFoam and play around with the values in the fixedValue boundary. Once you're happy that this behaves the way you want, try playing around with the pressure-velocity system, keeping in mind the consistency I've mentioned.

Good luck,

Hrv

Hello Hrv, thanks for the h
 

Hello Hrv,

thanks for the help so far. Now another problem arised, I'd by very thankful if you could help me, since I have to hand out my diploma thesis in a couple of days.

I have introduced a tensor-field Pi (Pi=rho*U*U + mu*(gradU+gradUT)...) as the momentum flux tensor, which is placed as div Pi in the matrix for the momentum equation: d/dt(rho*U)+div(Pi)=0


I want to model a Couette flow and specified U at both walls with different velocities, and set p to zeroGradient. All worked fine, the velocity profile fell linear.

Then I changed U,p to zeroGradient for the two walls and Pi to the value I obtained from the first calculation ==> U at both walls is identical, Pi is very small, even at the boundaries I specified!?

What is the problem? Is the system overdetermined, since I set three boundary conditions (U,p,Pi), or is the reason zeroGradient for both wall-velocities? Or should I subtract p from Pi and add it after the Piso-loop?

Hello Hrv, later I want to
 

Hello Hrv,

later I want to implement Pi's boundary as transient BC, that's the reason why I put my message under this topic.

it seems, that I forgot a component of the tensor. Nevertheless, in comparison with case 1 with
- zeroGradient for Pi and p at the Couette walls, and a fixed Velocity for U there,
I obtain now with
- zeroGradient for U and p and Pi equally set to the calculated Pi of case 1 a correct, linear falling velocity profile, but the velocities at the Couette-walls are shifted to case 1. The velocity-difference between the walls is the same as in the first case.

What is going wrong? Or was this result expectable ?

Best regards,
Dennis

Hi Dennis, Firstly, it has
 

Hi Dennis,

Firstly, it has struck me that you are trying to do something a bit out of the ordinary and that you're choosing a (shall we say) "less than optimal" way of doing it.

If you wish to vary the wall drag as a function of time, the easiest way would be to make the viscosity a field and then vary the wall viscosity in any way you want; the rest of the solver need not change.

As for the first message, you have to be careful with the b.c. combinations of U and p, which is not arbitrary because of continuity. Thus, if you do a zero gradient on both U and p you need to make sure global continuity is still preserved (global flux scaling). Secondly, you are indeed allowed to rip out the laplacian from the momentum equation and make it explicit, but this is asking for numerical trouble. You still need a SIMPLE/PISO-like procedure to work in the same way.

I'm not sure about further details of your problem, but hope the above might help you.

Good luck,

Hrv

I'm also trying to implement t
 

I'm also trying to implement the transient BC for total pressure, I followed the words Mr.Weller said

"It would probably be best to start from the totalPressure fvPatchField type in OpenFOAM-1.0.2/src/OpenFOAM/fields/fvPatchFields/derivedFvPatchFields/totalPress ure
Copy those files and rename them as say timeVaryingUniformTotalPressureFvPatchScalarField and do a search/replace for that name in both the H and C file and then add the code which handles the data interpolation from the timeVaryingUniformFixedValue BC in OpenFOAM-1.0.2/src/cfdTools/derivedFvPatchFields/timeVaryingUniformFixedValue"

Now I was stuck at the last one, I don't know which part of the code is responsible for doing the interpolation thing, so if I want to add the code concerning interpolation, which part I should pay attention to. The code is too much to read. Can somebody guide me to finish this? Thank you!

Because the previous discussio
 

Because the previous discussion was based on the old version, now it has been updated to version 1.3. Please come up with the new solution for defining the transient BC. Transient BC for total pressure is important for my simulation, please give me more hint. Thanks!

There are no differences betwe
 

There are no differences between versions 1.2 and 1.3 you should worry about. In any case, this is a very easy job:
- make a copy of the boundary condition and change the name
- go into the updateCoeffs() function in your boundary condition and before you do anything else change p0_ as a function of time.
- recompile and set the b.c. in your simulation

Once you are happy with the implementation, think of a general function that could be used to define the time variation of p0_ you wish to use and define it in terms of parameters. Pull the parameters through the private data, read them from the b.c. dictionary. This will allow you to manipulate the time variation without recompiling the code.

Enjoy,

Hrv

The boundary condition is not
 

The boundary condition is not visible from the solver, i.e. you either did not compile it up properly or it did not link. Put a little print statement in the constructor - when it prints out, you will know that the code is doing what it should.

Right now, the code does not recognise the:

type timeVaryingUniformTotalPressure;

and creates a default b.c. for you, which is why everything fails.

Hrv

I have edited the Make/file as
 

I have edited the Make/file as well as Make/options, why the new boundary condition is still not linked to existing application? The output message was described before this article. Did I miss something?
Thanks!

Hi all, my problem appears
 

Hi all,

my problem appears even earlier. I try to do a timedependent pressureInlet with:
in
{
type timeVaryingUniformFixedValue;
timeDataFileName "inlet.dat";
value uniform 1e5;
}
what I copied from above.

the error message is:
Invalid patch field type 'timeVaryingUniformFixedValue' for patch 'in' in field dictionary 'p'.

So how can I actually use that function?
Thanks a lot
Anja

Hello Dihao Tang, You are n
 

Hello Dihao Tang,

You are not actually linking the library:

LIB_LIBS = \
-L$(FOAM_USER_LIBBIN) \
-lfiniteVolume

The second line should say

-L$(FOAM_USER_LIBBIN) -lfoamUser

The first bit says where to look for your library and the second which library to use. I assume you have compiled your new b.c. into the foamUser library.

Hrv

Hi Anja, What is the type o
 

Hi Anja,

What is the type of the patch "in" in the constant/polyMesh/boundary? (there's nothing wrong with the b.c.).

Hrv

Well, the type of "in" is patc
 

Well, the type of "in" is patch, like:

in
{
type patch;
physicalType pressureInlet;
nFaces 1218;
startFace 1145638;
}
This is what I've got in constant/polyMesh/boundary

Anja

Hmm, where do you get this mes
 

Hmm, where do you get this message from - are you by any chance trying to use FoamX? If so, just run the solver from the command line and tell me whant happens.

Hrv

Ok, the new problem arises as
 

Ok, the new problem arises as you implied, I didn't compile my new BC into the foamUser library. Thanks for your tip. But how do I compile the new BC? What I did is to add "$(derivedFvPatchFields)/timeVaryingUniformTotalPressure/timeVaryingUniformTotal PressureFvPatchScalarField.C" in /workdir/flux1/e7guest/OpenFOAM/OpenFOAM-1.3/src/finiteVolume/Make/files, and then wmake. Sorry I'm not familiar with this.

Compiling the wrong file: you
 

Compiling the wrong file: you should compile the one with template instantiations in it:

timeVaryingUniformTotalPressureFvPatchScalarFields .C

Note that "s" in the end that you are missing.

Hrv

Hi Hrv, so you can see what
 

Hi Hrv,

so you can see what I have written in constant/polyMesh/boundary and a little earlier in the thread what is in /0/p for "in".

Then I'm trying to use FoamX:
--> FOAM Warning :
From function FoamX::IGeometricFieldImpl::load(const dictionary& fieldDict)
in file IGeometricFieldImpl.C at line 488
Invalid patch field type 'timeVaryingUniformFixedValue' for patch 'in' in field dictionary 'p'.

And I'm very sorry for the next question, but do I have to compile
timeVaryingUniformFixedValueFvPatchFields.C
before? I have tried to as there is a Make file within /src/cfdTools/general, but I didn't work.

Anja

Don't use FoamX - this is to d
 

Don't use FoamX - this is to do with the config files for your application and they have not been set up for the time varying boundary condition. If you use it from the command line all will be well.

You do not need to compile the b.c. because it is already in the library. By the way, are you using OpenFOAM-1.2 or 1.3? (you should really switch to the latest version).

Have fun,

Hrv

I am still using 1.2. Agai
 

I am still using 1.2.

Again sorry, but how can I start the case from the command line?

Oh, I'm having fun (grrrr).
Anja