- Nektar-users - imperial.ac.uk

Problem 3D CompressibleFlowSolver
by Selbach, Fabian 13 Jul '16

13 Jul '16

Hello, i need your feedback about the simulation of a 3 dimensional flow around a cylinder or a NACA-profile with the CompressibleFlowSolver of the NavierStokesCFE or the EulerCFE. In every case the simulation starts, but always ends at the point of "Writing: "file_0.chk" " due to time-limit of the Cluster (limited to 1 day). I tried several times. The parameters, Solver Info and so on were shown (see below). In 2D there is not such a problem. So my question is, if it depends on the calculation capacity (CPU etc.) or what the reason for this? Actually iam calculating on a Cluster with 10 nodes and 120 CPUs. I think, that the calculation normally should be faster and another time-step should be done after one day or is it normal to a 3D-simulation with the compressible solver? So please can you give me an advice about the Problem? For example the 3D-problem of the cylinder with the CompressibleFlowSolver with the NavierStokesCFE produces this output after one day of calculation: (The example with the cylinder is exact the same you published at this page: http://www.nektar.info/compressible-flow/ ) Parameters: ALPHA = 0 CINF = 294.827 CP = 1004.7 FINTIME = 2 GAMMA = 1.4 GASCONSTANT = 287.058 IO_CHECKSTEPS = 50000 IO_INFOSTEPS = 1 KAPPA = 0.1 L = 1 MACH = 0.1 MU = 0.00275172 MU0 = 0.5 NUMSTEPS = 2e+06 PINF = 22600 PR = 0.72 RE = 3900 RHOINF = 0.364 SKAPPA = -2.3 THERMALCONDUCTIVITY = 3.83981 TIMESTEP = 1e-06 TINF = 216.29 TWALL = 216.29 UINF = 29.4827 VINF = 0 WINF = 0 Solver Info: ADVECTIONTYPE = WeakDG DIFFUSIONTYPE = LDGNS DRIVER = Standard EQTYPE = NavierStokesCFE EVOLUTIONOPERATOR = Nonlinear GLOBALMATRIXSTORAGETYPE = SmvBSR GLOBALSYSSOLN = IterativeStaticCond LINEARPRECONSOLVER = Xxt LOCALMATRIXSTORAGESTRATEGY = Sparse PRECONDITIONER = Diagonal PROBLEMTYPE = General PROJECTION = DisContinuous TIMEINTEGRATIONMETHOD = RungeKutta2_ImprovedEuler UPWINDTYPE = ExactToro VISCOSITYTYPE = Variable gs_setup: 240784 unique labels shared pairwise times (avg, min, max): 0.000148432 0.000120687 0.000157881 crystal router : 0.000947791 0.000929117 0.000967693 used all_to_all method: pairwise handle bytes (avg, min, max): 241216 152740 313476 buffer bytes (avg, min, max): 160523 101632 208640 gs_setup: 1187072 unique labels shared pairwise times (avg, min, max): 0.000483757 0.000410008 0.000513387 crystal router : 0.0109781 0.0108864 0.01108 used all_to_all method: pairwise handle bytes (avg, min, max): 1.18751e+06 656164 1481220 buffer bytes (avg, min, max): 791381 437248 987136 gs_setup: 240784 unique labels shared pairwise times (avg, min, max): 0.000113803 9.51052e-05 0.000123191 crystal router : 0.000868803 0.000849199 0.000890398 used all_to_all method: pairwise handle bytes (avg, min, max): 241216 152740 313476 buffer bytes (avg, min, max): 160523 101632 208640 gs_setup: 1187072 unique labels shared pairwise times (avg, min, max): 0.000463862 0.000412512 0.000496101 crystal router : 0.00953256 0.00941629 0.0096302 used all_to_all method: pairwise handle bytes (avg, min, max): 1.18751e+06 656164 1481220 buffer bytes (avg, min, max): 791381 437248 987136 gs_setup: 240784 unique labels shared pairwise times (avg, min, max): 0.000115333 9.5892e-05 0.000125098 crystal router : 0.00325584 0.0032357 0.0032764 used all_to_all method: pairwise handle bytes (avg, min, max): 241216 152740 313476 buffer bytes (avg, min, max): 160523 101632 208640 gs_setup: 1187072 unique labels shared pairwise times (avg, min, max): 0.00103487 0.00097959 0.00105419 crystal router : 0.00855757 0.00837069 0.0108672 used all_to_all method: pairwise handle bytes (avg, min, max): 1.18751e+06 656164 1481220 buffer bytes (avg, min, max): 791381 437248 987136 gs_setup: 240784 unique labels shared pairwise times (avg, min, max): 0.000114435 8.49009e-05 0.000136399 crystal router : 0.00204957 0.0020185 0.00207429 used all_to_all method: pairwise handle bytes (avg, min, max): 241216 152740 313476 buffer bytes (avg, min, max): 160523 101632 208640 gs_setup: 1187072 unique labels shared pairwise times (avg, min, max): 0.000471148 0.0004215 0.000498414 crystal router : 0.00977638 0.0085747 0.0109815 used all_to_all method: pairwise handle bytes (avg, min, max): 1.18751e+06 656164 1481220 buffer bytes (avg, min, max): 791381 437248 987136 gs_setup: 240784 unique labels shared pairwise times (avg, min, max): 0.000113707 9.59873e-05 0.000121403 crystal router : 0.000872626 0.000852704 0.00089221 used all_to_all method: pairwise handle bytes (avg, min, max): 241216 152740 313476 buffer bytes (avg, min, max): 160523 101632 208640 gs_setup: 1187072 unique labels shared pairwise times (avg, min, max): 0.000467315 0.000390005 0.000493503 crystal router : 0.010846 0.0107322 0.0109444 used all_to_all method: pairwise handle bytes (avg, min, max): 1.18751e+06 656164 1481220 buffer bytes (avg, min, max): 791381 437248 987136 ======================================================================= EquationType: NavierStokesCFE Session Name: Cylinder_NS_3D Spatial Dim.: 3 Max SEM Exp. Order: 4 Expansion Dim.: 3 Riemann Solver: ExactToro Advection Type: Projection Type: Discontinuous Galerkin Diffusion Type: Advection: explicit AdvectionType: WeakDG Diffusion: explicit Time Step: 1e-06 No. of Steps: 2000000 Checkpoints (steps): 50000 Integration Type: RungeKutta2_ImprovedEuler Problem Type: General ======================================================================= Initial Conditions: - Field rho: rhoInf - Field rhou: rhoInf * uInf - Field rhov: rhoInf * vInf - Field rhow: rhoInf * wInf - Field E: pInf / (Gamma - 1) + 0.5 * rhoInf * (uInf * uInf + vInf * vInf + wInf * wInf) Writing: "Cylinder_NS_3D_0.chk" slurmstepd: *** JOB 930941 CANCELLED AT 2016-07-06T03:27:36 DUE TO TIME LIMIT *** I run the solver by: "mpirun -np 120 CompressibleFlowSolver -v 3D_cylinder_mesh.xml 3D_cylinder_conditions.xml" Thanks for any hint. If you need more information, please let me know . Best regards Fabian Selbach University of Siegen

5 14

Problem after parallelization
by Amitvikram Dutta 12 Jul '16

12 Jul '16

Hi all, Recently I was made aware that there could be a possible problem with how nektar++ had been compiled on the cluster that I was trying to run it on. Apparently nektar++ had not been compiled with the MPI turned on with the result being that it was not parallelizing properly. After I pointed this out to the system administrator he went on to fix this issue. After fixing this however, whenever I try to submit a job I get the following error *mpirun has exited due to process rank 18 with PID 8273 onnode pod16a5.ibb exiting improperly. There are two reasons this could occur:1. this process did not call "init" before exiting, but others inthe job did. This can cause a job to hang indefinitely while it waitsfor all processes to call "init". By rule, if one process calls "init",then ALL processes must call "init" prior to termination.2. this process called "init", but exited without calling "finalize".By rule, all processes that call "init" MUST call "finalize" prior toexiting or it will be considered an "abnormal termination"This may have caused other processes in the application to beterminated by signals sent by mpirun (as reported here).* Note however, that when I try to run the same problem in serial mode there are no problems. I was hoping someone could shed light on any well-known issues regarding this. Sincerely, -- *Amitvikram Dutta* *MASc Candidate* *Graduate Research Assistant * *Okanagan CFD Laboratory* *University of British Columbia | Okanagan Campus*

2 1

VTK/Tecplot to FLD
by Lander, Marcus David 11 Jul '16

11 Jul '16

So, here is my situation: I am trying to introduce noise into my initial conditions for a Turbulent Channel DNS using awgn(). Currently, it is set up along the lines of u = 1.0 + 0.1*awgn(1.0). However, for what we are doing, we need this initial noise to be symmetric over the XY-plane at the middle of the channel (i.e. the bottom half is identical to the top half). I have been trying various combinations of modules in FieldConvert, but I feel as though I'm missing something. (If you could offer and insight on this, that would be great.) My other idea was to bring the initial field into a program such as paraview, and then make the necessary edits there. However, after reading and tinkering, I don't believe that FieldConvert has the ability to read in a VTK file and convert it back to a FLD file. Is there any way to actually read in data from a source such as VTK file or some other non-Nektar++ source? I tried this with a tecplot file, but it does not seem to want to read it.

2 1

Full 3D stability
by Stanisław Gepner 26 Jun '16

26 Jun '16

Dear all, Could you please tell me if it is possible to perform stability analysis of a fully 3D flow. From what I can see in the code this feature is currently limited to 2D and 2.5D cases. Is this so? Kind regards, Stan Gepner Sorry if you are getting this message twice, for some reason it did not go through the first time. I could not find it in the archives.

2 1

REQUEST FOR ASSISTANCE
by MATTHEW ADEWOLE 23 Jun '16

23 Jun '16

Sir/Ma, I have a problem with the installation of Nektar++ on my laptop computer. I followed the instructions as stated in the user guide. Attached is the error reports. Please help me as I need the software for my Ph.D work.Thanks. Adewole Matthew,Ph.D student,University of Ibadan,Nigeria.

2 1

Turbulent Channel Flow Example
by Lander, Marcus David 09 Jun '16

09 Jun '16

So, I have been running through all the examples given thus far, and I'm curious about the Turbulent Channel Flow example. I have been running the simulation for a decent amount of time, but I still do not seem to be gaining a solution that resembles what is shown in the user guide. I have also included the recommended modifications made in this post: https://mailman.ic.ac.uk/mailman/htdig/nektar-users/2016-May/000371.html My questions regarding the turbulent channel case are: 1) Approximately how long does the simulation need to run in terms of "in-simulation-time" before I can expect to see something similar to what is shown in the user-guide? Currently, mine is at 26.8299 seconds, with a time-step of 0.0001 (as per the original example). 2) When the case in the user-guide was generated, was it done in serial??? I have been running this in parallel to try and speed it along because our job queue only allows us one hour of execution at a time.

2 1

Calculating memory for a job
by Amitvikram Dutta 05 Jun '16

05 Jun '16

Hi everyone, How would I go about calculating the memory requirements necessary for a particular job? I have a 23k cell mesh problem, that keeps getting deleted from my cluster because of exceeding memory usage requirements. Sincerely, -- *Amitvikram Dutta* *MASc Candidate* *Graduate Research Assistant * *Okanagan CFD Laboratory* *University of British Columbia | Okanagan Campus*

2 5

Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach
by Asim Onder 01 Jun '16

01 Jun '16

Hi Douglas, thanks for the feedback. I was aware of --npz parallelization but was using a small number, not 1/2 or 1/4 of HomModesZ. Increasing npz really helped. I still have to try GlobalSysSoln. Now I face a memory problem for another case. The simulation runs out of memory when starting from a checkpoint file. Here is a little bit information about this case: - Mesh is made of around 16000 quad elements with p=5, i.e., NUMMODES="6" TYPE="MODIFIED" in xy, and HomModesZ=1080 in z direction. - I'm trying to run this case on 60 computing nodes each equipped with 24 processors, and a memory of 105 gb. In total, it makes 1440 procs, and 6300gb memory. - Execution command: mpirun -np 1440 IncNavierStokesSolver --npz 360 config.xml I was wondering if the memory usage of the application is scaling on different cores during IO, or using only one core. If it is only one core, than if it exceeds 105gb, it crushes I guess. Would you have maybe any suggestion/comment on this? Thanks, Asim On 04/13/2016 12:12 AM, Serson, Douglas wrote: Hi Asim, Concerning your questions: 1- Are you using the command line argument --npz? This is very important for obtaining an efficient parallel performance with the Fourier expansion, since it defines the number of partitions in the z-direction. If it is not set, only the xy plane will be partitioned and the parallelism will saturate quickly. I suggest initially setting npz to 1/2 or 1/4 of HomModesZ (note that nprocs must be a multiple of npz, since nprocs/npz is the number of partitions in the xy plane). Also, depending on your particular case and the number of partitions you have in the xy plane, your simulation may benefit from using a direct solver for the linear systems. This can be activated by adding '-I GlobalSysSoln=XxtMultiLevelStaticCond' to the command line. This is usually more efficient for a small number of partitions, but considering the large size of your problem it might be worth trying it. 2- I am not sure what could be causing that. I suppose it would help if you could send the exact commands you are using to run FieldConvert. Cheers, Douglas ________________________________ From: Asim Onder <ceeao(a)nus.edu.sg><mailto:ceeao@nus.edu.sg> Sent: 12 April 2016 06:42 To: Sherwin, Spencer J; Serson, Douglas Cc: nektar-users; Moxey, David Subject: Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach Dear Spencer, Douglas, Nektar-users, I'm involved now in testing of a local petascale supercomputer, and for some quite limited time I can use several thousand processors for my DNS study. My test case is oscillating flow over a rippled bed. I build up a dense unstructured grid with p=6 quadrilateral elements in x-y, and Fourier expansions in z directions. In total I have circa half billion dofs per variable. I would have a few questions about this relatively large case: 1. I noticed that scaling gets inefficient after around 500 procs, let's say parallel efficiency goes below 80%. I was wondering if you would have any general suggestions to tune the configurations for a better scaling. 2. Postprocessing vorticity and Q criterion is not working for this case. At the of the execution Fieldconvert writes some small files without the field data. What could be the reason for this? Thanks you in advance for your suggestions. Cheers, Asim On 03/21/2016 04:16 AM, Sherwin, Spencer J wrote: Hi Asim, To follow-up on Douglas’ comment we are trying to get more organised to sort out a developers guide. We are also holding a user meeting in June. If you were able to make this we could also try and have a session on getting you going on the developmental side of things. Cheers, Spencer. On 17 Mar 2016, at 14:58, Serson, Douglas <d.serson14(a)imperial.ac.uk<mailto:d.serson14@imperial.ac.uk>> wrote: Hi Asim, I am glad that your simulation is now working. About your questions: 1. We have some work done on a filter for calculating Reynolds stresses as the simulation progresses, but it is not ready yet, and it would not provide all the statistics you want. Since you already have a lot of chk files, I suppose the best way would indeed be using a script to process all of them with FieldConvert. 2. Yes, this has been recently included in FieldConvert, using the new 'meanmode' module. 3. I just checked that, and apparently this is caused by a bug when using this module without fftw. This should be fixed soon, but as an alternative this module should work if you switch fftw on (just add <I PROPERTY="USEFFT" VALUE="FFTW"/> to you session file, if the code was compiled with support to fftw). 4. I think there is some work towards a developer guide, but I don't how advanced is the progress on that. I am sure Spencer will be able to provide you with more information on that. Cheers, Douglas ________________________________________ From: Asim Onder <ceeao(a)nus.edu.sg<mailto:ceeao@nus.edu.sg>> Sent: 17 March 2016 09:10 To: Serson, Douglas; Sherwin, Spencer J Cc: nektar-users; Moxey, David Subject: Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach Hi Spencer, Douglas, Thanks to your suggestions I managed to get the turbulent regime for the oscillatory channel flow. I have now completed the DNS study for one case, and built up a large database with checkpoint (*chk) files. I would like to calculate turbulent statistics using this database, especially for second order terms, e.g. Reynolds stresses and turbulent dissipation, and third order terms, e.g. turbulent diffusion terms. However, I am a little bit confused how I could achieve this. I would appreciate if you could give some hints about the following: 1. The only way I could think of to calculate turbulent statistics is to write a simple bash script to iterate over chk files, and apply various existing/extended FieldConvert operations on individual chk files. This would require some additional storage to store the intermediate steps, and therefore would be a bit cumbersome. Would it be any simpler way directly doing this directly in Nektar++? 2. I have one homogeneous direction, for which I used Fourier expansions. I would like to apply spatial averaging over this homogeneous direction. Does Nektar++ already contain such functionality? 3. I want to use 'wss' in Fieldconvert module to calculate wall shear stress. However, it returns segmentation fault. Any ideas why it could be? 4. I was wondering if there is any introductory document for basic programming in Nektar++. User guide does not contain information about programming. It would be nice to have some additional information to Doxygen documentation. Thank you very much in advance for your feedback. Cheers, Asim On 02/15/2016 11:59 PM, Serson, Douglas wrote: Hi Asim, As Spencer mentioned, svv can help in stabilizing your solution. You can find information on how to set it up in the user guide (pages 92-93), but basically all you need to do is use: <I PROPERTY="SpectralVanishingViscosity" VALUE="True"/> You can also tune it by setting the parameters SVVCutoffRatio and SVVDiffCoeff, but I would suggest starting with the default parameters. Also, you can use the parameter IO_CFLSteps to output the CFL number. This way you can check if the time step you are using is appropriate. Cheers, Douglas From: Sherwin, Spencer J Sent: 14 February 2016 19:46 To: ceeao Cc: nektar-users; Serson, Douglas; Moxey, David Subject: Re: [Nektar-users] Parallel transposition not implemented yet for 3D-Homo-2D approach Hi Asim, Getting a flow through transition is very challenging since there is a strong localisation of shear and this can lead to aliasing issues which can then cause instabilities. Both Douglas and Dave have experienced this with recent simulations so I am cc’ing them to make some suggestions. I would be inclined to be using spectralhpdealiasing and svv. Hopefully Douglas can send you an example of how to switch this on. Cheers, Spencer. On 11 Feb 2016, at 10:32, ceeao<<mailto:ceeao@nus.edu.sg>ceeao(a)nus.edu.sg<mailto:ceeao@nus.edu.sg>> wrote: Hi Spencer, Nektar-Users, I followed the suggestion and coarsened the grid a bit. This way it worked impressively fast, but the flow is stable and remains laminar, as I didn't add any perturbations. I need to kick the transition to have turbulence. If I add white noise, even very low magnitude, conjugate gradient solver blows up again. I also tried adding some sinusoidal perturbations to boundary conditions, and again had troubles with CG. I don't really get CG's extreme sensitivity to perturbations. Any suggestion is much appreciated. Thanks in advance. Cheers, Asim On 02/08/2016 04:48 PM, Sherwin, Spencer J wrote: HI Asim, How many parallel cores are you running on. Sometime starting up these flows can be tricky especially if you are immediately jumping to a high Reynolds number. Have you tried first starting the flow at a Lower Reynolds number? Also 100 x 200 is quite a few elements in the x-y plane. Remember the polynomial order adds in more points on top of the mesh discretisation. I would perhaps recommend trying a smaller mesh to see how that goes first. Actually I note there is a file called TurbChFl_3D1H.xml in the ~/Nektar/Solvers/IncNavierStokesSolver/Examples directory which might be worth looking at. I think this was a mesh used in Ale Bolis’ thesis which you can find under: http://wwwf.imperial.ac.uk/ssherw/spectralhp/papers/PhDThesis/Bolis_Thesis.… Cheers, Spencer. On 1 Feb 2016, at 07:01, ceeao<mailto:ceeao@nus.edu.sg><ceeao(a)nus.edu.sg><mailto:ceeao@nus.edu.sg> wrote: Hi Spencer, Thank you for the quick reply and suggestion. I switched indeed to 3D homo 1D case and this time I have problems with the divergence of linear solvers. I refined the grid in the channel flow example to 100x200x64 in x-y-z directions, and left everything else the same. When I employ the default global system solver "IterativeStaticCond" with this setup, I get divergence: "Exceeded maximum number of iterations (5000)". I checked the initial fields and mesh in Paraview, everything seems to be normal. I also tried the "LowEnergyBlock" preconditioner, and apparently this one is valid only in sheer 3D cases. My knowledge in iterative solvers for hp-Fem is minimal. Therefore, I was wondering if you could suggest maybe a robust option that at least converge. My concern is getting some rough estimates for the speed of Nektar++ in my oscillating channel flow problem. If the speed will be promising, I will switch to Nektar++ from OpenFOAM, as OpenFOAM is low-order and not really suitable for DNS. Thanks again in advance. Cheers, Asim On 01/31/2016 11:53 PM, Sherwin, Spencer J wrote: Hi Asim, I think your conclusions is correct. We did some early implementation into the 2D Homogeneous expansion but have not pulled it all the way through since we did not have a full project on this topic. We have however kept the existing code running through our regression test. For now I would perhaps suggest you try the 3D homo 1D approach for your runs since you can use parallelisation in that code. Cheers, Spencer. On 29 Jan 2016, at 04:00, ceeao<mailto:ceeao@nus.edu.sg><ceeao(a)nus.edu.sg><mailto:ceeao@nus.edu.sg> wrote: Dear all, I just installed the library, and need to simulate DNS of a channel flow with oscillating pressure gradient. As I have two homogeneous directions I applied standard Fourier discretization in these directions. It seems like this case is not parallelized yet, and I got the error in the subject. I was wondering if I'm overlooking something. If not, are there maybe any plans in the future to include parallelization of 2D FFT's? Thank you in advance. Best, Asim Onder Research Fellow National University of Singapore ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. _______________________________________________ Nektar-users mailing list Nektar-users(a)imperial.ac.uk<mailto:Nektar-users@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052 Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052 Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052 ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ <mailto:s.sherwin@imperial.ac.uk>s.sherwin(a)imperial.ac.uk<mailto:s.sherwin@imperial.ac.uk> +44 (0) 20 759 45052 ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you. ________________________________ Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

3 18

Linking ARPAC
by Lander, Marcus David 27 May '16

27 May '16

I am having issues getting Nektar++ to recognize ARPACK. When I run through the channel-flow tutorial, in the Channel-Coupled.xml section, I get to the following command: IncNavierStokesSolver Channel-Coupled.xml Then, I receive the following error: Value 'Arpack' is not valid for property 'DRIVER' I'm very confused how to link Arpack (which is going to be installed to my personal directory rather than on the main section of the cluster, because I do not have permission to install Arpack globally). It is installed at $HOME/ARPACK/ In ccmake .., I point the ARPACK_LIBRARY flag to $HOME/ARPACK/libarpack_LINUX.a, and then I changed the NEKTAR_USE_ARPACK flag to on. Is there something I am missing???

2 1

Parallel Problem with FieldConvert
by Jian Yu 27 May '16

27 May '16

Dear all, I encountered a problem when I run the FieldConvert with two or more cpu cores for the C0Projection module. For example, when I run the following command, it is OK: mpirun -np 1 ./FieldConvert -m C0Projection 2D_20x20.xml 2D_20x20_0.chk 2D_20x20_0_C0.fld However, the following command will report an error: mpirun -np 2 ./FieldConvert -m C0Projection 2D_20x20.xml 2D_20x20_0.chk 2D_20x20_0_C0.fld and the error message is: gs_setup: 60 unique labels shared pairwise times (avg, min, max): 0.000110245 0.00010879 0.000111699 crystal router : 9.22918e-05 9.22918e-05 9.22918e-05 all reduce : 0.000179148 0.0001791 0.000179195 used all_to_all method: crystal router handle bytes (avg, min, max): 4724 4724 4724 buffer bytes (avg, min, max): 1920 1920 1920 CG iterations made = 5001 using tolerance of 1e-09 (error = nan, rhs_mag = inf) Fatal : Level 0 assertion violation Exceeded maximum number of iterations terminate called after throwing an instance of 'ErrorUtil::NekError' what(): Level 0 assertion violation Exceeded maximum number of iterations Can anyone help me about this? Best Jian

2 2