Boundary Conditions

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
cwinant
Posts: 17
Joined: Wed Apr 08, 2020 9:54 pm

Boundary Conditions

Post by cwinant »

In the case where BC on adjacent boundaries are different (for example wall and sliding wall), which condition is imposed at the intersection. To be clear in the Cavity totorial are the upper corner points moving or still?

In a similar problem I need to impose a boundary condition on the normal gradient of the velocity (du/dy) rather that on the velocity (corresponding to a wind stress acting over a swimmimg pool for example). Could someone tell me where I can find pertinent references, and if there are sites where similar problems have been solved.

Many thanks
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Boundary Conditions

Post by Yvan Fournier »

Hello,

Boundary conditions are defined at face centers, so there are no "intersections".

For the boundary conditions you need, I am not sure I have any examples. Do you want a Neumann BC type for the velocity, or simply apply a driving force based on a stress ?

In the first case, the graphical interface does not propose that, but I would guess using user-defined subroutines (cs_user_boundary_conditions), using the appropriate "icodcl/rcodcl" BC code could work. I cancheck with other developers, and I'll be happy to let someone else answer that.

Otherwise, using a velocity source term on the matching boundary cells based on that gradient would seem to map well to a driving force computed based on the stress.

Best regards,

Yvan
cwinant
Posts: 17
Joined: Wed Apr 08, 2020 9:54 pm

Re: Boundary Conditions

Post by cwinant »

Hi Yvan

Your team is awesome for prompt replies. Thanks so much for that, and thanks much more for this incredible tool.

In fluids the classic cavity flow comes in two flavors: lid-driven, where the velocity is prescribed on the open boundary and shear driven, where the stress (du/dy) is prescribed on that boundary. The literature is incredibly confusing about this. What is important is that I am looking at prescribing du/dy on the top lid.

I am not sure of the innards of code saturne. In my finite element code, I impose a non-homogeneous Neumann condition at each point on the top boundary

Everything else in the setup of the cavity tutorial remains the same (with the minor exception that I have variable aspect ratio cavities). Eventually I want to let the flow become three-dimensiona, but I have to climb up the learning curve first.

Thanks again.
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Boundary Conditions

Post by Yvan Fournier »

Hello,

A colleague suggests trying the "ifrent" boundary condition code, but there is no example on our validation suite for this type of use yet, so I am not sure how to use it in this context or if it is really the best solution here.

Note that when using a wall law, the sliding velocity already translates from a "no slip" to a sort of friction velocity, but in your case, with 2 fluids, the wind may also be slower due to the air zone's shear layer.

If you simply want to impose a non-homogeneous Neumann condition, you can try a regular setup in the GUI, then in the cs_user_boundary_condition.f90 user subroutine, select the wall zone, and apply "icodcl(ifac, ivar) = 3" for ivar = iu, iv, and iw (velocity components) velocity variable, with the matching rcodcl(ifac, ivar, 3) value for the flux. Check existing examples of cs_user_boundary_conditions in the Doxygen documentation or user_examples sources for the general loop and syntax logic.

Hoping that this will work.

Best regards,

Yvan
cwinant
Posts: 17
Joined: Wed Apr 08, 2020 9:54 pm

Re: Boundary Conditions

Post by cwinant »

Hi and thank you for your clear instructions. I have written subroutine cs_user_boundary_conditions.f90 and placed it in CASE3/SRC. To be clear, what I want to do is replace the Dirichlet condition on u in my sliding wall by a condition on du/dy. Both v and w should remain zero.
.............
!--------
! Formats
!--------
!! Apply flux condition on u only
call getfbr('??????', nlelt, lstelt) !What should the string be for sliding wall

do ilelt = 1, nlelt

ifac = lstelt(ilelt)
icodcl(ifac,iu)=3 ! Neumann
icodcl(ifac,iv)=1 ! Dirichlet
icodcl(ifac,iw)=1 ! Dirichlet

rcodcl(ifac,iu,3)=1 ! non-homogeneous Neumann
rcodcl(ifac,iv,1)=0 ! homogeneous Dirichlet
rcodcl(ifac,iv,1)=0 ! !--------
! Formats
!--------
!! Apply flux condition on u only

call getfbr('??????', nlelt, lstelt) !What should the string be for sliding wall

do ilelt = 1, nlelt

