[Nek5000-users] pressure normalisation in periodic flows

Fri Feb 24 12:42:21 CST 2012

Dear Philipp,

Thank you for your email.  I think I understand the issue... Without
yet verifying it, my guess is that we never explicitly orthogonalize
p itself, but only dp and thus if there is somehow drift in the mean
of p it is not corrected.

At this point, this is just a hypothesis... I'll try to verify.

Best regards,

Paul

On Fri, 24 Feb 2012, nek5000-users at lists.mcs.anl.gov wrote:

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