[Nek5000-users] tubChannel - neknek script

[nek5000-users at lists.mcs.anl.gov]

Hi Marco,

Just to follow up on Yulia's reply:

You cannot declare space with nelv, as it is a run-time parameter not known at link time.
You must use lelv.

lelv = upper bound on number of elements per processor.

nelv = number of elements on this processor (when the code is executing)

nelv = number of elements in the mesh (for purposes of .rea file).

If number of processors (mpi ranks) = 1, then nelv in the two preceding definitions are the same.

nelgv = total number of elements in the (non-neknek) simulation -- i.e., nelgv is equal to the
            nelv value in the .rea file.

lelx, lely, lelz are parameters, defined at compile time, that are _sometimes_ (but more and
            more rarely) used to aid in data post-processing when your domain is coming as a 
            monolithic tensor-product-box from genbox.

            lelx,lely,lelz are never needed for simulations.

Indeed, because these are compile-time parameters, you will have difficulty in the neknek
case if your two coupled simulations do not have the same shape.   A different post-processing
strategy is in order.

There is no good automated way that I know of to detect the domain size, particularly in 
parallel.  It could be done, particularly on a case-by-case basis, but it would need some
built in assumptions to work (e.g., that the domain is a monolithic tensor product mesh
built by genbox).

hth,
Paul

________________________________________
From: nek5000-users-bounces at lists.mcs.anl.gov [nek5000-users-bounces at lists.mcs.anl.gov] on behalf of nek5000-users at lists.mcs.anl.gov [nek5000-users at lists.mcs.anl.gov]
Sent: Tuesday, March 21, 2017 11:15 AM
To: nek5000-users at lists.mcs.anl.gov
Subject: [Nek5000-users] tubChannel - neknek script

Hello,

I am running the neknek script with the turbChannel example. My setup consists of two channels: the first one has periodic boundary conditions, and the second one has inlet/outlet boundary conditions. The numerical solution of first channel is used as an inlet condition for the second channel. The numerical solution seems to behave as expected.

My next step is to simulate a short channel with periodic boundary conditions, and a longer one with inlet/outlet boundary conditions. The number of elements in the streamwise direction (x-axis) now differs. This is causing some problems since the number of elements in the x,y and z directions are set in the SIZE file that is unique to the sessions named inside and outside. Note that I need the number of elements in each direction to compute the y+ and u+ values.

In the turbChannel example, the number of elements in the x, y and z directions are defined in the usr file (nelx, nely and nelz). This approach could work in my case, I think, assuming that I include a if statement on the session name (inside vs outside). However, I am after something more generic that can be applied to more complex geometries where the number of elements in each direction is not known or difficult to know.

Is there a way with Nek5000 to get the number of elements in each direction in a automated way?

I have another question that is a little bit off topic: when initializing an array in the subroutines defined in the usr file, should I use nelv or lelv as the number of elements per processors? In the turbChannel example, both are used and it confuses me. nelv is the maximum number of elements per processor, whereas lelv is the actual number of elements in a processor, which leads me to think lelv should be used. Is this correct?

Thanks,

Marco