ifac = lstelt(ilelt)
icodcl(ifac,iu)=3 ! Neumann
icodcl(ifac,iv)=1 ! Dirichlet
icodcl(ifac,iw)=1 ! Dirichlet

rcodcl(ifac,iu,3)=1 ! non-homogeneous Neumann
rcodcl(ifac,iv,1)=0 ! homogeneous Dirichlet
rcodcl(ifac,iv,1)=0 ! homogeneous Dirichlet

end do


..............
I am still unsure about the following:

(1) What should the first argument in the call to getfbr be to specify the sliding wall. I have looked through the 6.0 user manual and the Doxygen doc but couldn't find anything (surely my fault)

(2) Do I understand correctly that once this code is placed in /SRC, the GUI will understand that it needs to be compaled ank linked to cose-saturne before execution?

(3) This is off-topic, but I want to be able to work with the final values of u, v, w and p with my own post processing. What would be the best way to obtain a files with those variables? Only thing I can come up with is to generate a csv file of watchpoints that includes a point for each node?

PS Is there a better way to include code snippets?
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Boundary Conditions

Post by Yvan Fournier »

Hello,

1) The string for the sliding wall is your boundary zone selection string (usually simply the name of the mesh group matching that wall, otherwise a geometric criteria); in the documentation searching for "selection crit" should get you in the right sections. This is in the pdf user documentation (and is moved to the Doxygen documentation in upcoming version 6.2).

2) Yes that is correct.

3) A profile is probably better than a simple series of probes, but you can also extract sections from the checkpoint files using the "code_saturne bdump" command (though this will not contain the cell centers).
The simplest solution is probably to generate the regular postprocessing output, and extract cell center coordinates and output the required fields using ParaView or scripts using VTK.

For code_snippets, you can use the "code display" mode in the toolbar for editing posts. Not perfect, but better than nothing.

Best regards,

Yvan
cwinant
Posts: 17
Joined: Wed Apr 08, 2020 9:54 pm

Re: Boundary Conditions

Post by cwinant »

Hi

You won't be surprised the hear that my 1st try failed. The compiler compiled with only warnings about unused variables, but the execution threw errors. I have attached a tar file with the cs_user... .f90 file from the SRC directory, the file named error found in 20200601-1700, and the entire post-processing directory. In ParaVis , when I looked at ERROR.case, I could only see zero velocities, which would suggest I have not implemented the flux BC properly.

If you ever have a moment to look at this, it would be great, if you don't, believe me, I understand
Attachments
trouble.tar
(760 KiB) Downloaded 238 times
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Boundary Conditions

Post by Yvan Fournier »

Hello,

The BC's for the velocity components are not independent, so you should use Neumann for all. Also, I am not sure we have tested this type of combination before, so can't guarantee it will work (a backup solution would be to use velocity source terms near the boundary).

Could you post the rest of the setup data ? I can try to take a quick look this week.

Best regards,

Yvan
cwinant
Posts: 17
Joined: Wed Apr 08, 2020 9:54 pm

Re: Boundary Conditions

Post by cwinant »

Hi and many thanks for your help. I am attaching a new tarball motrouble.tar which has the same files as yesterday with the xml and med files used in those runs. Those two files, without the cs_user_boundary_conditions.f90 in /SRC, give the proper solution for a lid-drven cavity (constant u velocity at the top).

You say that flux BC on velocities have to be the same for the three components u, v and w. From a fluid point of view this is not necessary; in this case one actually needs to impose v (or w) =0, since otherwise the domain changes shape.
Attachments
motrouble.tar
(1.14 MiB) Downloaded 237 times
Yvan Fournier
Posts: 4070
Joined: Mon Feb 20, 2012 3:25 pm

Re: Boundary Conditions

Post by Yvan Fournier »

Hello,

I'll try to take a look tomorrow. In our case, since the velocity components are coupled, we cannot use Dirichlet BC's on the other velocity components with the current code (we would need hybrid BC's, which we do not have in a form suited for this as far as I know, allowing both "sliding" and Neumann conditions), so the crash might be related. I'll try to check.

What you are trying to do seems very similar to how wall laws are handled internally (flow tangential to wall, with friction computed), but I have to think about how to express that in terms of available user boundary conditions...

Best regards,

Yvan
Post Reply