From nek5000-users at lists.mcs.anl.gov Fri Apr 7 10:18:23 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 7 Apr 2017 17:18:23 +0200 Subject: [Nek5000-users] proj_ortho error in pipe flow Message-ID: Dear Nek users, I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 steps, I get this problem (see attachment for complete logfile): Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 1.0526E-02 Solving for fluid 32 Project velx 6.6444E-09 2.4759E-09 2.6836E+00 8 0 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 32 Project vely 6.8730E-09 2.1046E-09 3.2656E+00 8 0 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 32 Project velz 5.2396E-03 2.5121E-06 2.0858E+03 8 0 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 32proj_ortho: 2 8 velz Detect rank deficiency: NaN 1.0000E+00 32proj_ortho: 1 8 velz Detect rank deficiency: NaN 1.0000E+00 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 1.0000E-08 8.7926E-03 1.7780E-02 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 7.85399E-01 volflow Z 32 Fluid done 3.2000E-02 2.4042E-02 In the next step I get CFL, CTarg! and the simulation exits. This problem does neither show up on my local machine nor on another smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I do not see this error. It only appears when p94 and p95 are both unequal 0. In my case I set them to 9. Do you know what might be causing this issue and how to solve it for the Cray XC40 system? Best Regards Steffen -------------- next part -------------- Starting at Fri Apr 7 16:47:45 CEST 2017 Hosts: eslogin002.hww.de Nodes: 1 Processes per node: 24 Cores: 24 ------------------ /----------------------------------------------------------\\ | _ __ ______ __ __ ______ ____ ____ ____ | | / | / // ____// //_/ / ____/ / __ \\/ __ \\/ __ \\ | | / |/ // __/ / ,< /___ \\ / / / // / / // / / / | | / /| // /___ / /| | ____/ / / /_/ // /_/ // /_/ / | | /_/ |_//_____//_/ |_|/_____/ \\___/ \\___/ \\___/ | | | |----------------------------------------------------------| | | | NEK5000: Open Source Spectral Element Solver | | COPYRIGHT (c) 2008-2017 UCHICAGO ARGONNE, LLC | | Version: 17.0.0 | | Web: http://nek5000.mcs.anl.gov | | | \\----------------------------------------------------------/ Number of processors: 24 REAL wdsize : 8 INTEGER wdsize : 4 Timer accuracy : 9.54E-08 Reading /lustre/cray/ws8/ws/xxxxx-nek_tests/nek_runs/pipe/hydro/run/hydro.rea mapping elements to processors Reading /lustre/cray/ws8/ws/xxxxx-nek_tests/nek_runs/pipe/hydro/run/hydro.map 0 32 32 768 768 NELV 1 32 32 768 768 NELV 5 32 32 768 768 NELV 8 32 32 768 768 NELV 2 32 32 768 768 NELV 9 32 32 768 768 NELV 10 32 32 768 768 NELV 4 32 32 768 768 NELV 11 32 32 768 768 NELV 3 32 32 768 768 NELV 18 32 32 768 768 NELV 12 32 32 768 768 NELV 20 32 32 768 768 NELV 7 32 32 768 768 NELV 6 32 32 768 768 NELV 23 32 32 768 768 NELV 22 32 32 768 768 NELV 21 32 32 768 768 NELV 19 32 32 768 768 NELV 15 32 32 768 768 NELV 16 32 32 768 768 NELV 14 32 32 768 768 NELV 17 32 32 768 768 NELV 13 32 32 768 768 NELV RANK 0 IEG 108 112 117 118 119 120 300 304 305 306 309 310 311 312 492 494 496 497 498 501 502 503 504 684 686 688 689 690 693 694 695 696 element load imbalance: 0 32 32 done :: mapping elements to processors 0 objects found 118 Parameters from file: 1 1.00000 P001: DENSITY 2 -5300.00 P002: VISCOSITY 7 1.00000 P007: RHOCP 8 1.00000 P008: CONDUCT 11 103.000 P011: NSTEPS 12 -1.00000E-03 P012: DT 13 20.0000 P013: IOCOMM 15 10.0000 P015: IOSTEP 21 1.00000E-08 P021: DIVERGENCE 22 1.00000E-08 P022: HELMHOLTZ 24 1.00000E-02 P024: TOLREL 25 1.00000E-02 P025: TOLABS 26 0.50000 P026: COURANT/NTAU 27 3.00000 P027: TORDER 54 -3.00000 P054: fixed flow rate dir: |p54|=1,2,3=x,y,z 55 1.00000 P055: vol.flow rate (p54>0) or Ubar (p54<0) 59 0.00000 P059: !=0 --> full Jac. eval. for each el. 66 6.00000 P066: output : <0=ascii, else binary 67 6.00000 P067: restart: <0=ascii, else binary 68 10.0000 P068: STAT_COMP: how often you compute stats 69 50.0000 P069: STAT_OUTP: how often you write stats 70 50.0000 P070: CHKPTSTP: how often you write restart files (rs8) 93 20.0000 P093: Number of previous pressure solns saved 94 9.00000 P094: start projecting velocity after p94 step 95 9.00000 P095: start projecting pressure after p95 step 99 4.00000 P099: dealiasing: <0--> off /3--> old /4-->new 102 1.00000 P102: Dump out divergence at each time step 103 0.01000 P103: weight of stabilizing filter nelgt/nelgv/lelt: 768 768 1200 lx1 /lx2 /lx3 : 5 3 5 done :: read .rea file 0.25736E-01 sec setup mesh topology Right-handed check complete for 768 elements. OK. setvert3d: 5 29456 50192 29456 29456 call usrsetvert done :: usrsetvert gs_setup: 12560 unique labels shared pairwise times (avg, min, max): 1.80612e-05 1.59979e-05 2.01941e-05 crystal router : 1.46588e-05 1.43051e-05 1.49012e-05 all reduce : 0.000158255 0.000156999 0.000159812 used all_to_all method: crystal router handle bytes (avg, min, max): 223072 152956 276732 buffer bytes (avg, min, max): 37301.3 25760 47008 setupds time 8.6558E-03 seconds 0 5 29456 768 8 max multiplicity done :: setup mesh topology call usrdat done :: usrdat generate geometry data NOTE: All elements deformed , param(59) ^=0 done :: generate geometry data call usrdat2 done :: usrdat2 regenerate geometry data 1 NOTE: All elements deformed , param(59) ^=0 done :: regenerate geometry data 1 verify mesh topology -0.500000000000000 0.500000000000000 Xrange -0.500000000000000 0.500000000000000 Yrange 0.000000000000000E+000 1.00000000000000 Zrange done :: verify mesh topology IFTRAN = T IFFLOW = T IFHEAT = F IFSPLIT = F IFLOMACH = F IFUSERVP = F IFUSERMV = F IFSTRS = F IFCHAR = F IFCYCLIC = F IFAXIS = F IFMVBD = F IFMELT = F IFMODEL = F IFKEPS = F IFMOAB = F IFNEKNEK = F IFSYNC = T IFVCOR = T IFINTQ = F IFCWUZ = F IFSWALL = F IFGEOM = F IFSURT = F IFWCNO = F IFTMSH for field 1 = F IFADVC for field 1 = T IFNONL for field 1 = F Dealiasing enabled, lxd= 8 Estimated eigenvalues EIGAA = 9.86960440108936 EIGGA = 450284.517077610 EIGAE = 9.86960440108936 EIGAS = 8.333333333333333E-002 EIGGE = 450284.517077610 EIGGS = 2.00000000000000 verify mesh topology -0.500000000000000 0.500000000000000 Xrange -0.500000000000000 0.500000000000000 Yrange 0.000000000000000E+000 1.00000000000000 Zrange done :: verify mesh topology E-solver strategy: 1 itr mg_nx: 1 2 4 mg_ny: 1 2 4 mg_nz: 1 2 4 call usrsetvert done :: usrsetvert gs_setup: 680 unique labels shared pairwise times (avg, min, max): 1.29193e-05 1.18017e-05 1.37091e-05 crystal router : 5.6078e-06 5.48363e-06 5.72205e-06 all reduce : 1.7484e-05 1.73092e-05 1.75953e-05 used all_to_all method: crystal router handle bytes (avg, min, max): 16252 12052 19156 buffer bytes (avg, min, max): 2465.33 1904 2944 setupds time 1.4441E-03 seconds 1 2 836 768 setvert3d: 4 15180 21324 15180 15180 call usrsetvert done :: usrsetvert gs_setup: 6964 unique labels shared pairwise times (avg, min, max): 1.5373e-05 1.35899e-05 1.76907e-05 crystal router : 1.00841e-05 9.799e-06 1.02997e-05 all reduce : 8.25336e-05 8.18014e-05 8.35896e-05 used all_to_all method: crystal router handle bytes (avg, min, max): 127296 87988 156980 buffer bytes (avg, min, max): 21137.3 14768 26496 setupds time 4.7832E-03 seconds 2 4 15180 768 setvert3d: 3 5640 6408 5640 5640 call usrsetvert done :: usrsetvert gs_setup: 3004 unique labels shared pairwise times (avg, min, max): 1.4472e-05 1.28031e-05 1.63078e-05 crystal router : 6.6479e-06 6.50883e-06 6.69956e-06 all reduce : 3.99897e-05 3.96013e-05 4.05073e-05 used all_to_all method: crystal router handle bytes (avg, min, max): 58356 41020 71068 buffer bytes (avg, min, max): 9525.33 6816 11808 setupds time 2.9030E-03 seconds 3 3 5640 768 setvert3d: 5 29456 50192 29456 29456 call usrsetvert done :: usrsetvert gs_setup: 12560 unique labels shared pairwise times (avg, min, max): 1.54346e-05 1.33038e-05 1.74046e-05 crystal router : 1.46826e-05 1.44005e-05 1.49012e-05 all reduce : 0.000159989 0.000158787 0.0001616 used all_to_all method: crystal router handle bytes (avg, min, max): 223072 152956 276732 buffer bytes (avg, min, max): 37301.3 25760 47008 setupds time 7.5829E-03 seconds 4 5 29456 768 setup h1 coarse grid, nx_crs= 2 call usrsetvert done :: usrsetvert gs_setup: 680 unique labels shared pairwise times (avg, min, max): 1.23511e-05 1.03951e-05 1.38998e-05 crystal router : 4.39882e-06 4.29153e-06 4.48227e-06 all reduce : 1.73748e-05 1.719e-05 1.74999e-05 used all_to_all method: crystal router handle bytes (avg, min, max): 16252 12052 19156 buffer bytes (avg, min, max): 2465.33 1904 2944 done :: setup h1 coarse grid 5.075931549072266E-003 sec call usrdat3 done :: usrdat3 set initial conditions nekuic (1) for ifld 1 call nekuic for vel xyz min -0.50000 -0.50000 0.0000 uvwpt min 0.0000 0.0000 1.0000 0.0000 0.0000 PS min 0.99000E+22 xyz max 0.50000 0.50000 1.0000 uvwpt max 0.0000 0.0000 1.0000 0.0000 0.0000 PS max -0.99000E+22 done :: set initial conditions call userchk 0 0.0000E+00 Write checkpoint FILE: hydro0.f00001 0 0.0000E+00 done :: Write checkpoint file size = 3.0 MB avg data-throughput = 83.0MB/s io-nodes = 24 done :: userchk gridpoints unique/tot: 50192 96000 dofs: 48144 20736 Initialization successfully completed 0.11032 sec Starting time loop ... DT/DTCFL/DTFS/DTINIT 0.100E-02 0.000E+00 0.593-322 0.100E-02 Step 1, t= 1.0000000E-03, DT= 1.0000000E-03, C= 0.023 0.0000E+00 0.0000E+00 Solving for fluid 1 Hmholtz VELZ 1 1.7018E+00 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 2 1.3450E-02 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 3 1.5849E-04 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 4 1.6074E-06 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 5 2.2425E-08 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 6 4.0630E-10 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 5 4.0630E-10 1.7018E+00 1.0000E-08 1 1.00000E-08 2.17259E-13 4.01456E-13 5.41176E-01 1 Divergence 1 U-PRES gmres 1 2.1726E-13 4.0146E-13 1.0000E-08 7.1907E-04 1.1599E-03 1 DNORM, DIVEX 2.198172942125789E-013 2.172586674725858E-013 1 Hmholtz VELZ 1 9.9774E-01 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 2 6.1199E-03 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 3 7.2730E-05 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 4 1.4029E-06 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 5 1.9624E-08 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 6 3.5717E-10 1.8868E-04 1.0000E-08 1.0000E+03 F 1 Hmholtz VELZ 5 3.5717E-10 9.9774E-01 1.0000E-08 1 1.00000E-04 2.83402E-13 4.08036E-13 6.94550E-01 0 Divergence 0 U-PRES gmres 1 2.8340E-13 4.0804E-13 1.0000E-04 3.6812E-04 7.2598E-04 1 7.81677E-04 1.00000E+00 1.00000E+00 basflow Z 1 0.1000000E-02 4.76073E+00 3.72135E-03 7.81677E-01 7.85399E-01 volflow Z 1 Fluid done 1.0000E-03 7.6170E-03 filt amp 0.0000 0.0000 0.0000 0.0000 0.0100 filt trn 1.0000 1.0000 1.0000 1.0000 0.9900 Step 2, t= 2.0000000E-03, DT= 1.0000000E-03, C= 0.023 1.2206E-02 1.2206E-02 Solving for fluid 2 Hmholtz VELX 0 9.4271E-12 9.4271E-12 1.0000E-08 2 Hmholtz VELY 0 9.4227E-12 9.4227E-12 1.0000E-08 2 Hmholtz VELZ 5 2.4847E-10 3.2933E+00 1.0000E-08 2 U-PRES gmres 1 9.4610E-13 1.5322E-12 1.0000E-08 4.5395E-04 7.9298E-04 2 DNORM, DIVEX 9.464175787172753E-013 9.461022252443596E-013 2 Hmholtz VELZ 4 4.0433E-09 9.9774E-01 1.0000E-08 0 U-PRES gmres 1 1.9253E-12 3.1157E-12 1.0000E-04 3.5119E-04 6.8712E-04 2 5.21158E-04 1.00000E+00 1.00000E+00 basflow Z 2 0.2000000E-02 -2.03310E+00 -1.05957E-03 7.86458E-01 7.85399E-01 volflow Z 2 Fluid done 2.0000E-03 6.4468E-03 Step 3, t= 3.0000000E-03, DT= 1.0000000E-03, C= 0.023 2.2941E-02 1.0735E-02 Solving for fluid 3 Hmholtz VELX 0 9.1600E-11 9.1600E-11 1.0000E-08 3 Hmholtz VELY 0 9.1590E-11 9.1590E-11 1.0000E-08 3 Hmholtz VELZ 5 1.0894E-10 3.6725E+00 1.0000E-08 3 U-PRES gmres 1 2.9812E-12 4.7110E-12 1.0000E-08 4.4107E-04 7.8297E-04 3 DNORM, DIVEX 2.981441029198212E-012 2.981214196025064E-012 3 Hmholtz VELZ 4 1.8402E-09 9.9774E-01 1.0000E-08 0 U-PRES gmres 1 7.1775E-13 1.1612E-12 1.0000E-04 3.5119E-04 7.0310E-04 3 4.26414E-04 1.00000E+00 1.00000E+00 basflow Z 3 0.3000000E-02 1.73615E+00 7.40317E-04 7.84658E-01 7.85399E-01 volflow Z 3 Fluid done 3.0000E-03 6.2871E-03 Step 4, t= 4.0000000E-03, DT= 1.0000000E-03, C= 0.024 3.1733E-02 8.7922E-03 Solving for fluid 4 Hmholtz VELX 0 8.4520E-11 8.4520E-11 1.0000E-08 4 Hmholtz VELY 0 8.4533E-11 8.4533E-11 1.0000E-08 4 Hmholtz VELZ 4 5.7268E-09 3.2214E+00 1.0000E-08 4 U-PRES gmres 1 4.0800E-12 7.5439E-12 1.0000E-08 4.3988E-04 7.8201E-04 4 DNORM, DIVEX 4.080101052278270E-012 4.079985609915090E-012 4 0.4000000E-02 2.23876E-01 9.54639E-05 7.85303E-01 7.85399E-01 volflow Z 4 Fluid done 4.0000E-03 3.5310E-03 Step 5, t= 5.0000000E-03, DT= 1.0000000E-03, C= 0.024 3.7650E-02 5.9168E-03 Solving for fluid 5 Hmholtz VELX 0 1.1332E-10 1.1332E-10 1.0000E-08 5 Hmholtz VELY 0 1.1323E-10 1.1323E-10 1.0000E-08 5 Hmholtz VELZ 4 5.5891E-09 3.1424E+00 1.0000E-08 5 U-PRES gmres 1 4.0020E-12 6.0607E-12 1.0000E-08 4.5204E-04 7.9513E-04 5 DNORM, DIVEX 4.002157619691075E-012 4.001992348531620E-012 5 0.5000000E-02 2.20709E-01 9.41133E-05 7.85304E-01 7.85399E-01 volflow Z 5 Fluid done 5.0000E-03 3.5372E-03 Step 6, t= 6.0000000E-03, DT= 1.0000000E-03, C= 0.024 4.5496E-02 7.8461E-03 Solving for fluid 6 Hmholtz VELX 1 6.1591E-13 1.0781E-10 1.0000E-08 6 Hmholtz VELY 1 6.1599E-13 1.0766E-10 1.0000E-08 6 Hmholtz VELZ 4 5.2585E-09 3.0485E+00 1.0000E-08 6 U-PRES gmres 1 1.0207E-11 1.9025E-11 1.0000E-08 4.5419E-04 8.0085E-04 6 DNORM, DIVEX 1.020720384931466E-011 1.020715819732652E-011 6 0.6000000E-02 2.17638E-01 9.28039E-05 7.85306E-01 7.85399E-01 volflow Z 6 Fluid done 6.0000E-03 3.7589E-03 Step 7, t= 7.0000000E-03, DT= 1.0000000E-03, C= 0.024 5.2164E-02 6.6681E-03 Solving for fluid 7 Hmholtz VELX 1 7.4415E-13 1.2102E-10 1.0000E-08 7 Hmholtz VELY 1 7.5130E-13 1.2107E-10 1.0000E-08 7 Hmholtz VELZ 4 4.9167E-09 2.9577E+00 1.0000E-08 7 U-PRES gmres 1 1.4285E-11 2.7817E-11 1.0000E-08 4.3821E-04 7.7796E-04 7 DNORM, DIVEX 1.428514599120713E-011 1.428505538012936E-011 7 0.7000000E-02 2.14661E-01 9.15347E-05 7.85307E-01 7.85399E-01 volflow Z 7 Fluid done 7.0000E-03 3.7742E-03 Step 8, t= 8.0000000E-03, DT= 1.0000000E-03, C= 0.024 5.8715E-02 6.5508E-03 Solving for fluid 8 Hmholtz VELX 1 1.4103E-12 1.9137E-10 1.0000E-08 8 Hmholtz VELY 1 1.4529E-12 1.9315E-10 1.0000E-08 8 Hmholtz VELZ 4 4.6070E-09 2.8736E+00 1.0000E-08 8 U-PRES gmres 1 1.7677E-11 3.9040E-11 1.0000E-08 4.4584E-04 7.9203E-04 8 DNORM, DIVEX 1.767719693310791E-011 1.767720753586405E-011 8 0.8000000E-02 2.11773E-01 9.03031E-05 7.85308E-01 7.85399E-01 volflow Z 8 Fluid done 8.0000E-03 3.8049E-03 Step 9, t= 9.0000000E-03, DT= 1.0000000E-03, C= 0.024 6.4911E-02 6.1960E-03 Solving for fluid 9 Hmholtz velx 1 1.4859E-12 2.3231E-10 1.0000E-08 9 Hmholtz vely 1 1.7041E-12 2.4480E-10 1.0000E-08 9 Hmholtz velz 4 4.3245E-09 2.7952E+00 1.0000E-08 9 U-PRES gmres 1 2.5635E-11 5.4938E-11 1.0000E-08 4.1890E-04 7.6914E-04 9 DNORM, DIVEX 2.563482495492407E-011 2.563482607944534E-011 9 0.9000000E-02 2.08969E-01 8.91071E-05 7.85309E-01 7.85399E-01 volflow Z 9 Fluid done 9.0000E-03 4.5190E-03 Step 10, t= 1.0000000E-02, DT= 1.0000000E-03, C= 0.024 7.1832E-02 6.9211E-03 Solving for fluid 10 Project velx 1.0928E-12 1.0380E-12 1.0528E+00 1 1 10 Hmholtz velx 1 2.2565E-12 2.9156E-10 1.0000E-08 10 Project vely 1.1238E-12 1.1064E-12 1.0158E+00 1 1 10 Hmholtz vely 1 2.4580E-12 3.2426E-10 1.0000E-08 10 Project velz 8.4125E-03 1.4438E-04 5.8267E+01 1 1 10 Hmholtz velz 4 1.3860E-10 4.3668E-02 1.0000E-08 10 U-PRES gmres 1 3.5152E-11 1.0643E-10 1.0000E-08 4.2200E-04 7.5507E-04 10 DNORM, DIVEX 3.515225402474910E-011 3.515227680759790E-011 10 0.1000000E-01 2.06244E-01 8.79452E-05 7.85311E-01 7.85399E-01 volflow Z 10 Fluid done 1.0000E-02 5.6860E-03 10 1.0000E-02 Write checkpoint FILE: hydro0.f00002 10 1.0000E-02 done :: Write checkpoint file size = 1.9 MB avg data-throughput = 99.6MB/s io-nodes = 24 Step 11, t= 1.1000000E-02, DT= 1.0000000E-03, C= 0.024 9.8775E-02 2.6943E-02 Solving for fluid 11 Project velx 2.0887E-12 1.6492E-12 1.2664E+00 2 0 11 Hmholtz velx 1 3.8614E-12 4.6283E-10 1.0000E-08 11 Project vely 2.0993E-12 1.8999E-12 1.1050E+00 2 0 11 Hmholtz vely 1 3.5506E-12 5.0358E-10 1.0000E-08 11 Project velz 8.1908E-03 2.0834E-06 3.9314E+03 2 0 11 Hmholtz velz 3 5.3533E-10 8.1921E-04 1.0000E-08 11 U-PRES gmres 1 5.9757E-11 1.1938E-10 1.0000E-08 4.1008E-04 7.3814E-04 11 DNORM, DIVEX 5.975704618222100E-011 5.975696721245879E-011 11 0.1100000E-01 2.03595E-01 8.68158E-05 7.85312E-01 7.85399E-01 volflow Z 11 Fluid done 1.1000E-02 5.4030E-03 Step 12, t= 1.2000000E-02, DT= 1.0000000E-03, C= 0.024 1.0672E-01 7.9491E-03 Solving for fluid 12 Project velx 3.3627E-12 1.2342E-12 2.7247E+00 3 0 12 Hmholtz velx 1 3.3679E-12 3.8173E-10 1.0000E-08 12 Project vely 3.3632E-12 1.0434E-12 3.2233E+00 3 0 12 Hmholtz vely 1 3.5490E-12 3.4661E-10 1.0000E-08 12 Project velz 7.9792E-03 1.5430E-07 5.1712E+04 3 0 12 Hmholtz velz 2 2.9327E-09 5.1295E-05 1.0000E-08 12 U-PRES gmres 1 5.5735E-11 1.9372E-10 1.0000E-08 4.0412E-04 7.3099E-04 12 DNORM, DIVEX 5.573487507738371E-011 5.573496867795029E-011 12 0.1200000E-01 2.01021E-01 8.57180E-05 7.85313E-01 7.85399E-01 volflow Z 12 Fluid done 1.2000E-02 5.4240E-03 Step 13, t= 1.3000000E-02, DT= 1.0000000E-03, C= 0.024 1.1473E-01 8.0049E-03 Solving for fluid 13 Project velx 6.4193E-12 2.2025E-12 2.9146E+00 4 0 13 Hmholtz velx 1 3.8826E-12 5.9537E-10 1.0000E-08 13 Project vely 6.4350E-12 2.1703E-12 2.9650E+00 4 0 13 Hmholtz vely 1 4.8476E-12 6.2835E-10 1.0000E-08 13 Project velz 7.7771E-03 4.1469E-08 1.8754E+05 4 0 13 Hmholtz velz 2 1.6601E-09 1.5089E-05 1.0000E-08 13 U-PRES gmres 1 4.3753E-11 1.0105E-10 1.0000E-08 4.0913E-04 7.4196E-04 13 DNORM, DIVEX 4.375244503850638E-011 4.375262559056995E-011 13 0.1300000E-01 1.98517E-01 8.46505E-05 7.85314E-01 7.85399E-01 volflow Z 13 Fluid done 1.3000E-02 5.6980E-03 Step 14, t= 1.4000000E-02, DT= 1.0000000E-03, C= 0.024 1.2315E-01 8.4231E-03 Solving for fluid 14 Project velx 2.1362E-12 1.0723E-12 1.9921E+00 5 0 14 Hmholtz velx 1 3.9810E-12 3.8491E-10 1.0000E-08 14 Project vely 2.2193E-12 1.2086E-12 1.8363E+00 5 0 14 Hmholtz vely 1 4.5744E-12 4.3292E-10 1.0000E-08 14 Project velz 7.5841E-03 7.8784E-10 9.6264E+06 5 0 14 Hmholtz velz 1 2.6942E-09 2.6278E-07 1.0000E-08 14 U-PRES gmres 1 3.4870E-11 8.9533E-11 1.0000E-08 4.1699E-04 7.5006E-04 14 DNORM, DIVEX 3.487049980630507E-011 3.487038385396511E-011 14 0.1400000E-01 1.96082E-01 8.36122E-05 7.85315E-01 7.85399E-01 volflow Z 14 Fluid done 1.4000E-02 5.8091E-03 Step 15, t= 1.5000000E-02, DT= 1.0000000E-03, C= 0.024 1.3200E-01 8.8480E-03 Solving for fluid 15 Project velx 2.0870E-12 9.5755E-13 2.1795E+00 6 0 15 Hmholtz velx 1 1.9816E-12 2.7526E-10 1.0000E-08 15 Project vely 2.2341E-12 9.1877E-13 2.4317E+00 6 0 15 Hmholtz vely 1 1.8638E-12 2.6079E-10 1.0000E-08 15 Project velz 7.3997E-03 4.0501E-10 1.8271E+07 6 0 15 Hmholtz velz 1 7.6036E-10 1.0470E-07 1.0000E-08 15 U-PRES gmres 1 2.6690E-11 5.1313E-11 1.0000E-08 4.2105E-04 7.5889E-04 15 DNORM, DIVEX 2.669000890239623E-011 2.668996948897072E-011 15 0.1500000E-01 1.93713E-01 8.26021E-05 7.85316E-01 7.85399E-01 volflow Z 15 Fluid done 1.5000E-02 6.1171E-03 Step 16, t= 1.6000000E-02, DT= 1.0000000E-03, C= 0.024 1.4055E-01 8.5521E-03 Solving for fluid 16 Project velx 1.4278E-12 7.9313E-13 1.8002E+00 7 0 16 Hmholtz velx 1 2.6163E-12 2.6755E-10 1.0000E-08 16 Project vely 1.6042E-12 7.4087E-13 2.1654E+00 7 0 16 Hmholtz vely 1 2.3466E-12 2.5477E-10 1.0000E-08 16 Project velz 7.2237E-03 1.3826E-10 5.2246E+07 7 0 16 Hmholtz velz 1 3.2483E-10 3.9892E-08 1.0000E-08 16 U-PRES gmres 1 2.1901E-11 5.3006E-11 1.0000E-08 4.1389E-04 7.4697E-04 16 DNORM, DIVEX 2.190062603618091E-011 2.190051882309305E-011 16 0.1600000E-01 1.91408E-01 8.16191E-05 7.85317E-01 7.85399E-01 volflow Z 16 Fluid done 1.6000E-02 6.4211E-03 Step 17, t= 1.7000000E-02, DT= 1.0000000E-03, C= 0.024 1.4961E-01 9.0539E-03 Solving for fluid 17 Project velx 1.3666E-12 4.9154E-13 2.7802E+00 8 0 17 Hmholtz velx 1 1.2733E-12 1.6037E-10 1.0000E-08 17 Project vely 1.4605E-12 4.9563E-13 2.9467E+00 8 0 17 Hmholtz vely 1 1.4031E-12 1.6687E-10 1.0000E-08 17 Project velz 7.0554E-03 1.5474E-10 4.5597E+07 8 0 17 Hmholtz velz 1 4.5936E-10 5.0088E-08 1.0000E-08 17 U-PRES gmres 1 1.3609E-11 3.4234E-11 1.0000E-08 4.0889E-04 7.4100E-04 17 DNORM, DIVEX 1.360943508813963E-011 1.360926198189646E-011 17 0.1700000E-01 1.89164E-01 8.06623E-05 7.85318E-01 7.85399E-01 volflow Z 17 Fluid done 1.7000E-02 6.5470E-03 Step 18, t= 1.8000000E-02, DT= 1.0000000E-03, C= 0.024 1.5878E-01 9.1720E-03 Solving for fluid 18 Project velx 1.0274E-12 5.3877E-13 1.9069E+00 8 0 18 Hmholtz velx 1 1.4884E-12 1.8013E-10 1.0000E-08 18 Project vely 1.0690E-12 5.8445E-13 1.8290E+00 8 0 18 Hmholtz vely 1 1.8685E-12 2.0648E-10 1.0000E-08 18 Project velz 6.8946E-03 7.1559E-11 9.6348E+07 8 0 18 Hmholtz velz 1 1.6445E-10 2.1576E-08 1.0000E-08 18 U-PRES gmres 1 1.0436E-11 2.4511E-11 1.0000E-08 4.1199E-04 7.6413E-04 18 DNORM, DIVEX 1.043611579202116E-011 1.043609660969369E-011 18 0.1800000E-01 1.86979E-01 7.97307E-05 7.85319E-01 7.85399E-01 volflow Z 18 Fluid done 1.8000E-02 6.5770E-03 Step 19, t= 1.9000000E-02, DT= 1.0000000E-03, C= 0.024 1.6790E-01 9.1209E-03 Solving for fluid 19 Project velx 8.7493E-13 3.9461E-13 2.2172E+00 8 0 19 Hmholtz velx 1 1.0589E-12 1.3349E-10 1.0000E-08 19 Project vely 8.9401E-13 4.5467E-13 1.9663E+00 8 0 19 Hmholtz vely 1 1.2473E-12 1.5373E-10 1.0000E-08 19 Project velz 6.7408E-03 7.4093E-11 9.0978E+07 8 0 19 Hmholtz velz 1 2.4016E-10 2.3433E-08 1.0000E-08 19 U-PRES gmres 1 1.0136E-11 2.1459E-11 1.0000E-08 4.1890E-04 7.4482E-04 19 DNORM, DIVEX 1.013612501741543E-011 1.013595013048983E-011 19 0.1900000E-01 1.84852E-01 7.88234E-05 7.85320E-01 7.85399E-01 volflow Z 19 Fluid done 1.9000E-02 6.5510E-03 Step 20, t= 2.0000000E-02, DT= 1.0000000E-03, C= 0.024 1.7691E-01 9.0160E-03 Solving for fluid 20 Project velx 5.4623E-13 3.0284E-13 1.8037E+00 8 0 20 Hmholtz velx 1 9.3158E-13 9.9875E-11 1.0000E-08 20 Project vely 5.6154E-13 3.4088E-13 1.6473E+00 8 0 20 Hmholtz vely 1 1.0630E-12 1.1617E-10 1.0000E-08 20 Project velz 6.5937E-03 2.4260E-10 2.7179E+07 8 0 20 Hmholtz velz 1 5.4904E-10 7.5425E-08 1.0000E-08 1 1.00000E-08 1.14059E-11 2.57048E-11 4.43728E-01 20 Divergence 20 U-PRES gmres 1 1.1406E-11 2.5705E-11 1.0000E-08 4.2105E-04 7.6318E-04 20 DNORM, DIVEX 1.140603378518951E-011 1.140594271632045E-011 20 0.2000000E-01 1.82779E-01 7.79396E-05 7.85321E-01 7.85399E-01 volflow Z 20 Fluid done 2.0000E-02 6.5720E-03 20 2.0000E-02 Write checkpoint FILE: hydro0.f00003 20 2.0000E-02 done :: Write checkpoint file size = 1.9 MB avg data-throughput = 135.4MB/s io-nodes = 24 Step 21, t= 2.1000000E-02, DT= 1.0000000E-03, C= 0.024 2.0031E-01 2.3399E-02 Solving for fluid 21 Project velx 7.6707E-13 3.7846E-13 2.0268E+00 8 0 21 Hmholtz velx 1 8.7942E-13 1.1567E-10 1.0000E-08 21 Project vely 7.7903E-13 4.1219E-13 1.8900E+00 8 0 21 Hmholtz vely 1 9.9778E-13 1.2594E-10 1.0000E-08 21 Project velz 6.4529E-03 3.3439E-10 1.9298E+07 8 0 21 Hmholtz velz 1 1.0414E-09 1.0937E-07 1.0000E-08 21 U-PRES gmres 1 8.8641E-12 1.7381E-11 1.0000E-08 4.2319E-04 7.5603E-04 21 DNORM, DIVEX 8.864165661558847E-012 8.864093057245260E-012 21 0.2100000E-01 1.80760E-01 7.70784E-05 7.85321E-01 7.85399E-01 volflow Z 21 Fluid done 2.1000E-02 6.6080E-03 Step 22, t= 2.2000000E-02, DT= 1.0000000E-03, C= 0.024 2.0941E-01 9.1000E-03 Solving for fluid 22 Project velx 1.0020E-12 4.7137E-13 2.1257E+00 8 0 22 Hmholtz velx 1 1.0187E-12 1.3992E-10 1.0000E-08 22 Project vely 1.0078E-12 5.0553E-13 1.9935E+00 8 0 22 Hmholtz vely 1 1.0447E-12 1.4699E-10 1.0000E-08 22 Project velz 6.3181E-03 4.1853E-10 1.5096E+07 8 0 22 Hmholtz velz 1 1.6836E-09 1.5292E-07 1.0000E-08 22 U-PRES gmres 1 1.1124E-11 2.7521E-11 1.0000E-08 4.1294E-04 7.3910E-04 22 DNORM, DIVEX 1.112350036742130E-011 1.112355704875387E-011 22 0.2200000E-01 1.78791E-01 7.62391E-05 7.85322E-01 7.85399E-01 volflow Z 22 Fluid done 2.2000E-02 6.6011E-03 Step 23, t= 2.3000000E-02, DT= 1.0000000E-03, C= 0.024 2.1891E-01 9.4991E-03 Solving for fluid 23 Project velx 2.0033E-12 7.0411E-13 2.8452E+00 8 0 23 Hmholtz velx 1 2.1215E-12 2.2952E-10 1.0000E-08 23 Project vely 2.0084E-12 6.8921E-13 2.9140E+00 8 0 23 Hmholtz vely 1 2.1462E-12 2.2652E-10 1.0000E-08 23 Project velz 6.1890E-03 1.1746E-10 5.2689E+07 8 0 23 Hmholtz velz 1 5.2150E-10 5.4728E-08 1.0000E-08 23 U-PRES gmres 1 1.5356E-11 3.7380E-11 1.0000E-08 4.1914E-04 7.4697E-04 23 DNORM, DIVEX 1.535600085253532E-011 1.535618069214322E-011 23 0.2300000E-01 1.76872E-01 7.54208E-05 7.85323E-01 7.85399E-01 volflow Z 23 Fluid done 2.3000E-02 6.6011E-03 Step 24, t= 2.4000000E-02, DT= 1.0000000E-03, C= 0.024 2.2809E-01 9.1808E-03 Solving for fluid 24 Project velx 1.3278E-12 9.3083E-13 1.4265E+00 8 0 24 Hmholtz velx 1 1.9564E-12 2.6374E-10 1.0000E-08 24 Project vely 1.3393E-12 9.5074E-13 1.4087E+00 8 0 24 Hmholtz vely 1 2.1517E-12 2.7481E-10 1.0000E-08 24 Project velz 6.0653E-03 3.8601E-10 1.5713E+07 8 0 24 Hmholtz velz 1 1.3674E-09 1.3788E-07 1.0000E-08 24 U-PRES gmres 1 1.9949E-11 4.1854E-11 1.0000E-08 4.1413E-04 7.5293E-04 24 DNORM, DIVEX 1.994902567500108E-011 1.994889829933690E-011 24 0.2400000E-01 1.75001E-01 7.46230E-05 7.85324E-01 7.85399E-01 volflow Z 24 Fluid done 2.4000E-02 6.6140E-03 Step 25, t= 2.5000000E-02, DT= 1.0000000E-03, C= 0.024 2.3713E-01 9.0411E-03 Solving for fluid 25 Project velx 1.6757E-12 8.0392E-13 2.0843E+00 8 0 25 Hmholtz velx 1 2.0914E-12 2.5894E-10 1.0000E-08 25 Project vely 1.6921E-12 8.2437E-13 2.0525E+00 8 0 25 Hmholtz vely 1 2.3363E-12 2.7353E-10 1.0000E-08 25 Project velz 5.9467E-03 5.0424E-11 1.1793E+08 8 0 25 Hmholtz velz 1 1.3395E-10 1.7128E-08 1.0000E-08 25 U-PRES gmres 1 1.5574E-11 3.6509E-11 1.0000E-08 4.1199E-04 7.3695E-04 25 DNORM, DIVEX 1.557425419252328E-011 1.557413483174415E-011 25 0.2500000E-01 1.73176E-01 7.38447E-05 7.85325E-01 7.85399E-01 volflow Z 25 Fluid done 2.5000E-02 6.5801E-03 Step 26, t= 2.6000000E-02, DT= 1.0000000E-03, C= 0.024 2.4670E-01 9.5689E-03 Solving for fluid 26 Project velx 1.2205E-12 1.0942E-12 1.1154E+00 8 0 26 Hmholtz velx 1 2.7186E-12 3.3343E-10 1.0000E-08 26 Project vely 1.2372E-12 1.1241E-12 1.1006E+00 8 0 26 Hmholtz vely 1 2.7979E-12 3.4316E-10 1.0000E-08 26 Project velz 5.8330E-03 1.0244E-10 5.6942E+07 8 0 26 Hmholtz velz 1 3.8475E-10 3.5464E-08 1.0000E-08 26 U-PRES gmres 1 9.7700E-12 1.9884E-11 1.0000E-08 4.1699E-04 7.7295E-04 26 DNORM, DIVEX 9.769898352285633E-012 9.770009398970843E-012 26 0.2600000E-01 1.71396E-01 7.30855E-05 7.85325E-01 7.85399E-01 volflow Z 26 Fluid done 2.6000E-02 6.6321E-03 Step 27, t= 2.7000000E-02, DT= 1.0000000E-03, C= 0.024 2.5576E-01 9.0561E-03 Solving for fluid 27 Project velx 8.7449E-13 6.5973E-13 1.3255E+00 8 0 27 Hmholtz velx 1 1.5832E-12 2.0449E-10 1.0000E-08 27 Project vely 8.9548E-13 6.7206E-13 1.3324E+00 8 0 27 Hmholtz vely 1 1.6389E-12 2.1020E-10 1.0000E-08 27 Project velz 5.7239E-03 7.8727E-11 7.2705E+07 8 0 27 Hmholtz velz 1 2.0872E-10 2.4526E-08 1.0000E-08 27 U-PRES gmres 1 1.2224E-11 2.4136E-11 1.0000E-08 4.2510E-04 7.5197E-04 27 DNORM, DIVEX 1.222338858502294E-011 1.222351929261660E-011 27 0.2700000E-01 1.69658E-01 7.23446E-05 7.85326E-01 7.85399E-01 volflow Z 27 Fluid done 2.7000E-02 6.6199E-03 Step 28, t= 2.8000000E-02, DT= 1.0000000E-03, C= 0.025 2.6478E-01 9.0241E-03 Solving for fluid 28 Project velx 6.0816E-13 4.4563E-13 1.3647E+00 8 0 28 Hmholtz velx 1 1.0679E-12 1.3984E-10 1.0000E-08 28 Project vely 6.3460E-13 4.9212E-13 1.2895E+00 8 0 28 Hmholtz vely 1 1.2174E-12 1.6108E-10 1.0000E-08 28 Project velz 5.6191E-03 2.8628E-10 1.9628E+07 8 0 28 Hmholtz velz 1 9.1642E-10 1.0748E-07 1.0000E-08 28 U-PRES gmres 1 1.2698E-11 2.9665E-11 1.0000E-08 4.1604E-04 7.4100E-04 28 DNORM, DIVEX 1.269758373785236E-011 1.269769385205162E-011 28 0.2800000E-01 1.67962E-01 7.16215E-05 7.85327E-01 7.85399E-01 volflow Z 28 Fluid done 2.8000E-02 6.5951E-03 Step 29, t= 2.9000000E-02, DT= 1.0000000E-03, C= 0.025 2.7384E-01 9.0549E-03 Solving for fluid 29 Project velx 1.1817E-12 7.7278E-13 1.5291E+00 8 0 29 Hmholtz velx 1 1.3410E-12 2.0816E-10 1.0000E-08 29 Project vely 1.2079E-12 7.7686E-13 1.5548E+00 8 0 29 Hmholtz vely 1 1.3716E-12 2.1027E-10 1.0000E-08 29 Project velz 5.5185E-03 7.0110E-11 7.8713E+07 8 0 29 Hmholtz velz 1 2.8204E-10 2.7890E-08 1.0000E-08 29 U-PRES gmres 1 1.2570E-11 2.9788E-11 1.0000E-08 4.1199E-04 7.3886E-04 29 DNORM, DIVEX 1.257021803612805E-011 1.257021373763485E-011 29 0.2900000E-01 1.66307E-01 7.09155E-05 7.85328E-01 7.85399E-01 volflow Z 29 Fluid done 2.9000E-02 6.6278E-03 Step 30, t= 3.0000000E-02, DT= 1.0000000E-03, C= 0.025 2.8313E-01 9.2869E-03 Solving for fluid 30 Project velx 9.4261E-13 6.2417E-13 1.5102E+00 8 0 30 Hmholtz velx 1 1.2782E-12 1.7280E-10 1.0000E-08 30 Project vely 9.8026E-13 6.3862E-13 1.5350E+00 8 0 30 Hmholtz vely 1 1.4106E-12 1.7730E-10 1.0000E-08 30 Project velz 5.4219E-03 8.6166E-10 6.2924E+06 8 0 30 Hmholtz velz 1 2.8812E-09 2.9992E-07 1.0000E-08 30 U-PRES gmres 1 1.1464E-10 2.6503E-10 1.0000E-08 4.4107E-04 7.8297E-04 30 DNORM, DIVEX 1.146484171228502E-010 1.146395845477926E-010 30 0.3000000E-01 1.64690E-01 7.02261E-05 7.85328E-01 7.85399E-01 volflow Z 30 Fluid done 3.0000E-02 6.5820E-03 30 3.0000E-02 Write checkpoint FILE: hydro0.f00004 30 3.0000E-02 done :: Write checkpoint file size = 1.9 MB avg data-throughput = 79.0MB/s io-nodes = 24 Step 31, t= 3.1000000E-02, DT= 1.0000000E-03, C= 0.025 3.1607E-01 3.2944E-02 Solving for fluid 31 Project velx 1.9210E-11 1.9138E-11 1.0037E+00 8 0 31 Hmholtz velx 1 1.9672E-11 5.0448E-09 1.0000E-08 31 Project vely 1.7216E-11 1.7152E-11 1.0038E+00 8 0 31 Hmholtz vely 1 1.8736E-11 4.9216E-09 1.0000E-08 31 Project velz 5.3290E-03 9.5708E-09 5.5679E+05 8 0 31 Hmholtz velz 2 3.0379E-10 3.2832E-06 1.0000E-08 31 U-PRES gmres 3 6.2988E-09 4.6644E-08 1.0000E-08 1.0133E-03 2.0421E-03 31 DNORM, DIVEX 6.309401183402714E-009 6.298823073726441E-009 31 0.3100000E-01 1.63111E-01 6.95527E-05 7.85329E-01 7.85399E-01 volflow Z 31 Fluid done 3.1000E-02 7.9679E-03 Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 1.0526E-02 Solving for fluid 32 Project velx 6.6444E-09 2.4759E-09 2.6836E+00 8 0 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 32 Project vely 6.8730E-09 2.1046E-09 3.2656E+00 8 0 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 32 Project velz 5.2396E-03 2.5121E-06 2.0858E+03 8 0 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 32proj_ortho: 2 8 velz Detect rank deficiency: NaN 1.0000E+00 32proj_ortho: 1 8 velz Detect rank deficiency: NaN 1.0000E+00 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 1.0000E-08 8.7926E-03 1.7780E-02 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 7.85399E-01 volflow Z 32 Fluid done 3.2000E-02 2.4042E-02 Step 33, t= 3.3000000E-02, DT= 1.0000000E-03, C= 0.025 3.5334E-01 2.6744E-02 Solving for fluid 33 Project velx 5.2937E-04 3.4066E-05 1.5540E+01 8 0 33 Hmholtz velx 3 5.8362E-09 1.0173E-02 1.0000E-08 33 Project vely 5.4648E-04 3.5738E-05 1.5291E+01 8 0 33 Hmholtz vely 3 6.1795E-09 1.0217E-02 1.0000E-08 33 Project velz 5.1642E-03 6.3547E-04 8.1266E+00 6 0 33 Hmholtz velz 4 1.3787E-09 2.4417E-01 1.0000E-08 33proj_ortho: 2 7 velz Detect rank deficiency: NaN 1.0000E+00 33 U-PRES gmres 120 3.2992E-04 9.1268E-04 1.0000E-08 3.6037E-02 7.4512E-02 33 DNORM, DIVEX 2.46689287957593 3.299187314590418E-004 33 0.3300000E-01 1.59990E-01 6.82220E-05 7.85330E-01 7.85399E-01 volflow Z 33 Fluid done 3.3000E-02 8.1082E-02 CFL, Ctarg! 284.332673470552 0.500000000000000 34 3.3000E-02 Write checkpoint FILE: hydro0.f00005 34 3.3000E-02 done :: Write checkpoint file size = 1.9 MB avg data-throughput = 147.5MB/s io-nodes = 24 11 Emergency exit: 34 time = 3.300000000000002E-002 9 Emergency exit: 34 time = 3.300000000000002E-002 14 Emergency exit: 34 time = 3.300000000000002E-002 17 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. 22 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. *** STOP *** Latest solution and data are dumped for post-processing. Latest solution and data are dumped for post-processing. Latest solution and data are dumped for post-processing. *** STOP *** 18 Emergency exit: 34 time = 3.300000000000002E-002 15 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. *** STOP *** *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** *** STOP *** *** STOP *** 5 Emergency exit: 34 time = 3.300000000000002E-002 8 Emergency exit: 34 time = 3.300000000000002E-002 10 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. Latest solution and data are dumped for post-processing. *** STOP *** *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** 13 Emergency exit: 34 time = 3.300000000000002E-002 23 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. Latest solution and data are dumped for post-processing. *** STOP *** *** STOP *** 21 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. *** STOP *** 0 Emergency exit: 34 time = 3.300000000000002E-002 1 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. *** STOP *** 3 Emergency exit: 34 time = 3.300000000000002E-002 7 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. 6 Emergency exit: 34 time = 3.300000000000002E-002 *** STOP *** Latest solution and data are dumped for post-processing. Latest solution and data are dumped for post-processing. 2 Emergency exit: 34 time = 3.300000000000002E-002 *** STOP *** *** STOP *** Latest solution and data are dumped for post-processing. 4 Emergency exit: 34 time = 3.300000000000002E-002 *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** 20 Emergency exit: 34 time = 3.300000000000002E-002 12 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** 19 Emergency exit: 34 time = 3.300000000000002E-002 Latest solution and data are dumped for post-processing. 16 Emergency exit: 34 time = 3.300000000000002E-002 *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** Latest solution and data are dumped for post-processing. *** STOP *** runtime statistics: total time 0.353340010507202 mxmf time 0 0.000000000000000E+000 0.000000000000000E+000 tgop time 5575 3.266096115112305E-002 9.243493569901651E-002 inv3 time 273 1.613378524780273E-003 4.566079347946892E-003 invc time 99 9.999275207519531E-004 2.829930070236333E-003 mltd time 918 2.628493309020996E-002 7.438991427118383E-002 cdtp time 918 2.229833602905273E-002 6.310730561490778E-002 eslv time 36 0.120205163955688 0.340196865288875 pres time 33 0.150884628295898 0.427023897121956 crsl time 185 5.387544631958008E-003 1.524747968458045E-002 crsl min 5.160808563232422E-003 crsl max 5.882263183593750E-003 crsl avg 5.474865436553955E-003 hmhz time 33 5.243468284606934E-002 0.148397241429868 spro time 34 4.618167877197266E-004 1.307003945171144E-003 usbc time 33 8.642435073852539E-003 2.445925968431016E-002 usbc min 7.734060287475586E-003 usbc max 9.352207183837891E-003 usb avg 8.474369843800863E-003 axhm time 694 3.651022911071777E-002 0.103328884431483 advc time 99 1.854228973388672E-002 5.247718679599906E-002 vdss time 274 2.405118942260742E-002 6.806811769797348E-002 vdss min 1.815438270568848E-002 vdss max 2.539277076721191E-002 vdss avg 2.211845914522807E-002 dsum time 1141 4.439687728881836E-002 0.125649165021218 dsum min 3.167104721069336E-002 dsum max 4.561710357666016E-002 dsum avg 4.384730259577433E-002 dadd time 0 1.598310470581055E-002 4.523434717417818E-002 ddsl time 185 5.954694747924805E-002 0.168525911893678 solv time 185 6.815433502197266E-003 1.928859823265994E-002 prep time 35 6.918621063232422E-002 0.195806329809666 MPI timings total comm time 4.600620269775391E-002 0.166948377715475 comm min 3.311204910278320E-002 comm max 5.898952484130859E-002 comm avg 4.842885335286459E-002 barrier time 0 0.000000000000000E+000 0.000000000000000E+000 barrier min 0.000000000000000E+000 barrier max 0.000000000000000E+000 barrier avg 0.000000000000000E+000 waitall time 11195 3.656482696533203E-002 0.794780373541179 waitall min 2.262520790100098E-002 waitall max 4.934859275817871E-002 waitall avg 3.865465521812439E-002 allreduce time 0 0.000000000000000E+000 0.000000000000000E+000 allreduce min 0.000000000000000E+000 allreduce max 0.000000000000000E+000 allreduce avg 0.000000000000000E+000 allreduce_sync time 0.000000000000000E+000 0.000000000000000E+000 allreduce_sync min 0.000000000000000E+000 allreduce_sync max 0.000000000000000E+000 allreduce_sync avg 0.000000000000000E+000 # nid tusbc tdadd tcrsl tvdss tdsum tgop qqq F 0 8.6424E-03 1.5983E-02 5.3875E-03 2.4051E-02 4.4397E-02 3.2661E-02 qqq 1 8.8966E-03 1.6063E-02 5.1608E-03 2.5393E-02 4.4976E-02 5.2797E-02 qqq 2 8.3587E-03 1.6842E-02 5.6503E-03 2.0835E-02 4.4769E-02 5.7136E-02 qqq 3 9.3522E-03 1.6212E-02 5.3024E-03 2.1300E-02 3.1671E-02 3.5687E-02 qqq 4 9.0003E-03 1.6313E-02 5.3015E-03 2.4041E-02 4.4778E-02 5.5589E-02 qqq 5 8.2464E-03 1.6971E-02 5.8258E-03 1.9455E-02 4.4560E-02 5.9780E-02 qqq 6 8.6889E-03 1.6192E-02 5.5237E-03 2.4356E-02 4.5617E-02 5.5960E-02 qqq 7 8.7538E-03 1.5855E-02 5.2750E-03 2.5064E-02 4.5087E-02 5.4449E-02 qqq 8 8.2150E-03 1.6556E-02 5.7075E-03 2.0328E-02 4.4294E-02 5.8549E-02 qqq 9 8.5251E-03 1.6092E-02 5.3415E-03 2.2626E-02 4.5111E-02 5.6242E-02 qqq 10 8.5392E-03 1.6140E-02 5.5597E-03 2.3234E-02 4.4845E-02 5.5619E-02 qqq 11 7.9479E-03 1.6839E-02 5.8823E-03 1.8791E-02 4.4739E-02 6.0194E-02 qqq 12 8.7032E-03 1.5378E-02 5.2822E-03 2.3747E-02 4.4782E-02 4.9581E-02 qqq 13 8.7762E-03 1.5500E-02 5.2562E-03 2.4471E-02 4.4170E-02 4.9750E-02 qqq 14 8.1465E-03 1.5933E-02 5.6129E-03 1.9685E-02 4.3852E-02 5.3759E-02 qqq 15 8.3561E-03 1.5804E-02 5.4088E-03 2.1786E-02 4.4206E-02 5.3200E-02 qqq 16 8.5623E-03 1.5433E-02 5.2996E-03 2.3059E-02 4.3695E-02 5.1350E-02 qqq 17 7.8588E-03 1.6481E-02 5.7223E-03 1.8388E-02 4.4183E-02 5.7596E-02 qqq 18 8.5285E-03 1.5386E-02 5.4266E-03 2.3645E-02 4.4376E-02 5.1830E-02 qqq 19 8.6548E-03 1.5412E-02 5.3701E-03 2.4292E-02 4.3998E-02 5.1528E-02 qqq 20 8.0819E-03 1.6098E-02 5.5826E-03 1.9737E-02 4.3289E-02 5.5220E-02 qqq 21 8.3082E-03 1.5827E-02 5.4238E-03 2.1808E-02 4.4188E-02 5.3329E-02 qqq 22 8.5077E-03 1.5384E-02 5.3835E-03 2.2597E-02 4.3298E-02 5.2802E-02 qqq 23 7.7341E-03 1.6088E-02 5.7104E-03 1.8154E-02 4.3452E-02 5.6648E-02 qqq call exitt: dying ... backtrace(): obtained 10 stack frames. [0x20255fc9] [0x2038cba2] [0x201380ce] [0x2011a53a] [0x20003ddf] [0x20000e1e] [0x20000c5b] [0x20000aae] [0x207b7d11] [0x20000989] total elapsed time : 5.61988E-01 sec total solver time incl. I/O : 3.53340E-01 sec time/timestep : 1.03924E-02 sec avg throughput per timestep : 2.01238E+05 gridpts/CPUs max resident memory : 1.03506E+01 MB Application 7145931 resources: utime ~20s, stime ~11s, Rss ~10672, inblocks ~69765, outblocks ~51109 From nek5000-users at lists.mcs.anl.gov Fri Apr 7 12:54:32 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 7 Apr 2017 17:54:32 +0000 Subject: [Nek5000-users] proj_ortho error in pipe flow In-Reply-To: References: Message-ID: Hi Steffen, It looks like your solution is hitting a steady-state condition and that the projection onto prior solutions is thus projecting in to a set of linearly-dependent vectors. In principle, the code is supposed to correct for this condition but apparently it is not doing so correctly. I see you're running at Re > 5000, so presumably you are interested in turbulence, rather than laminar steady state. I would recommend adding a random perturbation to the initial condition or, better still, adding something with bound vorticity near the walls that will get stretched and bring about a more rapid transition. I find that something like the attached works well with channel flow (snap through within about 10 convective time units). I was disappointed that it didn't work as well with pipe flow, where I had to go up to Re=40k to get the thing started and then bring it down. I assume this has something to do with the lack of linear transition in Hagen-Poiseuille flow. If you find a better mechanism to speed transition, I'd be interested to find out about it. Best, 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: Friday, April 07, 2017 10:18 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] proj_ortho error in pipe flow Dear Nek users, I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 steps, I get this problem (see attachment for complete logfile): Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 1.0526E-02 Solving for fluid 32 Project velx 6.6444E-09 2.4759E-09 2.6836E+00 8 0 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 32 Project vely 6.8730E-09 2.1046E-09 3.2656E+00 8 0 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 32 Project velz 5.2396E-03 2.5121E-06 2.0858E+03 8 0 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 32proj_ortho: 2 8 velz Detect rank deficiency: NaN 1.0000E+00 32proj_ortho: 1 8 velz Detect rank deficiency: NaN 1.0000E+00 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 1.0000E-08 8.7926E-03 1.7780E-02 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 7.85399E-01 volflow Z 32 Fluid done 3.2000E-02 2.4042E-02 In the next step I get CFL, CTarg! and the simulation exits. This problem does neither show up on my local machine nor on another smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I do not see this error. It only appears when p94 and p95 are both unequal 0. In my case I set them to 9. Do you know what might be causing this issue and how to solve it for the Cray XC40 system? Best Regards Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: pipc_ic.usr Type: application/octet-stream Size: 1512 bytes Desc: pipc_ic.usr URL: From nek5000-users at lists.mcs.anl.gov Sat Apr 8 12:55:36 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 8 Apr 2017 19:55:36 +0200 Subject: [Nek5000-users] proj_ortho error in pipe flow In-Reply-To: References: Message-ID: Hi Steffen, which revision of the code are you using? Is the initial field you are using already turbulent, or are you going through transition? Any special reason why you have 9 for p94/95? Philipp On 2017-04-07 19:54, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Steffen, > > It looks like your solution is hitting a steady-state condition and that the > projection onto prior solutions is thus projecting in to a set of linearly-dependent > vectors. > > In principle, the code is supposed to correct for this condition but apparently > it is not doing so correctly. > > I see you're running at Re > 5000, so presumably you are interested in turbulence, > rather than laminar steady state. I would recommend adding a random perturbation > to the initial condition or, better still, adding something with bound vorticity near the > walls that will get stretched and bring about a more rapid transition. > > I find that something like the attached works well with channel flow (snap through within > about 10 convective time units). I was disappointed that it didn't work as well with pipe > flow, where I had to go up to Re=40k to get the thing started and then bring it down. > I assume this has something to do with the lack of linear transition in Hagen-Poiseuille flow. > If you find a better mechanism to speed transition, I'd be interested to find out about it. > > Best, > > 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: Friday, April 07, 2017 10:18 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] proj_ortho error in pipe flow > > Dear Nek users, > > I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 > steps, I get this problem (see attachment for complete logfile): > > Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 > 1.0526E-02 > Solving for fluid > 32 Project velx 6.6444E-09 2.4759E-09 > 2.6836E+00 8 0 > 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 > 32 Project vely 6.8730E-09 2.1046E-09 > 3.2656E+00 8 0 > 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 > 32 Project velz 5.2396E-03 2.5121E-06 > 2.0858E+03 8 0 > 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 > 32proj_ortho: 2 8 velz Detect rank deficiency: NaN > 1.0000E+00 > 32proj_ortho: 1 8 velz Detect rank deficiency: NaN > 1.0000E+00 > 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 > 1.0000E-08 8.7926E-03 1.7780E-02 > 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 > 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 > 7.85399E-01 volflow Z > 32 Fluid done 3.2000E-02 2.4042E-02 > > In the next step I get CFL, CTarg! and the simulation exits. > > This problem does neither show up on my local machine nor on another > smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I > do not see this error. It only appears when p94 and p95 are both unequal > 0. In my case I set them to 9. > > Do you know what might be causing this issue and how to solve it for the > Cray XC40 system? > > > Best Regards > Steffen > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Sun Apr 9 02:12:56 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 9 Apr 2017 07:12:56 +0000 Subject: [Nek5000-users] Problem with intp_rstd Message-ID: Dear all, I've been playing around with the 'intp_rstd' subroutine to do calculations on the dealiasing grid (lxd*lxy*lzd). I can map the velocity field onto the fine grid (vx --> vxd) and when I print out values it seems fine. Then I try to calculate vxd**2, and still seems fine. However, when I try to map back to the original grid, the results are complete garbage. Here is a snippet of my code. do e=1,nelv ! mapping to fine grid call intp_rstd(vxd(1,1,1,e),vx(1,1,1,e),nx1,nxd,if3d,0) ! 0 --> forward enddo call vsq(vxd,ntotd) ! calculating vxd**2 do e=1,nelv ! mapping back to original grid call intp_rstd(vx(1,1,1,e),vxd(1,1,1,e),nx1,nxd,if3d,1) ! 0 --> backwards enddo Am I doing something wrong? Thanks, Juan Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Apr 9 12:29:49 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 9 Apr 2017 17:29:49 +0000 Subject: [Nek5000-users] Problem with intp_rstd In-Reply-To: References: Message-ID: Dear Juan, The usage model for intp_rstd() is to map back and forth between a std grid and a fine grid, in the context of Galerkin projection. Here is the basic idea: If you want to find u \in PN such that ||(u*-u)|| \leq ||(u*-v)|| for all v \in PN, that is, such that u is the closest element in PN to u*, then you have to choose a norm. Let's suppose you are choosing the L2 norm. Let's also assume u*=vx^2, which is a polynomial of degree 2N. If u is the closest element of PN to u*, it means that (u*-u) \perp PN, which is to say, (v, (u-u*) ) = 0 for all v in PN [ i.e., (v,e)=0, where e=u-u* is the error and (.,.) is the L2 inner-product]. Assuming there are n basis functions in PN, we have: u = sum_j=1^n u_j phi_j (X) and thus we have n unknown basis coefficients, u_j, j=1,...n. Moreover, the projection (i.e., best-fit) statement gives us n equations: (phi_i , u-u* ) = 0 , i=1,...,n or, (phi_i, u ) = (phi_i , u*) , i=1,...,n Bescause the inner product (f,g) := \int_Omega f g dX is linear, we can right the term on the left as sum_j (phi_i, phi_j ) u = (phi_i , u*) =: b_i , i=1,...,n so B u = b where B_{ij} := (phi_,phi_j) := \int_Omega phi_i , phi_j dX. Thus, we have two types of integrals to compute, B_{ij} and b_i. Let's take care of b_i first: b_i = \int_Omega v u* dX If u* \in P_2N and v \in P_N, then we need a quadrature rule that is exact for all polynomials of degree M \leq 3N. Gauss (not Gauss Lobatto) quadrature on (3M/2+1) points is exact for all polynomials of degree 2(3M/2+1) - 1 = 3M+1, so that will suffice. To compute b_i, we thus do: b_i = sum_k=1^m phi_i (\xi_k) rho_k vx(\xi_k) vx(\xi_k) where \xi_k are the Gauss quadrature points in the domain, m=number of Gauss points, rho_k are the Mth-order Gauss quadrature weights. Note that, it is important to interpolate vx to the \xi_k, and not u*, because information is otherwise already lost. Note that if vx(X) = sum_j \phi_j(X) vx_j then vx(\xi_k) = \sum \phi_j(\xi_k) vx_j = J vx where J_{kj} := \phi_j(\xi_k) is the interpolation matrix from the Nth-order Gauss Lobatto (GL) points to the Mth-order Gauss (G) quadrature points. Careful inspection of of the above expression shows that the rhs ( b = {b_i} ) is given by: b = J^T B_M V (J vx) where V = diag ( vx(\xi_k) ) is just a diagonal matrix with vx on the fine quadrature mesh. So, ignoring momentarily the diagonal matrix V, the process of generating the right hand side, with entries on the Nth-order Gauss points is, in words: Interpolate vx onto fine mesh: vx --> J vx Collocate with V and the diagonal matrix of quadrature weights, B_M Map back to the Nth-order GL mesh: J^T ( B_M V (J vx ) ) OK. So, intp_rstd(...,0) applies J. intp_rstd(...,1) applies J^T Now, you still haven't finished the projection process. To get u, you must do the following: call col3(u,binvm1,rhs,n) which applies B^{-1} to get u (from, as it were, u*= vx * vx ). As a final finishing touch, the "col3" statement will be exact if the product u*v is in P_2N-1. Unfortunately, it is in P_2N, because u and v are both polynomials of degree N. You have the option of computing the non diagonal matrix and solving that system via preconditioned conjugate gradients, or of just allowing that small discrepancy. If you've come this far, I would recommend the former. I have code that can do that for you. 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: Sunday, April 09, 2017 2:12 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Problem with intp_rstd Dear all, I've been playing around with the 'intp_rstd' subroutine to do calculations on the dealiasing grid (lxd*lxy*lzd). I can map the velocity field onto the fine grid (vx --> vxd) and when I print out values it seems fine. Then I try to calculate vxd**2, and still seems fine. However, when I try to map back to the original grid, the results are complete garbage. Here is a snippet of my code. do e=1,nelv ! mapping to fine grid call intp_rstd(vxd(1,1,1,e),vx(1,1,1,e),nx1,nxd,if3d,0) ! 0 --> forward enddo call vsq(vxd,ntotd) ! calculating vxd**2 do e=1,nelv ! mapping back to original grid call intp_rstd(vx(1,1,1,e),vxd(1,1,1,e),nx1,nxd,if3d,1) ! 0 --> backwards enddo Am I doing something wrong? Thanks, Juan Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Apr 9 17:39:20 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 9 Apr 2017 18:39:20 -0400 Subject: [Nek5000-users] Inconsistent Periodic BC in Prenek Message-ID: Hello Neks, I am making a rectangular domain with two sides periodic and 2 sides no-slip. I am having problems after the global refine. If I refine my domain to 48 elements, it's fine, but if I refine it to 192 elements (which is better, with a grid size =1 ), it returns "Inconsistent Periodic BCs" and "Reset el/face1". As a result the "genmap" does not work due to Periodic Mismatch. Please note that there is no problems if no. of elements = 48. I don't understand what the problem is. Any help is appreciated. Thanks for reading. Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Apr 9 18:55:57 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Apr 2017 07:55:57 +0800 (GMT+08:00) Subject: [Nek5000-users] How to read velocity time history files in turbChannel In-Reply-To: References: Message-ID: Hi all, I modified the case turbChannel into turbulent boundary flow, of which the inflow boundary condition is 'v ' and the outflow boundary condition is 'O '. For the inflow boundary condition, I wonder can I get it from velocity time history files, just similar to the restart case that gets initial condition from defined file? I tryied a lot, and find for parallel computing the subroutine userbc is invoked randomly. The major subroutine function for inflow boundary may be subroutine faceiv (cb,v1,v2,v3,iel,iface,nx,ny,nz). I have no idea how to deal with it from time history files. Can anybody help me or give me a simple example? Best regards! Hu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Apr 9 21:36:13 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Apr 2017 02:36:13 +0000 Subject: [Nek5000-users] Inconsistent Periodic BC in Prenek In-Reply-To: References: Message-ID: Hi Saikat, If you're doing this in prenek then the likelihood of having the periodic bcs retain correct numbering is very low. I would suggest to build the mesh in genbox and you can then prescribe the BCs (along with precise coordinates of the array of elements). Otherwise, the standard procedure is to edit the .rea file and replace " P " with " " (3 blanks), then go into prenek and when it prompts for BCs click: SET ENTIRE LEVEL PERIODIC AUTO .... which should produce what you need. 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: Sunday, April 09, 2017 5:39 PM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Inconsistent Periodic BC in Prenek Hello Neks, I am making a rectangular domain with two sides periodic and 2 sides no-slip. I am having problems after the global refine. If I refine my domain to 48 elements, it's fine, but if I refine it to 192 elements (which is better, with a grid size =1 ), it returns "Inconsistent Periodic BCs" and "Reset el/face1". As a result the "genmap" does not work due to Periodic Mismatch. Please note that there is no problems if no. of elements = 48. I don't understand what the problem is. Any help is appreciated. Thanks for reading. Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 10 07:32:33 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Apr 2017 14:32:33 +0200 Subject: [Nek5000-users] proj_ortho error in pipe flow In-Reply-To: References: Message-ID: Hi Paul & Philipp, thanks for your quick replies and suggestions. I started the simulation again with a slightly perturbed laminar flow field as initial conditions and there are no proj_ortho errors anymore. For now, this perturbation is more or less random and probably not ideal for tripping the laminar flow to turbulence. Therefore, I might try to implement a more effective numerical tripping method in the future. I can let you know when (and if) I succeed. The parameters p94 and p95 are set to "9" just because I have found that in another simulation somewhere. Do you suggest trying different values here? The Nek5000 version was downloaded as a zip file on 21/03/2017 so I suppose it is the commit 95b42f08c960d522679e0f0881d284ec841ae09 \Steffen On 09/04/17 19:00, nek5000-users-request at lists.mcs.anl.gov wrote: > Message: 1 > Date: Sat, 8 Apr 2017 19:55:36 +0200 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] proj_ortho error in pipe flow > Message-ID: > > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi Steffen, > which revision of the code are you using? Is the initial field you are > using already turbulent, or are you going through transition? Any > special reason why you have 9 for p94/95? > > Philipp > > On 2017-04-07 19:54, nek5000-users at lists.mcs.anl.gov wrote: >> Hi Steffen, >> >> It looks like your solution is hitting a steady-state condition and that the >> projection onto prior solutions is thus projecting in to a set of linearly-dependent >> vectors. >> >> In principle, the code is supposed to correct for this condition but apparently >> it is not doing so correctly. >> >> I see you're running at Re > 5000, so presumably you are interested in turbulence, >> rather than laminar steady state. I would recommend adding a random perturbation >> to the initial condition or, better still, adding something with bound vorticity near the >> walls that will get stretched and bring about a more rapid transition. >> >> I find that something like the attached works well with channel flow (snap through within >> about 10 convective time units). I was disappointed that it didn't work as well with pipe >> flow, where I had to go up to Re=40k to get the thing started and then bring it down. >> I assume this has something to do with the lack of linear transition in Hagen-Poiseuille flow. >> If you find a better mechanism to speed transition, I'd be interested to find out about it. >> >> Best, >> >> 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: Friday, April 07, 2017 10:18 AM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: [Nek5000-users] proj_ortho error in pipe flow >> >> Dear Nek users, >> >> I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 >> steps, I get this problem (see attachment for complete logfile): >> >> Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 >> 1.0526E-02 >> Solving for fluid >> 32 Project velx 6.6444E-09 2.4759E-09 >> 2.6836E+00 8 0 >> 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 >> 32 Project vely 6.8730E-09 2.1046E-09 >> 3.2656E+00 8 0 >> 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 >> 32 Project velz 5.2396E-03 2.5121E-06 >> 2.0858E+03 8 0 >> 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 >> 32proj_ortho: 2 8 velz Detect rank deficiency: NaN >> 1.0000E+00 >> 32proj_ortho: 1 8 velz Detect rank deficiency: NaN >> 1.0000E+00 >> 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 >> 1.0000E-08 8.7926E-03 1.7780E-02 >> 32 DNORM, DIVEX 2.704668739973178E-005 9.937641774554489E-009 >> 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 >> 7.85399E-01 volflow Z >> 32 Fluid done 3.2000E-02 2.4042E-02 >> >> In the next step I get CFL, CTarg! and the simulation exits. >> >> This problem does neither show up on my local machine nor on another >> smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I >> do not see this error. It only appears when p94 and p95 are both unequal >> 0. In my case I set them to 9. >> >> Do you know what might be causing this issue and how to solve it for the >> Cray XC40 system? >> >> >> Best Regards >> Steffen >> >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> From nek5000-users at lists.mcs.anl.gov Mon Apr 10 07:42:42 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Apr 2017 14:42:42 +0200 Subject: [Nek5000-users] proj_ortho error in pipe flow In-Reply-To: References: Message-ID: ok, great! As Paul says, ideally one wants an initial condition that quickly leads to turbulence, and that is done with some streamwise vorticity near the walls. The way we typically do that is not with an initial condition, but rather with our trip force, because this leads to an efficient vertical mixing (across the shear), and thus to quick transition. We then turn the force off after a short time. This way, you do not need to care much about continuity, and you can just have a force in the wall-normal direction at some selected positions in the flow. This works well for higher Reynolds numbers, at least from our experience. Another thought that one could experiment a bit is to use the synthetic eddy method as a way to generate not just boundary conditions, but also initial conditions. Philipp On 2017-04-10 14:32, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul & Philipp, > > thanks for your quick replies and suggestions. I started the simulation > again with a slightly perturbed laminar flow field as initial conditions > and there are no proj_ortho errors anymore. > For now, this perturbation is more or less random and probably not ideal > for tripping the laminar flow to turbulence. Therefore, I might try to > implement a more effective numerical tripping method in the future. I > can let you know when (and if) I succeed. > > The parameters p94 and p95 are set to "9" just because I have found that > in another simulation somewhere. Do you suggest trying different values > here? > The Nek5000 version was downloaded as a zip file on 21/03/2017 so I > suppose it is the commit 95b42f08c960d522679e0f0881d284ec841ae09 > > > \Steffen > > > On 09/04/17 19:00, nek5000-users-request at lists.mcs.anl.gov wrote: >> Message: 1 >> Date: Sat, 8 Apr 2017 19:55:36 +0200 >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] proj_ortho error in pipe flow >> Message-ID: >> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Hi Steffen, >> which revision of the code are you using? Is the initial field you are >> using already turbulent, or are you going through transition? Any >> special reason why you have 9 for p94/95? >> >> Philipp >> >> On 2017-04-07 19:54, nek5000-users at lists.mcs.anl.gov wrote: >>> Hi Steffen, >>> >>> It looks like your solution is hitting a steady-state condition and >>> that the >>> projection onto prior solutions is thus projecting in to a set of >>> linearly-dependent >>> vectors. >>> >>> In principle, the code is supposed to correct for this condition but >>> apparently >>> it is not doing so correctly. >>> >>> I see you're running at Re > 5000, so presumably you are interested >>> in turbulence, >>> rather than laminar steady state. I would recommend adding a random >>> perturbation >>> to the initial condition or, better still, adding something with >>> bound vorticity near the >>> walls that will get stretched and bring about a more rapid transition. >>> >>> I find that something like the attached works well with channel flow >>> (snap through within >>> about 10 convective time units). I was disappointed that it didn't >>> work as well with pipe >>> flow, where I had to go up to Re=40k to get the thing started and >>> then bring it down. >>> I assume this has something to do with the lack of linear transition >>> in Hagen-Poiseuille flow. >>> If you find a better mechanism to speed transition, I'd be interested >>> to find out about it. >>> >>> Best, >>> >>> 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: Friday, April 07, 2017 10:18 AM >>> To: nek5000-users at lists.mcs.anl.gov >>> Subject: [Nek5000-users] proj_ortho error in pipe flow >>> >>> Dear Nek users, >>> >>> I am running a simple pipe flow on a Cray XC40 (Hazel Hen). After 32 >>> steps, I get this problem (see attachment for complete logfile): >>> >>> Step 32, t= 3.2000000E-02, DT= 1.0000000E-03, C= 0.025 3.2660E-01 >>> 1.0526E-02 >>> Solving for fluid >>> 32 Project velx 6.6444E-09 2.4759E-09 >>> 2.6836E+00 8 0 >>> 32 Hmholtz velx 1 3.9238E-09 6.7918E-07 1.0000E-08 >>> 32 Project vely 6.8730E-09 2.1046E-09 >>> 3.2656E+00 8 0 >>> 32 Hmholtz vely 1 3.6166E-09 5.9974E-07 1.0000E-08 >>> 32 Project velz 5.2396E-03 2.5121E-06 >>> 2.0858E+03 8 0 >>> 32 Hmholtz velz 3 7.6028E-10 9.3795E-04 1.0000E-08 >>> 32proj_ortho: 2 8 velz Detect rank deficiency: NaN >>> 1.0000E+00 >>> 32proj_ortho: 1 8 velz Detect rank deficiency: NaN >>> 1.0000E+00 >>> 32 U-PRES gmres 29 9.9376E-09 5.2213E-04 >>> 1.0000E-08 8.7926E-03 1.7780E-02 >>> 32 DNORM, DIVEX 2.704668739973178E-005 >>> 9.937641774554489E-009 >>> 32 0.3200000E-01 1.61568E-01 6.88948E-05 7.85330E-01 >>> 7.85399E-01 volflow Z >>> 32 Fluid done 3.2000E-02 2.4042E-02 >>> >>> In the next step I get CFL, CTarg! and the simulation exits. >>> >>> This problem does neither show up on my local machine nor on another >>> smaller cluster. Moreover, when I set either parameter 94 or 95 to 0, I >>> do not see this error. It only appears when p94 and p95 are both unequal >>> 0. In my case I set them to 9. >>> >>> Do you know what might be causing this issue and how to solve it for the >>> Cray XC40 system? >>> >>> >>> Best Regards >>> Steffen >>> >>> >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 10 15:42:35 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Apr 2017 20:42:35 +0000 Subject: [Nek5000-users] Problem with intp_rstd Message-ID: Dear Paul, Thank you for your detailed answer. I understand now what needs to be done. Also, you mentioned that you had a code that could help me solve the B u = b problem exactly. If it is not too much trouble, I would really appreciate it if you shared it with me. It would save me a lot of time. Thank you, Juan Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 11 12:52:14 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 11 Apr 2017 17:52:14 +0000 Subject: [Nek5000-users] Problem with intp_rstd Message-ID: Dear Paul, I am confused about something. I realize now that for the components of B_{ij} to be exact, quadrature for \int_\Omega \phi_i \phi_j dx = (\phi_i, \phi_j ). Since in Nek5000 we have (N+1)^dim GLL points for the velocity grid, does that mean every time an inner product is being evaluated in the code this is not exact? If I want B_{ij} to be exact, do I need to evaluate the basis functions on more GLL quadrature points (say, N+2)? I'm just wondering if I am understanding the problem correctly. For now, multiplying "rhs" by "binvm1" like you suggested produced accurate results for my dummy problem (vx**2), I may have to do exact integration in the long run. Thank you, Juan Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 19 08:58:29 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 Apr 2017 14:58:29 +0100 Subject: [Nek5000-users] prenek Message-ID: Hi nek, I want to generate a 2d pipe mesh using prenek and add 3 elements in first quadrant using [(0, 0), (0.0045, 0), (0.003536, 0.003536), (0, 0.0045)], [(0.0125, 0), (0.00884, 0.00884), (0.003536, 0.003536), (0.0045, 0)], and [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] for 3 elements respectively. But I usually add the element of [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] with some difference which would happened on the first point I select. Do you know how could I click the points very accurately? Kind regards, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Apr 19 10:58:29 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 19 Apr 2017 15:58:29 +0000 Subject: [Nek5000-users] prenek In-Reply-To: References: Message-ID: Hi Jian, You can click in the menu area instead of on the screen, and then type the values in. Or, you can use SET GRID to change the grid background such that it contains your point of interest (Sometimes this is more useful than the above if you have a lot of points.) Or, you can build a list of points of the form: npoints x1 y1 x2 y2 ... xnpoints ynpoints in a file called "obj.dat" and then click on DEFINE OBJECT, which will set these points to be the snap points in standard element-input mode. Then, use SET GRID to toggle between these points and the other standard background grid options. 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: Wednesday, April 19, 2017 8:58 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] prenek Hi nek, I want to generate a 2d pipe mesh using prenek and add 3 elements in first quadrant using [(0, 0), (0.0045, 0), (0.003536, 0.003536), (0, 0.0045)], [(0.0125, 0), (0.00884, 0.00884), (0.003536, 0.003536), (0.0045, 0)], and [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] for 3 elements respectively. But I usually add the element of [(0, 0.0125), (0.00884, 0.00884), (0.003536, 0.003536), (0, 0.00045)] with some difference which would happened on the first point I select. Do you know how could I click the points very accurately? Kind regards, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Apr 20 20:23:19 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 20 Apr 2017 21:23:19 -0400 Subject: [Nek5000-users] How to print out time derivatives of scalars in a flowfield Message-ID: Hello Neks, I am working on Rayleigh Benard convection in a cylindrical domain, and I have some reactive scalars advecting with the flowfield. I need to find out a way to print the values of the temporal derivative of these scalars at each time step. At this point, I get .f files which have the information of velocity, temperature and the scalar field (c). I need to find out a way to include the information for the time derivative of the scalar filed (dc/dt). How can this be done? Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Apr 21 13:35:23 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 21 Apr 2017 20:35:23 +0200 Subject: [Nek5000-users] Robin boundary condition on velocity Message-ID: Hi Neks I'm trying to implement a slip-length (Robin) as boundary condition for a plane channel flow, namely: (u+du/dy)_{wall}=0 where x and y are the streamwise and wall normal directions respectively. Following the latter post: http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html here there's what I came up with: c----------------------------------------------------------------------- subroutine userchk include 'SIZE' include 'TOTAL' common /my_DEBUG/ rmodulate common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) $ , work1(lx1,ly1,lz1,lelt) $ , work2(lx1,ly1,lz1,lelt) $ , graduy(lx1,ly1,lz1,lelt) n = nx1*ny1*nz1*nelv !!!Build Up MASKS! if (istep.eq.0) then do i=1,n x=xm1(i,1,1,1) y=ym1(i,1,1,1) if(x.gt.3.and.x.lt.4)then ROBIN_mask(i,1,1,1)=1.0 else ROBIN_mask(i,1,1,1)=0.0 endif enddo endif !Compute velocity gradient call rzero(graduy,n) call gradm1(work1,graduy,work2,vx) call dsavg(graduy) ! call outpost(work1,graduy,work2,pr,t,'GRD') !Da aggiungere l'eventualit? del 3D... rmodulate = 0.5*(tanh(0.25*time-10)+1) if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time return end c----------------------------------------------------------------------- c----------------------------------------------------------------------- subroutine userbc (ix,iy,iz,iside,eg) c NOTE ::: This subroutine MAY NOT be called by every process include 'SIZE' include 'TOTAL' include 'NEKUSE' integer e, eg !Imposing Fancy Boundary Conditions... ![Nek5000-users] Robin boundary conditions for the velocity common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) $ , work1(lx1,ly1,lz1,lelt) $ , work2(lx1,ly1,lz1,lelt) $ , graduy(lx1,ly1,lz1,lelt) common /my_DEBUG/ rmodulate e=gllel(eg) ! global element number to processor-local el. # ux=1*graduy(ix,iy,iz,e)*rmodulate uy=0.0 uz=0.0 return end c----------------------------------------------------------------------- subroutine useric (ix,iy,iz,ieg) include 'SIZE' include 'TOTAL' include 'NEKUSE' ux=1.0*y**2 uy=0.0 uz=0.0 temp=0 return end c----------------------------------------------------------------------- The code becomes unstable in the gradient computation due to some point-to-point oscillations. As you can see I've also tried to use a ramp function in order to make the onset of Robin condition more gentle, but at a given "slip-length amplitude" oscillations deteriorates the solution. I use ROBIN_mask in order to chose where to have such BC, but it seems that I'm still missing something in computing the velocity gradient GRD. By the way, this is my box.BOX file: base.rea 2 spatial dimension ( < 0 --> generate .rea/.re2 pair) 1 number of fields #======================================================================= # # Example of .box file for channel flow # # If nelx (y or z) < 0, then genbox automatically generates the # grid spacing in the x (y or z) direction # with a geometric ratio given by "ratio". # ( ratio=1 implies uniform spacing ) # # Note that the character bcs _must_ have 3 spaces. # #======================================================================= # Box -32 -16 nelx,nely,nelz for Box 0 6.2832 1. x0,x1,gain -1 1 1. y0,y1,gain P ,P ,v ,v , , bc's (3 chars each!) I was wondering if you might be able to give me some advice. Best regards, Francesco -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sat Apr 22 05:35:45 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 22 Apr 2017 12:35:45 +0200 Subject: [Nek5000-users] Robin boundary condition on velocity In-Reply-To: References: Message-ID: Hi Francesco, Robin boundary condition is implemented already for the passive scalar, in the form of Newton cooling boundary condition. You can see how this is implemented in subroutine BCNEUSC. In your case ITYPE=-1 and CB=?c ' in the subroutine, and you need to only set ?HC? accordingly. We tested this and even our turbulent simulations are stable with Robin BC. Best regards, Sudhakar. > On 21 Apr 2017, at 20:35, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Neks > I'm trying to implement a slip-length (Robin) as boundary condition for a plane channel flow, namely: > (u+du/dy)_{wall}=0 > where x and y are the streamwise and wall normal directions respectively. > > Following the latter post: > http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html > > here there's what I came up with: > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > common /my_DEBUG/ rmodulate > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > n = nx1*ny1*nz1*nelv > !!!Build Up MASKS! > if (istep.eq.0) then > do i=1,n > x=xm1(i,1,1,1) > y=ym1(i,1,1,1) > if(x.gt.3.and.x.lt.4)then > ROBIN_mask(i,1,1,1)=1.0 > else > ROBIN_mask(i,1,1,1)=0.0 > endif > enddo > endif > !Compute velocity gradient > call rzero(graduy,n) > call gradm1(work1,graduy,work2,vx) > call dsavg(graduy) > ! call outpost(work1,graduy,work2,pr,t,'GRD') > !Da aggiungere l'eventualit? del 3D... > rmodulate = 0.5*(tanh(0.25*time-10)+1) > if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time > return > end > c----------------------------------------------------------------------- > c----------------------------------------------------------------------- > subroutine userbc (ix,iy,iz,iside,eg) > c NOTE ::: This subroutine MAY NOT be called by every process > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > integer e, eg > !Imposing Fancy Boundary Conditions... > ![Nek5000-users] Robin boundary conditions for the velocity > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > common /my_DEBUG/ rmodulate > e=gllel(eg) ! global element number to processor-local el. # > ux=1*graduy(ix,iy,iz,e)*rmodulate > uy=0.0 > uz=0.0 > return > end > c----------------------------------------------------------------------- > subroutine useric (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > ux=1.0*y**2 > uy=0.0 > uz=0.0 > temp=0 > return > end > c----------------------------------------------------------------------- > > The code becomes unstable in the gradient computation due to some point-to-point oscillations. > As you can see I've also tried to use a ramp function in order to make the onset of Robin condition more gentle, > but at a given "slip-length amplitude" oscillations deteriorates the solution. > I use ROBIN_mask in order to chose where to have such BC, but it seems that I'm still missing something in computing the velocity gradient GRD. > > By the way, this is my box.BOX file: > > base.rea > 2 spatial dimension ( < 0 --> generate .rea/.re2 pair) > 1 number of fields > #======================================================================= > # > # Example of .box file for channel flow > # > # If nelx (y or z) < 0, then genbox automatically generates the > # grid spacing in the x (y or z) direction > # with a geometric ratio given by "ratio". > # ( ratio=1 implies uniform spacing ) > # > # Note that the character bcs _must_ have 3 spaces. > # > #======================================================================= > # > Box > -32 -16 nelx,nely,nelz for Box > 0 6.2832 1. x0,x1,gain > -1 1 1. y0,y1,gain > P ,P ,v ,v , , bc's (3 chars each!) > > > I was wondering if you might be able to give me some advice. > > Best regards, > > Francesco > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Apr 23 04:47:55 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 23 Apr 2017 11:47:55 +0200 Subject: [Nek5000-users] Outflow reflections - Non reflective BCs Message-ID: Hi Neks, I am running a 2D axisymmetric case of a jet and I am having some problems with the outflow boundary. More specifically, whenever a vortex hits that boundary I get reflections. I have the ON condition along with turb_outflow with rq=10 (as high as it will go without crashing). I've also read something about non-reflective BCs in the archive, but it doesn't seem like they were finally implemented. Is there any way I could find them? If not, is there any other easier way to solve this? Thanks in advance for the help, MViturro From nek5000-users at lists.mcs.anl.gov Mon Apr 24 04:56:14 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 11:56:14 +0200 Subject: [Nek5000-users] Exact restart Message-ID: Hi Neks, May be my question is already asked, but I can't find the answer so I asked here: can I restart a simulation in an exact state as if it is run continuously? I have simulation that is extremely sensible to the initial condition and the simulation that is spitted in 2 separate runs give a completely difference solution as if it is run 1 single time. Thank you in advance, Quan From nek5000-users at lists.mcs.anl.gov Mon Apr 24 06:08:43 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 11:08:43 +0000 Subject: [Nek5000-users] Exact restart In-Reply-To: References: Message-ID: Dear Quan, There is a "full-restart" option for this. Please see the README in the "cyl_restart" example. 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: Monday, April 24, 2017 4:56 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Exact restart Hi Neks, May be my question is already asked, but I can't find the answer so I asked here: can I restart a simulation in an exact state as if it is run continuously? I have simulation that is extremely sensible to the initial condition and the simulation that is spitted in 2 separate runs give a completely difference solution as if it is run 1 single time. Thank you in advance, Quan _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Apr 24 10:01:57 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 17:01:57 +0200 Subject: [Nek5000-users] double mesh + solution at boundary + scalar blows up ! In-Reply-To: References: Message-ID: Dear Neks thank you Paul for your help on my double mesh question !! it works perfectly, and I am now testing quantitatively the results against published data. I am having two issues, one is likely stupid, and the other is likely more complex. stupid issue: When I try to plot the solution at the lower wall of the channel, it appears to be undefined. Is this normal / is there a way to access the solution at the lower wall of the channel ? (The velocity should vanish as I have no slip boundary conditions, but the scalar should not vanish as I have no-flux for the scalar.) complicatd issue: the flow starts from 0, it is forced by an average pressure gradients, has laminar initial condition+30% random fluctuations and it converges nicely. after the turbulent flow becomes stationary, i introduce the scalar, which develops in a nice fluctuating plume, looking reasonable. however, after some times, for no apparent reason, the scalar blows up. it sometimes produces NaN, and sometimes it doesnt. Can anyone think a reason why this happens? Reynolds = Peclet, and the scalar is injected at the inlet through the boundary condition. It does not blow up upon reaching the outlet (where I have outflow BC). I tried moving the source and making it bigger and model it as a Gaussian instead of a step function to avoid Gibbs oscillations. I also tried changing the boundary conditions from no flux to absorption (following https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2014-July/002961.html). I also halved diffusivity, so Pe = 1/2 Re, but no luck. is there any reason why the scalar should be more resolved than the flow ? is there any known numerical issue that i?m ignoring ? any hint would be fantastic. thanks a bunch ! Agnese > On Jan 21, 2017, at 7:00 PM, nek5000-users-request at lists.mcs.anl.gov wrote: > > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > Today's Topics: > > 1. Re: double mesh ? (nek5000-users at lists.mcs.anl.gov ) > > From: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] double mesh ? > Date: January 21, 2017 at 1:18:41 PM GMT+1 > To: "nek5000-users at lists.mcs.anl.gov " > > Reply-To: nek5000-users at lists.mcs.anl.gov > > > Dear Agnese, > > Attached is an example that shows how to modify the connectivity for the thermal > field to be inflow/outflow. > > If your domain is generated with genbox and your flow is in the x direction then > this should also work for 3D. > > Note that no changes are required to the .rea file (you should have "P " for both > velocity and temperature in the .rea/.box file). > > The changes occur in the .usr file. > > 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: Monday, January 16, 2017 9:31 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] double mesh ? > > Dear Paul > > thank you so much for your help ! > I am looking forward to see your example, it will be of great help ! > > could you tell me something more about the recycling BC as well ? > > Thank you again for your help > Agnese > >> >> From: nek5000-users at lists.mcs.anl.gov >> Subject: Re: [Nek5000-users] double mesh ? >> Date: January 16, 2017 at 4:05:21 PM GMT+1 >> To: "nek5000-users at lists.mcs.anl.gov " > >> Reply-To: nek5000-users at lists.mcs.anl.gov >> >> Dear Agnese, >> >> Sorry for the long delay in answering this question. The issue is that in fact it is possible >> (and used to be a supported but rarely used feature). The challenge, however, is how to >> make it relatively easy in the context of the current setup for a variety of applications. >> >> Nek supports a different gather-scatter handle for each field (velocity, temperature, passive >> scalar, etc.) >> >> We have a handle that allows the user access to the connectivity list, which would give >> you an opportunity to "disconnect" the periodic faces for the temperature array. >> >> I'll try to code up an example for the case of channel flow with a mesh generated by >> genbox and post it shortly. >> >> Incidentally, an alternative approach that we often use for more complex domains >> would be to use a recycling boundary condition. I think it would not be as efficient, >> however, as periodicity for the case that you propose. >> >> Once again, apologies for the delayed response. >> >> 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: Thursday, December 22, 2016 4:38 AM >> To: nek5000-users at lists.mcs.anl.gov >> Subject: [Nek5000-users] double mesh ? >> >> Hi >> >> i am quite new, so i?m sorry if i?m getting things wrong. >> >> I am trying to simulate a turbulent channel flow, with a passive scalar. >> in the streamwise direction, i would like to impose periodic boundary conditions for the flow, and non-periodic for the scalar. >> in fact the scalar has a point source near the inlet, and i want to see how that develops downstream. >> >> as far as i understand this is not supported by nek5000, because the last mesh point is identified with the first mesh point when periodic BC are imposed. >> correct ? >> >> my question is : could i define two meshes, one for the scalar and one for the velocity ? >> >> thanks a lot for your help !!! >> agnese >> >> >> Agnese Seminara >> -------------------------------- >> CNRS >> Laboratoire de physique de la mati?re condens?e >> Parc Valrose >> avenue J Vallot >> 06108 Nice, France >> +33 (0) 492 076 775 >> http://sites.unice.fr/site/aseminara/ >> >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 10:20:29 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 17:20:29 +0200 Subject: [Nek5000-users] Nek5000-users Digest, Vol 98, Issue 10 In-Reply-To: References: Message-ID: Hi Sudhakar, thank you for your reply. It seems to me that subroutine BCNEUSC is in charge of reading the "HC" value for all element faces withstanding the "c " boundary condition. Nevertheless there is no info about how to Robin boundary condition is effectively implemented within the solver. May I ask you to give me some more suggestions, in order to implement such BC on a velocity component? Best regards, Francesco 2017-04-22 12:36 GMT+02:00 : > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > > > Today's Topics: > > 1. Robin boundary condition on velocity > (nek5000-users at lists.mcs.anl.gov) > 2. Re: Robin boundary condition on velocity > (nek5000-users at lists.mcs.anl.gov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Apr 2017 20:35:23 +0200 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] Robin boundary condition on velocity > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi Neks > I'm trying to implement a slip-length (Robin) as boundary condition for a > plane channel flow, namely: > (u+du/dy)_{wall}=0 > where x and y are the streamwise and wall normal directions respectively. > > Following the latter post: > http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html > > here there's what I came up with: > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > common /my_DEBUG/ rmodulate > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > n = nx1*ny1*nz1*nelv > !!!Build Up MASKS! > if (istep.eq.0) then > do i=1,n > x=xm1(i,1,1,1) > y=ym1(i,1,1,1) > if(x.gt.3.and.x.lt.4)then > ROBIN_mask(i,1,1,1)=1.0 > else > ROBIN_mask(i,1,1,1)=0.0 > endif > enddo > endif > !Compute velocity gradient > call rzero(graduy,n) > call gradm1(work1,graduy,work2,vx) > call dsavg(graduy) > ! call outpost(work1,graduy,work2,pr,t,'GRD') > !Da aggiungere l'eventualit? del 3D... > rmodulate = 0.5*(tanh(0.25*time-10)+1) > if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time > return > end > c----------------------------------------------------------------------- > c----------------------------------------------------------------------- > subroutine userbc (ix,iy,iz,iside,eg) > c NOTE ::: This subroutine MAY NOT be called by every process > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > integer e, eg > !Imposing Fancy Boundary Conditions... > ![Nek5000-users] Robin boundary conditions for the velocity > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > common /my_DEBUG/ rmodulate > e=gllel(eg) ! global element number to processor-local el. # > ux=1*graduy(ix,iy,iz,e)*rmodulate > uy=0.0 > uz=0.0 > return > end > c----------------------------------------------------------------------- > subroutine useric (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > ux=1.0*y**2 > uy=0.0 > uz=0.0 > temp=0 > return > end > c----------------------------------------------------------------------- > > The code becomes unstable in the gradient computation due to some > point-to-point oscillations. > As you can see I've also tried to use a ramp function in order to make the > onset of Robin condition more gentle, > but at a given "slip-length amplitude" oscillations deteriorates the > solution. > I use ROBIN_mask in order to chose where to have such BC, but it seems that > I'm still missing something in computing the velocity gradient GRD. > > By the way, this is my box.BOX file: > > base.rea > 2 spatial dimension ( < 0 --> generate .rea/.re2 > pair) > 1 number of fields > #======================================================================= > # > # Example of .box file for channel flow > # > # If nelx (y or z) < 0, then genbox automatically generates the > # grid spacing in the x (y or z) direction > # with a geometric ratio given by "ratio". > # ( ratio=1 implies uniform spacing ) > # > # Note that the character bcs _must_ have 3 spaces. > # > #======================================================================= > # > Box > -32 -16 nelx,nely,nelz for Box > 0 6.2832 1. x0,x1,gain > -1 1 1. y0,y1,gain > P ,P ,v ,v , , bc's (3 chars each!) > > > I was wondering if you might be able to give me some advice. > > Best regards, > > Francesco > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170421/fcdeceb5/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Sat, 22 Apr 2017 12:35:45 +0200 > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Robin boundary condition on velocity > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi Francesco, > > Robin boundary condition is implemented already for the passive scalar, in > the form of Newton cooling boundary condition. You can see how this is > implemented in subroutine BCNEUSC. In your case ITYPE=-1 and CB=?c ' in > the subroutine, and you need to only set ?HC? accordingly. We tested this > and even our turbulent simulations are stable with Robin BC. > > Best regards, > Sudhakar. > > > On 21 Apr 2017, at 20:35, nek5000-users at lists.mcs.anl.gov wrote: > > > > Hi Neks > > I'm trying to implement a slip-length (Robin) as boundary condition for > a plane channel flow, namely: > > (u+du/dy)_{wall}=0 > > where x and y are the streamwise and wall normal directions respectively. > > > > Following the latter post: > > http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html > > > > > here there's what I came up with: > > > > c----------------------------------------------------------------------- > > subroutine userchk > > include 'SIZE' > > include 'TOTAL' > > common /my_DEBUG/ rmodulate > > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > > $ , work1(lx1,ly1,lz1,lelt) > > $ , work2(lx1,ly1,lz1,lelt) > > $ , graduy(lx1,ly1,lz1,lelt) > > n = nx1*ny1*nz1*nelv > > !!!Build Up MASKS! > > if (istep.eq.0) then > > do i=1,n > > x=xm1(i,1,1,1) > > y=ym1(i,1,1,1) > > if(x.gt.3.and.x.lt.4)then > > ROBIN_mask(i,1,1,1)=1.0 > > else > > ROBIN_mask(i,1,1,1)=0.0 > > endif > > enddo > > endif > > !Compute velocity gradient > > call rzero(graduy,n) > > call gradm1(work1,graduy,work2,vx) > > call dsavg(graduy) > > ! call outpost(work1,graduy,work2,pr,t,'GRD') > > !Da aggiungere l'eventualit? del 3D... > > rmodulate = 0.5*(tanh(0.25*time-10)+1) > > if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time > > return > > end > > c----------------------------------------------------------------------- > > c----------------------------------------------------------------------- > > subroutine userbc (ix,iy,iz,iside,eg) > > c NOTE ::: This subroutine MAY NOT be called by every process > > include 'SIZE' > > include 'TOTAL' > > include 'NEKUSE' > > integer e, eg > > !Imposing Fancy Boundary Conditions... > > ![Nek5000-users] Robin boundary conditions for the velocity > > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > > $ , work1(lx1,ly1,lz1,lelt) > > $ , work2(lx1,ly1,lz1,lelt) > > $ , graduy(lx1,ly1,lz1,lelt) > > common /my_DEBUG/ rmodulate > > e=gllel(eg) ! global element number to processor-local el. # > > ux=1*graduy(ix,iy,iz,e)*rmodulate > > uy=0.0 > > uz=0.0 > > return > > end > > c----------------------------------------------------------------------- > > subroutine useric (ix,iy,iz,ieg) > > include 'SIZE' > > include 'TOTAL' > > include 'NEKUSE' > > ux=1.0*y**2 > > uy=0.0 > > uz=0.0 > > temp=0 > > return > > end > > c----------------------------------------------------------------------- > > > > The code becomes unstable in the gradient computation due to some > point-to-point oscillations. > > As you can see I've also tried to use a ramp function in order to make > the onset of Robin condition more gentle, > > but at a given "slip-length amplitude" oscillations deteriorates the > solution. > > I use ROBIN_mask in order to chose where to have such BC, but it seems > that I'm still missing something in computing the velocity gradient GRD. > > > > By the way, this is my box.BOX file: > > > > base.rea > > 2 spatial dimension ( < 0 --> generate .rea/.re2 > pair) > > 1 number of fields > > #======================================================================= > > # > > # Example of .box file for channel flow > > # > > # If nelx (y or z) < 0, then genbox automatically generates the > > # grid spacing in the x (y or z) direction > > # with a geometric ratio given by "ratio". > > # ( ratio=1 implies uniform spacing ) > > # > > # Note that the character bcs _must_ have 3 spaces. > > # > > #======================================================================= > > # > > Box > > -32 -16 nelx,nely,nelz for Box > > 0 6.2832 1. x0,x1,gain > > -1 1 1. y0,y1,gain > > P ,P ,v ,v , , bc's (3 chars each!) > > > > > > I was wondering if you might be able to give me some advice. > > > > Best regards, > > > > Francesco > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170422/42c96cbe/attachment.html> > > ------------------------------ > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > End of Nek5000-users Digest, Vol 98, Issue 10 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 10:21:38 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 17:21:38 +0200 Subject: [Nek5000-users] Reading boundary condition from an external file Message-ID: Hi, I am supposed to carry out a simulation where I have to use the flow profile at the outflow boundary of the first computational domain as the inflow condition for the second domain. The first domain consists of a cylinder and the second domain is empty. Consequently, the meshes in the two situations are different. The study will help us in understanding the far wake characteristics of a bluff body. I checked the Nek archives and found a thread on similar topic. At that time, however, it was concluded that carrying out this exercise on parallel is quite challenging (at least this is what I understood from the thread). I would like to know if there has been any development in this direction? Or is there some trick that I can do to achieve this? Many thanks, N. From nek5000-users at lists.mcs.anl.gov Mon Apr 24 11:10:32 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 12:10:32 -0400 Subject: [Nek5000-users] Time derivative of Scalar field Message-ID: Hello Neks, I want to find out the time derivative of Scalar field in my Rayleigh Benard calculations. Can you give me any idea how to go about it? Right now I get the scalar field only along with the primitive variables. But I want to get the time derivative field of the scalars (dc/dt). Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 11:20:31 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 16:20:31 +0000 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: Message-ID: Hi Saikat, Any reason to not save a few time steps and apply finite differences? 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: Monday, April 24, 2017 11:10 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Time derivative of Scalar field Hello Neks, I want to find out the time derivative of Scalar field in my Rayleigh Benard calculations. Can you give me any idea how to go about it? Right now I get the scalar field only along with the primitive variables. But I want to get the time derivative field of the scalars (dc/dt). Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 11:24:36 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 12:24:36 -0400 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: Message-ID: Hey Paul, In my case, the time step is very small, and I want the scalars (initially a small gaussian blob in the center of the cylindrical domain) to hit the wall. For that to happen I need too many files to print out. Right now I am printing them out at 0.1*(vertical diffusion time) and get say 100 files to hit the wall. While my time step is 1e-4 * (vertical diffusion time) for RB convection. Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Mon, Apr 24, 2017 at 12:20 PM, wrote: > > Hi Saikat, > > Any reason to not save a few time steps and apply finite differences? > > 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:* Monday, April 24, 2017 11:10 AM > *To:* nek5000-users at lists.mcs.anl.gov > *Subject:* [Nek5000-users] Time derivative of Scalar field > > Hello Neks, > > I want to find out the time derivative of Scalar field in my Rayleigh > Benard calculations. Can you give me any idea how to go about it? Right now > I get the scalar field only along with the primitive variables. But I want > to get the time derivative field of the scalars (dc/dt). > > Thanks, > Saikat > > Saikat Mukherjee, > PhD Student, > Paul Research Group - http://www.me.vt.edu/mpaul/ > Engineering Science and Mechanics, > Virginia Tech. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 11:44:56 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 16:44:56 +0000 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: , Message-ID: Can you just save them without writing them out? I would compute the time derivative during the run and then write that out? ________________________________ 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: Monday, April 24, 2017 11:24 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Time derivative of Scalar field Hey Paul, In my case, the time step is very small, and I want the scalars (initially a small gaussian blob in the center of the cylindrical domain) to hit the wall. For that to happen I need too many files to print out. Right now I am printing them out at 0.1*(vertical diffusion time) and get say 100 files to hit the wall. While my time step is 1e-4 * (vertical diffusion time) for RB convection. Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Mon, Apr 24, 2017 at 12:20 PM, > wrote: Hi Saikat, Any reason to not save a few time steps and apply finite differences? 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: Monday, April 24, 2017 11:10 AM To: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Time derivative of Scalar field Hello Neks, I want to find out the time derivative of Scalar field in my Rayleigh Benard calculations. Can you give me any idea how to go about it? Right now I get the scalar field only along with the primitive variables. But I want to get the time derivative field of the scalars (dc/dt). Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Apr 24 13:00:53 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Apr 2017 14:00:53 -0400 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: Message-ID: Hey Paul, Thanks for the reply. Yes, I wan't to know how to go about computing the time derivative during the run and write that out each time I write my .fld files. Yes there any subroutine in the .usr file that I can call? Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Mon, Apr 24, 2017 at 12:44 PM, wrote: > > Can you just save them without writing them out? > > I would compute the time derivative during the run and then write that out? > > > ------------------------------ > *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:* Monday, April 24, 2017 11:24 AM > *To:* nek5000-users at lists.mcs.anl.gov > *Subject:* Re: [Nek5000-users] Time derivative of Scalar field > > Hey Paul, > > In my case, the time step is very small, and I want the scalars (initially > a small gaussian blob in the center of the cylindrical domain) to hit the > wall. For that to happen I need too many files to print out. Right now I am > printing them out at 0.1*(vertical diffusion time) and get say 100 files to > hit the wall. While my time step is 1e-4 * (vertical diffusion time) for RB > convection. > > Thanks, > Saikat > > Saikat Mukherjee, > PhD Student, > Paul Research Group - http://www.me.vt.edu/mpaul/ > Engineering Science and Mechanics, > Virginia Tech. > > On Mon, Apr 24, 2017 at 12:20 PM, wrote: > >> >> Hi Saikat, >> >> Any reason to not save a few time steps and apply finite differences? >> >> 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:* Monday, April 24, 2017 11:10 AM >> *To:* nek5000-users at lists.mcs.anl.gov >> *Subject:* [Nek5000-users] Time derivative of Scalar field >> >> Hello Neks, >> >> I want to find out the time derivative of Scalar field in my Rayleigh >> Benard calculations. Can you give me any idea how to go about it? Right now >> I get the scalar field only along with the primitive variables. But I want >> to get the time derivative field of the scalars (dc/dt). >> >> Thanks, >> Saikat >> >> Saikat Mukherjee, >> PhD Student, >> Paul Research Group - http://www.me.vt.edu/mpaul/ >> Engineering Science and Mechanics, >> Virginia Tech. >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 25 03:17:27 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Apr 2017 10:17:27 +0200 Subject: [Nek5000-users] Robin boundary condition on velocity In-Reply-To: References: Message-ID: Hi Francesco, BCNEUSC computes the contribution of Robin boundary condition to the diagonal components of the matrix (if ITYPE=-1), and to the RHS (if ITYPE=1). You can read the nek5000 manual about Newton cooling BC, and you will understand immediately what is being done. In your specific case, you do not have an RHS contribution. You can see that this subroutine BCNEUSC computes matrix "S" which is added to "H2" (see subroutine CDSCAL). In your case, you need to do the same thing for Navier-Stokes. If you have Robin BC for vx and other BC for vy, you need to define H2 for each direction. Note that this works only when IFSTRS=false your rea file. Hope this helps! Sudhakar. On 04/24/2017 05:20 PM, nek5000-users at lists.mcs.anl.gov wrote: > Hi Sudhakar, > thank you for your reply. > > It seems to me that subroutine BCNEUSC is in charge of reading the > "HC" value for all element faces withstanding the "c " boundary > condition. > Nevertheless there is no info about how to Robin boundary condition is > effectively implemented within the solver. > > May I ask you to give me some more suggestions, in order to implement > such BC on a velocity component? > > Best regards, > > Francesco > > 2017-04-22 12:36 GMT+02:00 >: > > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > > > Today's Topics: > > 1. Robin boundary condition on velocity > (nek5000-users at lists.mcs.anl.gov > ) > 2. Re: Robin boundary condition on velocity > (nek5000-users at lists.mcs.anl.gov > ) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Apr 2017 20:35:23 +0200 > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Subject: [Nek5000-users] Robin boundary condition on velocity > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi Neks > I'm trying to implement a slip-length (Robin) as boundary > condition for a > plane channel flow, namely: > (u+du/dy)_{wall}=0 > where x and y are the streamwise and wall normal directions > respectively. > > Following the latter post: > http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html > > > here there's what I came up with: > > c----------------------------------------------------------------------- > subroutine userchk > include 'SIZE' > include 'TOTAL' > common /my_DEBUG/ rmodulate > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > n = nx1*ny1*nz1*nelv > !!!Build Up MASKS! > if (istep.eq.0) then > do i=1,n > x=xm1(i,1,1,1) > y=ym1(i,1,1,1) > if(x.gt.3.and.x.lt.4)then > ROBIN_mask(i,1,1,1)=1.0 > else > ROBIN_mask(i,1,1,1)=0.0 > endif > enddo > endif > !Compute velocity gradient > call rzero(graduy,n) > call gradm1(work1,graduy,work2,vx) > call dsavg(graduy) > ! call outpost(work1,graduy,work2,pr,t,'GRD') > !Da aggiungere l'eventualit? del 3D... > rmodulate = 0.5*(tanh(0.25*time-10)+1) > if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time > return > end > c----------------------------------------------------------------------- > c----------------------------------------------------------------------- > subroutine userbc (ix,iy,iz,iside,eg) > c NOTE ::: This subroutine MAY NOT be called by every process > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > integer e, eg > !Imposing Fancy Boundary Conditions... > ![Nek5000-users] Robin boundary conditions for the velocity > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > $ , work1(lx1,ly1,lz1,lelt) > $ , work2(lx1,ly1,lz1,lelt) > $ , graduy(lx1,ly1,lz1,lelt) > common /my_DEBUG/ rmodulate > e=gllel(eg) ! global element number to processor-local el. # > ux=1*graduy(ix,iy,iz,e)*rmodulate > uy=0.0 > uz=0.0 > return > end > c----------------------------------------------------------------------- > subroutine useric (ix,iy,iz,ieg) > include 'SIZE' > include 'TOTAL' > include 'NEKUSE' > ux=1.0*y**2 > uy=0.0 > uz=0.0 > temp=0 > return > end > c----------------------------------------------------------------------- > > The code becomes unstable in the gradient computation due to some > point-to-point oscillations. > As you can see I've also tried to use a ramp function in order to > make the > onset of Robin condition more gentle, > but at a given "slip-length amplitude" oscillations deteriorates the > solution. > I use ROBIN_mask in order to chose where to have such BC, but it > seems that > I'm still missing something in computing the velocity gradient GRD. > > By the way, this is my box.BOX file: > > base.rea > 2 spatial dimension ( < 0 --> generate > .rea/.re2 pair) > 1 number of fields > #======================================================================= > # > # Example of .box file for channel flow > # > # If nelx (y or z) < 0, then genbox automatically generates the > # grid spacing in the x (y or z) direction > # with a geometric ratio given by "ratio". > # ( ratio=1 implies uniform spacing ) > # > # Note that the character bcs _must_ have 3 spaces. > # > #======================================================================= > # > Box > -32 -16 nelx,nely,nelz for Box > 0 6.2832 1. x0,x1,gain > -1 1 1. y0,y1,gain > P ,P ,v ,v , , bc's (3 chars > each!) > > > I was wondering if you might be able to give me some advice. > > Best regards, > > Francesco > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Message: 2 > Date: Sat, 22 Apr 2017 12:35:45 +0200 > From: nek5000-users at lists.mcs.anl.gov > > To: nek5000-users at lists.mcs.anl.gov > > Subject: Re: [Nek5000-users] Robin boundary condition on velocity > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi Francesco, > > Robin boundary condition is implemented already for the passive > scalar, in the form of Newton cooling boundary condition. You can > see how this is implemented in subroutine BCNEUSC. In your case > ITYPE=-1 and CB=?c ' in the subroutine, and you need to only set > ?HC? accordingly. We tested this and even our turbulent > simulations are stable with Robin BC. > > Best regards, > Sudhakar. > > > On 21 Apr 2017, at 20:35, nek5000-users at lists.mcs.anl.gov > wrote: > > > > Hi Neks > > I'm trying to implement a slip-length (Robin) as boundary > condition for a plane channel flow, namely: > > (u+du/dy)_{wall}=0 > > where x and y are the streamwise and wall normal directions > respectively. > > > > Following the latter post: > > > http://lists.mcs.anl.gov/pipermail/nek5000-users/2011-April/001313.html > > > > > > > here there's what I came up with: > > > > > c----------------------------------------------------------------------- > > subroutine userchk > > include 'SIZE' > > include 'TOTAL' > > common /my_DEBUG/ rmodulate > > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > > $ , work1(lx1,ly1,lz1,lelt) > > $ , work2(lx1,ly1,lz1,lelt) > > $ , graduy(lx1,ly1,lz1,lelt) > > n = nx1*ny1*nz1*nelv > > !!!Build Up MASKS! > > if (istep.eq.0) then > > do i=1,n > > x=xm1(i,1,1,1) > > y=ym1(i,1,1,1) > > if(x.gt.3.and.x.lt.4)then > > ROBIN_mask(i,1,1,1)=1.0 > > else > > ROBIN_mask(i,1,1,1)=0.0 > > endif > > enddo > > endif > > !Compute velocity gradient > > call rzero(graduy,n) > > call gradm1(work1,graduy,work2,vx) > > call dsavg(graduy) > > ! call outpost(work1,graduy,work2,pr,t,'GRD') > > !Da aggiungere l'eventualit? del 3D... > > rmodulate = 0.5*(tanh(0.25*time-10)+1) > > if (nid.eq.0) write(6,*)"MODULATE", rmodulate,time > > return > > end > > > c----------------------------------------------------------------------- > > > c----------------------------------------------------------------------- > > subroutine userbc (ix,iy,iz,iside,eg) > > c NOTE ::: This subroutine MAY NOT be called by every process > > include 'SIZE' > > include 'TOTAL' > > include 'NEKUSE' > > integer e, eg > > !Imposing Fancy Boundary Conditions... > > ![Nek5000-users] Robin boundary conditions for the velocity > > common /my_ROBIN/ ROBIN_mask(lx1,ly1,lz1,lelt) > > $ , work1(lx1,ly1,lz1,lelt) > > $ , work2(lx1,ly1,lz1,lelt) > > $ , graduy(lx1,ly1,lz1,lelt) > > common /my_DEBUG/ rmodulate > > e=gllel(eg) ! global element number to processor-local el. # > > ux=1*graduy(ix,iy,iz,e)*rmodulate > > uy=0.0 > > uz=0.0 > > return > > end > > > c----------------------------------------------------------------------- > > subroutine useric (ix,iy,iz,ieg) > > include 'SIZE' > > include 'TOTAL' > > include 'NEKUSE' > > ux=1.0*y**2 > > uy=0.0 > > uz=0.0 > > temp=0 > > return > > end > > > c----------------------------------------------------------------------- > > > > The code becomes unstable in the gradient computation due to > some point-to-point oscillations. > > As you can see I've also tried to use a ramp function in order > to make the onset of Robin condition more gentle, > > but at a given "slip-length amplitude" oscillations deteriorates > the solution. > > I use ROBIN_mask in order to chose where to have such BC, but it > seems that I'm still missing something in computing the velocity > gradient GRD. > > > > By the way, this is my box.BOX file: > > > > base.rea > > 2 spatial dimension ( < 0 --> generate > .rea/.re2 pair) > > 1 number of fields > > > #======================================================================= > > # > > # Example of .box file for channel flow > > # > > # If nelx (y or z) < 0, then genbox automatically generates the > > # grid spacing in the x (y or z) direction > > # with a geometric ratio given by "ratio". > > # ( ratio=1 implies uniform spacing ) > > # > > # Note that the character bcs _must_ have 3 spaces. > > # > > > #======================================================================= > > # > > Box > > -32 -16 nelx,nely,nelz for Box > > 0 6.2832 1. x0,x1,gain > > -1 1 1. y0,y1,gain > > P ,P ,v ,v , , bc's (3 chars each!) > > > > > > I was wondering if you might be able to give me some advice. > > > > Best regards, > > > > Francesco > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > End of Nek5000-users Digest, Vol 98, Issue 10 > ********************************************* > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 25 11:29:35 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Apr 2017 12:29:35 -0400 Subject: [Nek5000-users] Time derivative of Scalar field Message-ID: Hello Neks, I want to find out the time derivative of Scalar field in my Rayleigh Benard calculations. I wan't to know how to go about computing the time derivative during the run, and write that out each time I write my .fld files. Is there any subroutine in the .usr file that I can call? Thanks, Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 25 13:06:23 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Apr 2017 18:06:23 +0000 Subject: [Nek5000-users] Time derivative of Scalar field Message-ID: Hi Saikat, I have attached a usr file that shows how to calculate finite difference based first derivative of the first passive scalar t(1,1,1,1,2) using the current time step and two previous time steps. The coefficients for the derivative are obtained using a call to fd_weights_full, and I am using a common block for storing the values of the scalar at two previous time-steps. Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t0.usr Type: application/octet-stream Size: 2887 bytes Desc: t0.usr URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 25 17:42:11 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Apr 2017 22:42:11 +0000 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: Message-ID: Thanks Ketan. Saikat, You may also be able to just use the values in vxlag() and thus avoid the need for extra storage. A simple test would verify.. Of course, it's not that expensive to just store your own copies for purposes of your own analysis. 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, April 25, 2017 1:06 PM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Time derivative of Scalar field Hi Saikat, I have attached a usr file that shows how to calculate finite difference based first derivative of the first passive scalar t(1,1,1,1,2) using the current time step and two previous time steps. The coefficients for the derivative are obtained using a call to fd_weights_full, and I am using a common block for storing the values of the scalar at two previous time-steps. Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Apr 25 18:00:17 2017 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Apr 2017 19:00:17 -0400 Subject: [Nek5000-users] Time derivative of Scalar field In-Reply-To: References: Message-ID: Thanks Ketan and Paul. Saikat Saikat Mukherjee, PhD Student, Paul Research Group - http://www.me.vt.edu/mpaul/ Engineering Science and Mechanics, Virginia Tech. On Tue, Apr 25, 2017 at 6:42 PM, wrote: > > Thanks Ketan. > > Saikat, > > You may also be able to just use the values in vxlag() and thus avoid the > need > for extra storage. > > A simple test would verify.. Of course, it's not that expensive to just > store your > own copies for purposes of your own analysis. > > 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, April 25, 2017 1:06 PM > *To:* nek5000-users at lists.mcs.anl.gov > *Subject:* Re: [Nek5000-users] Time derivative of Scalar field > > Hi Saikat, > > I have attached a usr file that shows how to calculate finite difference > based first derivative of the first passive scalar t(1,1,1,1,2) using the > current time step and two previous time steps. The coefficients for the > derivative are obtained using a call to fd_weights_full, and I am using a > common block for storing the values of the scalar at two previous > time-steps. > > Ketan > > > > > > > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: