makeq in runtime statistics

[turbulentphil]

Dear Neks,

running the rbc example from NekRS v23 provides some runtime statistics at the end of the simulation. One of the steps included in this breakdown is makeq. I've run the example exactly as provided and got 17.6% of time spent for makeq.

Since makef comprises the source term of the NSE equation (userf in Nek5000), I would have guessed that makeq corresponds to the source terms for scalar equations (userq in Nek5000). But we don't assign such a source term in the rbc example.

So what parts of the solution are represented by makeq and thus take up so much time?

Cheers, Philipp

[fischer1]

Makeq and makef build the RHS for the respective transport eqns, which include the advection terms. Most likely you're running with characteristics, which involves subcycling to build the contribution to the material derivative (i.e., advection) term. Because there are multiple substeps in the RK4 integrator, and each of these are fully dealiased, it can take some time to generate. The one thing to be aware of is that if your number of subcycle steps is 1, then you can have CFL ~ 2.0, if the number is 2, you can have CFL ~ 4.0 (assuming you don't start to impact accuracy). So, you should try to match your CFL w/ the number of substeps. For example, if you are running with CFL ~ 0.5, you should simply turn off the characteristics method altogether, because the std BDFk/EXTk scheme is stable up to CFL~0.5. hth, Paul

…

________________________________ From: turbulentphil ***@***.***> Sent: Friday, July 19, 2024 10:26 AM To: Nek5000/nekRS ***@***.***> Cc: Subscribed ***@***.***> Subject: [Nek5000/nekRS] makeq in runtime statistics (Discussion #580) Dear Neks, running the rbc example from NekRS v23 provides some runtime statistics at the end of the simulation. One of the steps included in this breakdown is makeq. I've run the example exactly as provided and got 17.6% of time spent for makeq. Since makef comprises the source term of the NSE equation (userf in Nek5000), I would have guessed that makeq corresponds to the source terms for scalar equations (userq in Nek5000). But we don't assign such a source term in the rbc example. So what parts of the solution are represented by makeq and thus take up so much time? Cheers, Philipp — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/Nek5000/nekRS/discussions/580__;!!DZ3fjg!6myQZVl8kn1-8v-rx3bWsmulCI6sYBKGzamX4VpfMsS8BvjN3pugpqG5OhfzGCDx5SZSUSbTlsb0dc7VOsKVjchal_U$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACV35EOOPGPTE4ZOHAXS2ADZNEV2NAVCNFSM6AAAAABLEZMOUSVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWHE2TGNRUHA__;!!DZ3fjg!6myQZVl8kn1-8v-rx3bWsmulCI6sYBKGzamX4VpfMsS8BvjN3pugpqG5OhfzGCDx5SZSUSbTlsb0dc7VOsKVyEDpl2w$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[turbulentphil]

Dear Paul,

thanks a lot for your answer!
So makeq is related to the characteristics / subcycling. Given that we can increase the time step size by up to a factor of 8 (CFL ~ 4 instead of 0.5), the cost of 17.6% solution time seems to be worth it.

One single follow-up question: You wrote "assuming you don't start to impact accuracy". I suppose you mean the impact of an increasingly coarser resolution in time, correct?

Best,
Philipp

[fischer1]

Dear Philipp, Correct... Obviously if you take too large a timestep you can start having an impact wrt accuracy, even if the scheme is stable. Paul

…

________________________________ From: turbulentphil ***@***.***> Sent: Friday, July 19, 2024 12:00 PM To: Nek5000/nekRS ***@***.***> Cc: Fischer, Paul ***@***.***>; Comment ***@***.***> Subject: Re: [Nek5000/nekRS] makeq in runtime statistics (Discussion #580) Dear Paul, thanks a lot for your answer! So makeq is related to the characteristics / subcycling. Given that we can increase the time step size by up to a factor of 8 (CFL ~ 4 instead of 0.5), the cost of 17.6% solution time seems to be worth it. One single follow-up question: You wrote "assuming you don't start to impact accuracy". I suppose you mean the impact of an increasingly coarser resolution in time, correct? Best, Philipp — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/Nek5000/nekRS/discussions/580*discussioncomment-10097839__;Iw!!DZ3fjg!6y92ieaBmuWPhQc1OncObNV4ISl3MIufvs6i4b2WvEnkbe9VNyyzKIeRPrjdKp-joECaaBqmGQqQJdnAgaYZhgXKP94$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACV35EKORGHWOMCTOZKLWZDZNFA4VAVCNFSM6AAAAABLEZMOUSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBZG44DGOI__;!!DZ3fjg!6y92ieaBmuWPhQc1OncObNV4ISl3MIufvs6i4b2WvEnkbe9VNyyzKIeRPrjdKp-joECaaBqmGQqQJdnAgaYZygZk_98$>. You are receiving this because you commented.Message ID: ***@***.***>