April 2018 - Nek5000-users - mailman3.cels.anl.gov

Re: [Nek5000-users] reading rm2 files
by nek5000-users＠lists.mcs.anl.gov 30 Apr '18

30 Apr '18

Hi, I dont think increasing the ldimt can solve the problem. Currently it set to be 3.

1 0

Fwd: 3D Taylor-Green vortex - error
by nek5000-users＠lists.mcs.anl.gov 30 Apr '18

30 Apr '18

Hi all, This is my second day with Nek5000. Day one was to go through the process of setting up the simulations with example eddy case and periodic hill case running fine on a single core of local workstation. I was hoping to run the 3D Taylor-Green vortex case (described in https://www.grc.nasa.gov/ hiocfd/wp-content/uploads/sites/22/C3.3_Twente.pdf) very quickly to compare the CPU wall clock time with OpenFOAM. Ideally I'd like to run a 16^3 elements cubical box [-pi,pi] with polynomial order 4 providing 64^3 degrees of freedom. I'm targeting 28-84 cores. The boundary conditions of the case are triply periodic and initial conditions are defined as trigonometric expressions of space. I didn't know how to write expressions such as sin(x)cos(y)sin(z) in Nek5000. So, I tried with initial condition uy=uz=0 and ux=1. I keep getting the following error with my set up: """ makenek - automatic build tool for Nek5000 generating makefile ... build 3rd-party software ... ‘tgv.usr’ -> ‘tgv.f’ mpif77 -c -O2 -fdefault-real-8 -fdefault-double-8 -cpp -DMPI -DUNDERSCORE -DTIMER -I/gpfs/home/lboro/ttvs3/Nek5000/run/tgv -I/gpfs/home/lboro/ttvs3/Nek5000/core -I./ /gpfs/home/lboro/ttvs3/Nek5000/run/tgv/tgv.f -o obj/tgv.o mpif77 -O2 -fdefault-real-8 -fdefault-double-8 -cpp -DMPI -DUNDERSCORE -DTIMER -I/gpfs/home/lboro/ttvs3/Nek5000/run/tgv -I/gpfs/home/lboro/ttvs3/Nek5000/core -I./ -o nek5000 obj/tgv.o obj/drive.o obj/drive1.o obj/drive2.o obj/plan5.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o obj/mvmesh.o obj/ic.o obj/gfldr.o obj/ssolv.o obj/planx.o obj/math.o obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/intp_usr.o obj/cvode_driver.o obj/nek_comm.o obj/vprops.o obj/makeq_aux.o obj/papi.o obj/nek_in_situ.o obj/reader_rea.o obj/reader_par.o obj/reader_re2.o obj/finiparser.o obj/iniparser.o obj/dictionary.o obj/hpf.o obj/mxm_std.o obj/comm_mpi.o obj/singlmesh.o obj/blas.o obj/dsygv.o -L/gpfs/home/lboro/ttvs3/Nek5000/3rd_party/gslib/lib -lgs -L/trinity/shared/apps/local/bzip2/1.0.6/1/lib -I/trinity/shared/apps/local/tk/8.5.13/1/lib -I/trinity/shared/apps/local/tcl/8.5.13/1/lib -L/trinity/shared/apps/local/zlib/1.2.11/1/lib obj/drive2.o: In function `dofcnt_': drive2.f:(.text+0x8d50): relocation truncated to fit: R_X86_64_PC32 against symbol `scrns_' defined in COMMON section in obj/convect.o obj/plan5.o: In function `midstep_': plan5.f:(.text+0x186): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan5.f:(.text+0x379): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan5.f:(.text+0x391): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan5.f:(.text+0x3c9): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o obj/plan4.o: In function `crespsp_': plan4.f:(.text+0x9db): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan4.f:(.text+0xb1a): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan4.f:(.text+0xc79): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan4.f:(.text+0xd7a): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan4.f:(.text+0xd90): relocation truncated to fit: R_X86_64_32S against symbol `scrns_' defined in COMMON section in obj/convect.o plan4.f:(.text+0xda3): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status make: *** [nek5000] Error 1 """ In your experience, the error is related to my compiler/mpi or the set up files? If latter, can anyone be kind enough to check out my set up files please? If you want to save time and have done this case before, you can share those files from the past. Any input is highly appreciated. PS- Thanks Prof. Fischer for your reply. Hope this one is more clear. Cheers, Vishal

1 5

reading rm2 files
by nek5000-users＠lists.mcs.anl.gov 30 Apr '18

30 Apr '18

Hi Nek, what I can do for the following warning? Open file: rm2.list 1Reading: rm2pp0.f00001 Reading checkpoint data WARNING: restart file has a NSPCAL > LDIMT read only part of the fld-data! WARNING: NPSCAL read from restart file differs from currently used NPSCAL!

1 1

Re: [Nek5000-users] Finite-amplitude disturbance based on os7000
by nek5000-users＠lists.mcs.anl.gov 27 Apr '18

27 Apr '18

Dear all, First of all, thank you a lot for your help and feedback. The amplitude of ux’ in my case is 1.82E-1 which is superimposed on the base flow u = 1 – y**2 along with uy’ (this setting is identical to the literature paper). An order of BDF 3 is employed. Polynomial order is 8 with 4 elements in streamwise direction and 12 elements in the wall-normal direction. 1 wave length is simulated in the channel. The default setting of os7000 was what I started. I have also tried to increase the spatial resolution, and reduce the time steps (dt = 0.05, 0.01, 0.005). However, it did not really change anything. The distortion is less obvious if the magnitude of perturbation is decreased and totally disappears if it is as small as 1.82E-3. Again, thank you a lot for the help and I will further explore the parameters and see what I can find. Regards, Emily

1 1

Finite-amplitude disturbance based on os7000
by nek5000-users＠lists.mcs.anl.gov 27 Apr '18

27 Apr '18

Dear Nek users, I run into a problem when I tried to realize a 2D finite-amplitude disturbance in the plane poiseuille flow (based on example of os7000). The code was compiled successfully and the initial conditions (base + disturbance) were all good (I verified the profiles with the literature). Both of the base flow (u = 1-y^2) and perturbation are set in the useric subroutine. Periodic boundary condition is employed. one wavelength is simulated. However, after the simulation starts, the perturbations somehow do not really evolve correctly; the wave shape along the streamwise was somehow distorted especially for the first few time steps (both ux' and uy'). After that, it recovered a bit but never went back to the perfect shape same as that in literature at later time steps. This issue yields some significant discrepancy with the available literature paper. I wonder if this could be due to the non-linear effect. Could anyone help me on this please? Regards, Emily

1 2

Finite-amplitude disturbance based on os7000
by nek5000-users＠lists.mcs.anl.gov 27 Apr '18

27 Apr '18

Dear Emily How much is the amplitude of your initial perturbation? if it is smaller than 10-3, it is unlikely from the nonlinear effect. I don't know how you solve OS equation, but the Reynold's number in OS equation is generally based on central line velocity. While the Reynold's number in Nek for the channel flow is generally based on mean flow velocity. If the wave was distorted, maybe you should check the shape of the disturbance, and the streamwise wave number alpha (which determines the length of computational domain.) Another reminder is that you need to run this case in temporal mode of OS equation if you use periodic boundary condition. Bien cordialement Zhenrong JING Doctorant (Doctor Candidate) LHEEA Ecole Centrale de Nantes 1 Rue de la Noë, 44321 Nantes, France

1 0

*****SPAM*****Twitter #nek5000
by nek5000-users＠lists.mcs.anl.gov 25 Apr '18

25 Apr '18

Dear NekCommunity, In Aug 2017 we launched @Nek5000 on Twitter! Just give it a shot and see what's happening: https://twitter.com/Nek5000 Please feel free to share your Nek related work (projects, simulations, developments, publications, events, ...) using the hashtag #nek5000. Cheers, Stefan

1 0

MAXNEL change and compiling
by nek5000-users＠lists.mcs.anl.gov 22 Apr '18

22 Apr '18

Hi all, I'm looking to simulat a problem with 287000 cells. On trying to run genmap an error keeps showing up as follows. using default value reading mesh data ... Abort: number of elements too large 287000 change MAXNEL and recompile I changed the MAXNEL flag (In both places) in the maketools file to 300000 and ran ./maketools all. The problem however is still cropping up as before. Are there some additional steps I need to take? Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

1 2

Re: [Nek5000-users] Pipe flow
by nek5000-users＠lists.mcs.anl.gov 19 Apr '18

19 Apr '18

Dear Philipp, Glad to hear from you. Would you please tell me more about the presusre gradient setting, i.e., what ffx should be in terms of different shear? I didnt find any guide to set that online. Kind regards, Zhai

1 1

pipe flow
by nek5000-users＠lists.mcs.anl.gov 18 Apr '18

18 Apr '18

Dear Nekers, I post last time regarding pressure gradient in the pipe flow. Is there anyone know how to do the single phase pipe flow keeping pressure gradient rather than flow rate? Best wishes, Zhai

1 1