[Nek5000-users] Boundary nodes cordinates and random generator

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

Hi,
I typically use ran1 in fact. It is simple, and portable. Of course, not 
too many different numbers are created, but should be enough for the 
purposes of inflow conditions. But, perhaps I am not sure I understand 
fully, you would need to create these random numbers just once when you 
start the simulation, and then just evaluate the complex exponentials? 
At least in my implementation I do not re-create random numbers.

For the coordinates, I guess you get them in userbc, where you can 
check, depending on your geometry, on what boundary you are.

Philipp

On 2018-10-16 20:31, nek5000-users at lists.mcs.anl.gov wrote:
> 
> Yes I need some temporal correlation as well. In fact for me evaluating the complex exponential part is okay, the problem was computational expense for generating random number for 150 modes for theta,Phi,Psi and Alfa. I used the built in function of fortran and I experience Segmentation fault in my computer and when I use the code from Numerical recipes (subroutine ran1) it works well. But I just want to know why this happens and what are the other possible solutions.
> 
> By using the ran1 code from Numerical recipe, 150X4 = 600 random numbers are generated at each time step for the random Fourier mode velocities.
> 
> Or is there anyway solutions to cut down the number of random numbers by slightly any change in the Fourier mode?
> 
> And finally regarding the co ordinates of the inlet boundary is there any quick way to get it?
> 
> 
> Regards
> 
> Sijo GEORGE
> 
> 
> Your replay for my last question:
> 
> But I guess you want some temporal correlation as well, i.e. your modes
> will evolve as a harmonic signal also in time? Typically, we chose a few
> modes (say 150) with random wavenumbers and phases, but then we just
> evolve them in space and time. So the problem is then rather to evaluate
> the complex exponential (i.e. cosine and sine signals) than random numbers.
> 
> So in that case, one needs to have a RNG that works well in parallel and
> you can restart a simulation without "kinks".
> 
> But if you do not need these properties, I would say that computing 150
> random numbers is not very expensive. I typically use a quite "simple"
> generator from Numerical recipes, just because it is portable and gives
> the same numbers on all machines.
> 
> Philipp
> 
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>