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

[hjasak]

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 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 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

[hjasak]

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

[tangd]

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!

[tangd]

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!

[hjasak]

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

[hjasak]

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

[tangd]

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!

[anja]

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

[hjasak]

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

[hjasak]

Hi Anja,

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

Hrv

[anja]

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

[hjasak]

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

[tangd]

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.

[hjasak]

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

[anja]

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

[hjasak]

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

[anja]

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