[Nek5000-users] pressure normalisation in periodic flows

Mon Mar 5 08:03:47 CST 2012

Dear Paul,

Thank you for your reply. We agree with your point of view. Meanwhile,  
the pressure, after being orthogonalized for several time-steps in  
USERSCHK, didn't drift again and the values were around zero.

Best regards
George

Quoting nek5000-users at lists.mcs.anl.gov:

>
> 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
> _______________________________________________
> 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.