[Nek5000-users] Failure with TORDER = 3 (P027)

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Fri Dec 9 04:32:55 CST 2011


Geroge,

Can you provide more details. A logfile would be helpful.

Cheers,
Stefan

On 12/7/11, nek5000-users at lists.mcs.anl.gov
<nek5000-users at lists.mcs.anl.gov> wrote:
>
> Hi George,
>
> That would seem unnecessary... It could simply be the case
> that you are facing lack of resolution.
>
> Also, have you already experienced transition to a fully
> turbulent state?   The transition phase normally takes more
> resolution to get through because of the intense vortex
> stretching.   Additional filtering usually cures this, however.
>
> Given that you've already tried this, perhaps this is something
> we need to look at.  If you want me to look in detail at the
> case that blows up, contact me off list and we can arrange a
> file transfer.
>
> Regards,
>
> Paul
>
>
>
>
> On Wed, 7 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote:
>
>>
>> Hi Paul,
>>
>> Thanks for the quick answer. I have been using a fixed time-step. After a
>> suggestion from Johan, I will try to overintegrate with lxd \approx 2*lx1,
>>
>> since I use a curved geometry. In addition, it might be useful to try with
>> an
>> even polynomial order? (Since my problems start as I change from N=5 to
>> N=7,
>> maybe N=8 is better?)
>>
>> George
>>
>> Quoting nek5000-users at lists.mcs.anl.gov:
>>
>>>
>>> Hi George,
>>>
>>> Is your timestep size variable? or fixed?
>>>
>>> You can fix it (highly recommended) by setting it to the value
>>> you want, but negative  (e.g., param 12 = -.001 in the .rea file
>>> would imply that DT=.001 for all timesteps).
>>>
>>>> From what you describe, I am guessing that this is the issue.
>>> In particular, variable timestepping + projection has some difficulties.
>>>
>>> With dealiasing and filtering, I never have problems with Torder=3,
>>> and I would recommend using this.  I concur, however, with Johan
>>> that Torder=2 is more stable.  (See the CRAS article with J. Mullen
>>> in 2001.)
>>>
>>> I hope this helps - please let us know if problems persist.
>>>
>>> Paul
>>>
>>>
>>> On Wed, 7 Dec 2011, nek5000-users at lists.mcs.anl.gov wrote:
>>>
>>>>
>>>> Dear All,
>>>>
>>>> I have been conducting a direct numerical simulation of turbulent pipe
>>>> flow
>>>> using nek5000 at a moderately high Reynolds number (at present
>>>> Re_tau=550).
>>>> For this, I have to use a very fine grid in order to capture the flow
>>>> physics accurately (for a length of 25R, I am using a total of 450
>>>> million
>>>> grid points when assuming a polynomial order 7). However, I have been
>>>> having
>>>> problems with the stability of the code when using TORDER = 3, i.e.
>>>> parameter 027. The way I conducted my simulation was as follows:
>>>>
>>>> - I started with polynomial order 3, TORDER set to 3, and run for 4 flow
>>>> through times, starting from random noise. At this point I had the
>>>> projection parameters, i.e. P094 and P095 set to non-zero values.
>>>>
>>>> - Afterwards, I increased the polynomial order to 5, with TORDER kept at
>>>>
>>>> 3,
>>>> and ran for another 2 flow through times. Here, I set the projection
>>>> parameters P094 and P095 to zero.
>>>>
>>>> - Now, starting from the last field of the previous run, I changed to my
>>>> target polynomial order 7, and keeping TORDER = 3. However, the codes
>>>> explodes shortly after restarting. The error is: "failed in HMHOLTZ."
>>>> I also tried a considerably lower time-step, but the problem persisted.
>>>> Meanwhile, when I change TORDER to 2, the code runs fine and does not
>>>> explode. The "physical" results are absolutely fine, and the statistics
>>>> I
>>>> get are in perfect agreement to our expectations.
>>>>
>>>> I did not get the same problem while running a turbulent pipe flow at a
>>>> lower Reynolds number (Re_tau=180) and with less grid points.
>>>>
>>>> Probably also of importance, I did test with various ways of restarting,
>>>> i.e. storing in fld or f files, using 4 or 8 byte accuracy, and storing
>>>> multiple consecutive fields for the multi-step time scheme. None of
>>>> these
>>>> changes made significant impact. Also, I am using overintegration and
>>>> filtering (0.01 in parameter P103); increasing the filtering (by a
>>>> factor
>>>> of
>>>> 5) did also not help.
>>>>
>>>> I am wondering if any faced a similar issue before, and if would have an
>>>> insight on how to tackle it. Could my problem maybe be related to the
>>>> restart-issue that Adam brought up recently?
>>>>
>>>> Best regards
>>>> George
>>>>
>>>> ----------------------------------------------------------------
>>>> 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.
>> _______________________________________________
>> 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
>



More information about the Nek5000-users mailing list