[Nek5000-users] pressure normalisation in periodic flows

[nek5000-users at lists.mcs.anl.gov]

Dear Philipp,

Thank you for the detailed note.

The normal way to orthogonalize would be:

       call ortho(pr)

One has to be careful in this context since there are two
types of orthogonalization to consider.  One is where you
remove the kernel of the pressure matrix (i.e., the vector
of all 1's), the other is where you remove the physical
mean.  These values are defined as follows:

     pbar_alg = sum_i=1,n (p_i) / n

     pbar_phy = int p dV / volume

Currently, ortho() does the former, since that is the
condition we are trying to satisfy in the iterative solvers.
Which condition is best for you is not 100% clear to me, but
it is probably a fine point that is not of leading-order
importance.  In any case, you can evaluate these as follows:

       include 'SIZE'
       include 'TOTAL'

       integer*8 ntotpg   ! Possibly more than 2 billion pts total

       ntotp  = nelv*nx2*ny2*nz2
       ntotpg = ntotp
       ntotpg = i8glsum(ntotpg,1)          ! Input must be integer*8
       pbar_alg = glsum(pr,ntotp)/ntotpg

       pbar_phy = glsc2(pr,bm2,ntotp)/volvm2

What is more curious is, why is the pressure spiking?
If you have a repeatable case where this happens, I'd
be happy to dig into it.  Please feel free to contact
me off-list if you'd like to transfer some files.

I'm happy to hear that the new restart feature avoids
this problem.

Best regards,

Paul




On Tue, 21 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote:

> Dear all,
> We are running turbulent pipe flow. During these runs we have observed some
> interesting behaviour of the instantaneous pressure, namely its mean value
> can be of order 10e7 depending on the run. We have tried various ways to
> bring that mean instantaneous pressure down to around zero, but we only
> succeeded partially. Of course, for computing the flow statistics (such as
> <p> and prms) we do have an additional normalisation based on the mean wall
> pressure, but having such a high "computational" pressure may lead to loss
> of precision which we would like to avoid.
>
> Therefore, we have a few questions which we tried to figure out during the
> last weeks:
> 1) from the Deville, Fischer and Mund book (and previous channel
> experiences) we assume that nek5000 will in the case of periodic bc (that is
> without any "O" condition) set the mean instantaneous pressure to zero. For
> some of our runs this is most probably fulfilled (checked only
> graphically...). Which routine would you suggest to use to do a volume
> average of the pressure (pnpn-2)?
> 2) Some of our runs were initially ran using the older restart scheme with
> only a single field/single precision. Since a few weeks we are exclusively
> using the newer restart option with four previous fields/double precision.
> The runs that were originally run with the old restart option are the ones
> that experience the high pressure values, whereas the cases that were only
> run (i.e. from the initiation with random noise) with the new restart have
> "correct" pressure levels (i.e. around zero).
> We would like to reduce the high pressures from the older runs. We have
> tried many things; subtracting a mean pressure in userchk, removing the wall
> pressure during the run etc., but none of these options completely solved
> our issue (i.e. the pressure was rising again). Would there be an option to
> restart nek without specifying a pressure?
> 3) To learn more about how nek is really doing the normalisation, which part
> of the code is doing the p-normalisation?
>
> By the way, we are using PnPn-2, mainly because our experience is that we
> are faster for our case.
>
> Thanks a lot for any help!
> Philipp
>
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>