[Nek5000-users] tubChannel - neknek script

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

Paul, Yulia,

thank you for your help.

Marco

> On Mar 21, 2017, at 2:03 PM, nek5000-users at lists.mcs.anl.gov wrote:
> 
> 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
> 
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4215 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20170321/5b6f7881/attachment-0001.bin>