Can someone tell me why I get the strange output in listing (zero residuals and the message “Incoming flow detained on faces…”)
This happened when I started attempting to use the les inflow module with the SEM enabled. Please refer to my SRC and listing (both contained inside the zip file)
SRC.zip (119 KB)
Hello,
Difficult to say with only your user subroutines, not knowing your CFL, mesh, and other settings.
Regards,
Yvan
Hello,
You can see the listing file inside the Same directory of SRC. I can’t post my mesh because it’s too big but in general it is a good quality hexahedron mesh. The CFL number is as you can see in the listing file. I have also tried with much smaller time steps but the result is the same. I find it a bit strange that the reported mass flow is zero in the listing file so surely I am doing something wrong in the way I set up the case in the subroutines? I’m not sure what else it could be!
Kind regards,
Oscar
Hello,
You have “not a number’s” for the inlet and wall mass flows starting at the first time step, so the best solution would be to run your case under a debug build, which would catch the first such error and help detect its origin. You can also increase the verbosity of the inflow method.
Did you try other LES inflow options ?
Regards,
Yvan
Thanks for the quick reply. I am not sure how to activate the debug build as I am running on a cluster and I don’t think I can pick and choose at the moment. However I will try the other Les inflow options and see if that solves the NaN problem. If you would like I can also send you the actual mesh input via a google share or Dropbox if that helps.
Ok so the problem does not seem to be with the type of turbulence method because when I run without the advanced subroutine in the cs_user_les_inflow.f90 I now have correct looking mass fluxes at the inlet and outlet! Could it be that I am simply inadvertently assigning zero inlet velocity when using the advanced subroutine? I reproduce the advanced subroutine from my original attachment below:
subroutine cs_user_les_inflow_advanced &
( nument , nfbent , &
nvar , nscal , &
lfbent , &
dt , &
uvwent , rijent , epsent )
!===============================================================================
!===============================================================================
! Module files
!===============================================================================
use paramx
use numvar
use optcal
use entsor
use cstphy
use cstnum
use mesh
!===============================================================================
implicit none
! Arguments
integer nument , nfbent
integer nvar , nscal
integer lfbent(nfbent)
double precision dt(ncelet)
double precision uvwent(ndim,nfbent), rijent(6,nfbent)
double precision epsent(nfbent)
! Local variables
integer ii, ifac, iel
double precision d2s3
double precision utau, href, reyfro, yy, yplus, uplus, kplus, eplus
double precision uref2, xdh, xitur, xkent, xeent
double precision, dimension(:), pointer :: cpro_viscl
!===============================================================================
! INSERT_MAIN_CODE_HERE
!if (nument.eq.1) then
! do ii = 1, nfbent
! ifac = lfbent(ii)
! iel = ifabor(ifac)
! uvwent(1,ii) = 1.1d0
! uvwent(2,ii) = 1.1d0
! uvwent(3,ii) = 1.1d0
! uref2 = uvwent(1,ii)**2 &
! + uvwent(2,ii)**2 &
! + uvwent(3,ii)**2
! uref2 = max(uref2,1.d-12)
! ! Hydraulic diameter
! xdh = 0.075d0
! ! Turbulence intensity
! xitur = 0.02d0
! xkent = epzero
! xeent = epzero
! call keenin &
! !==========
! ( uref2, xitur, xdh, cmu, xkappa, xkent, xeent )
! rijent(1,ii) = d2s3*xkent
! rijent(2,ii) = d2s3*xkent
! rijent(3,ii) = d2s3*xkent
! rijent(4,ii) = 0.d0
! rijent(5,ii) = 0.d0
! rijent(6,ii) = 0.d0
! epsent(ii) = xeent
! enddo
!endif
Hello,
I did not notice any obvious mistake in your setting, but can’t be sure without running it.
If your case is not too big, before you send it, you might try it on a workstation. As you only need one restart time step to produce the error, it’s OK if it’s slower.
And it’s not too hard to install a debug build on a station.
Otherwise, dropbox is fine for me. You can send the link as a private message if you prefer (responding to them works only sometimes, but receiving them works fine).
Regards,
Yvan
Hi Yvan,
I found the problem and it was (as expected) a simple mistake on my part. I was not setting the intended velocity at the inlet when specifying the entry velocity in the ‘advanced option’. On this point I have a follow up question regarding this issue: what is the difference between the following three quantities:
\verb|uvwent|, mean velocity at the inlet faces
\verb|vitent| (ref. mean velocity at the inlet) ?
Im guessing that when using the advanced subroutine the uvwent overrides the values in vitent? However what I don’t get is how these two relate to the velocitities we specify in the boundary conditions: e.g. \verb|rcodcl(ifac,iu,1)|. To me they are all specifying the same and thats a bit confusing.