[Nek5000-users] pressure normalisation in periodic flows

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Fri Feb 24 12:18:46 CST 2012


Dear Paul,

Thank you for your reply. In regards to the pressure normalization we
have tested the following:

1- Starting from restart files containing the high-pressure values (of
order 10^7). A run was performed for 53 time-steps and in the USERCHK,
we have normalized the pressure as follows:

----------------------------------------------------------------------------

C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C
        common /scrcg/ pm1(lx1,ly1,lz1,lelv)  ! Mapped pressure
        real pa(lx1,ly1,lz1), pb(lx1,ly1,lz1) ! Working arrays for mapp
        integer*8 ntotpg   ! Possibly more than 2 billion pts total
C%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%C

        call my_full_restart  ! save/load files for full-restart

        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
        call cadd(pr,pbar_phy,ntotp)

----------------------------------------------------------------------------

After the run ended, the pressure values were around zeros. For
several runs after-wards with the above procedure in the USERCHK taken
away. The pressure was fine and it didn't spike again.

Meanwhile:

2-   Starting from the same set of files  (containing the  
high-pressure values). A run was performed for 153 time-steps with no  
pressure normalization in the USERCHK as before. Here, we looked at the

subroutine ortho (respr)

in navier1.f and printed out the values of respr,rlam.  These were of  
order 1E-07 and E-012. However, during the run the pressure was high,  
and this was noticed by printing out (pr) in the USERCHK where the  
values were of order 10^7.

Best regards

George


Quoting 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
>>
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



More information about the Nek5000-users mailing list