January 2019 - Nektar-users

Element with max CFL
by Vishal Saini 02 Apr '20

02 Apr '20

Hi all, Quick question: Has anyone tried to check the location of a particular element in the mesh? A log file reports the maximum (?) CFL and the corresponding element as: "CFL: 0.0337915 (in elmt 94488)"? Is there a quick way to locate "elmt 94488"? Cheers, Vishal

2 2

Inlet boundary conditions from a file
by Amitvikram Dutta 17 Mar '19

17 Mar '19

Hi all, Would it be possible to specify the inlet velocity boundary conditions of a 2D problem using a .pts file? I have a profile from my experiments that I wish to use as an inlet BC to my simulation. The user guide has an example where a file is used in combination with TIMEDEPENDENT BCs. My condition is not time varying and is essentially a 1D profile at the inflow of the domain. What would be the format of the file that I would specify? Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 1

Re: [Nektar-users] FW: Problem while installing nektar++ with lapack
by Amitvikram Dutta 22 Feb '19

22 Feb '19

Hi all, I had to use a slight workaround because the platform I was compiling on could not download the thirdparty files correctly and would always give a hash mismatched error. I downloaded the third party files on my home machine and re-uploaded them into the $NEKTAR_HOME folder. As a result when I begin the build process the ThirdParty folder is populated with the zipped versions of the third party software. Is this what what might be causing the problem? Is there any way to edit the cmake file and to get the compilation process working correctly? On Fri, Oct 12, 2018 at 2:57 PM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfJeremy Cohen > *Sent:* October 12, 2018 2:56:43 PM (UTC-05:00) Eastern Time (US & Canada) > > *To:* Amitvikram Dutta > *Cc:* nektar-users > *Subject:* Re: [Nektar-users] Problem while installing nektar++ with > lapack > > Hi Amitvikram, > > Have you attempted to build lapack separately at any point? It's probably > worth clearing out your build directory and also all the contents of the > ThirdParty directory in the base nektar++ source directory, which I'll call > $NEKTAR_HOME, so $NEKTAR_HOME/ThirdParty and then re-running cmake in an > empty $NEKTAR_HOME/build directory and trying the build again. > > It looks like the build step is encountering a previous source tree in the > location where it's trying to build which seems strange. > > I've just had a look at the log from my clean build and I see exactly the > same messages as you in relation to lapack-3.7.0 in the same order as far > as "Checking whether /usr/bin/f95 supports Fortran 90 -- yes", however, I > then see "-- Looking for Python greater than 2.6 - " and the build of > lapack completes successfully. > > Just to confirm, I am running cmake and make in a separate build directory > under the main nektar++ source tree directory, so I'm building in > $NEKTAR_HOME/build - I assume you're doing something similar? You should > see a ThirdParty directory in $NEKTAR_HOME and another ThirdParty directory > in $NEKTAR_HOME/build/ > > I believe that the initial download of the lapack-3.7.0.tar.gz should be > placed in $NEKTAR_HOME/ThirdParty and unpacked there. Then, when the build > succeeds or stops, in $NEKTAR_HOME/build/ThirdParty, you should see > lapack-3.7.0/ where I think the build actually takes place, and then a > separate $NEKTAR_HOME/build/ThirdParty/lapack-3.7.0-tmp which should > contain a couple of lapack-3.7.0-cfgcmd.txt files that I think contain the > build command that is used - you could perhaps paste the contents of the > lapack-3.7.0-cfgcmd.txt into an email if you're still having issues and we > can see if that looks correct. > > It is, of course, possible that this is something related to the specific > configuration of the platform that you're building on, but I think the > third party lapack build should be straightforward and it sounds like for > some reason, it's attempting to build in the wrong location, or a location > where an existing source tree has ended up for some reason. > > I'm afraid I don't have a very detailed knowledge of the build system > beyond this so if none of the suggestions so far help you to resolve the > problem, maybe someone with more knowledge of the build system can provide > some advice. > > Cheers, > Jeremy > > On 12 Oct 2018, at 19:34, Amitvikram Dutta <amitvdutta23(a)gmail.com> wrote: > > Hi all, > > I tried to compile nektar using Jeremy's latest suggestions having both > THIRDPARTY_BUILD_BLAS_LAPACK and NEKTAR_USE_SYSTEM_BLAS_LAPACK turned on. > The following error occured. It seems that I might have to compile lapack > separately. Is this unusual? > > <image.png> > > On Fri, Oct 12, 2018 at 1:16 PM Amitvikram Dutta < > amitvikram.dutta(a)uwaterloo.ca> wrote: > >> *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfJeremy Cohen >> *Sent:* October 12, 2018 1:16:14 PM (UTC-05:00) Eastern Time (US & >> Canada) >> >> *To:* Amitvikram Dutta >> *Cc:* nektar-users >> *Subject:* Re: [Nektar-users] Problem while installing nektar++ with >> lapack >> >> Hi Amitvikram, >> >> As Chris suggests, it's probably better to use vendor supplied libraries >> if you can get those working. >> >> In addition to the further information Chris has asked to take a look at, >> one thing you could check is to whether there are any files in your >> nektar++/build/ThirdParty/lapack-3.7.0 directory (if that directory exists >> at all). >> >> I've been trying to see if I can recreate the problem and I was able to >> see something similar when setting THIRDPARTY_BUILD_BLAS_LAPACK=ON and >> NEKTAR_USE_SYSTEM_BLAS_LAPACK=OFF. In this case, I can configure >> successfully and start the build but it fails with a large number of >> undefined references that are similar to, and include, the dtpmv_ symbol >> that you mentioned. When I look in nektar++/build/ThirdParty/lapack-3.7.0, >> the directory is empty so it looks like the build system has configured on >> the basis of building its own blas/lapack but the build hasn't been carried >> out and therefore LibUtilities can't be linked against it. >> >> As a test, you could try running the build with both >> THIRDPARTY_BUILD_BLAS_LAPACK=ON and NEKTAR_USE_SYSTEM_BLAS_LAPACK=ON, if >> this isn't the setting you've been using already. When I tried this, the >> build of blas/lapack is carried out successfully and the linking is fine >> with the full build of Nektar++ completing successfully. I removed the >> system blas/lapack on my test system to be sure it was linking against the >> correct instance. >> >> Cheers, >> Jeremy >> >> On 12 Oct 2018, at 17:50, Chris Cantwell <c.cantwell(a)imperial.ac.uk> >> wrote: >> >> Hi Amitvikram, >> >> Could you send us your CMakeCache.txt file from your build directory and >> the output from running: >> make VERBOSE=1 >> for both cases. >> >> In the case of using ThirdParty LAPACK, it seems to not be linking to it. >> Probably you should be using vendor-supplied libraries if possible though >> so better if ee can get those working. >> >> Thanks, >> Chris >> >> >> >> On 12 October 2018 14:08:55 BST, Amitvikram Dutta <amitvdutta23(a)gmail.com> >> wrote: >>> >>> Hi Jeremy, >>> >>> I'm actually trying to build nektar++ on a BGQ cluster similar to Mira. >>> >>> I'm trying to build nektar++-4.4.1 and the system lapacek version is >>> 3.4.2 >>> >>> Sincerely, >>> On Fri, Oct 12, 2018 at 4:24 AM Amitvikram Dutta < >>> amitvikram.dutta(a)uwaterloo.ca> wrote: >>> >>>> >>>> ------------------------------ >>>> *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfJeremy Cohen >>>> *Sent:* October 12, 2018 4:24:33 AM (UTC-05:00) Eastern Time (US & >>>> Canada) >>>> *To:* Amitvikram Dutta >>>> *Cc:* nektar-users >>>> *Subject:* Re: [Nektar-users] Problem while installing nektar++ with >>>> lapack >>>> >>>> Hi Amitvikram, >>>> >>>> Can you provide some further details of the problem you're encountering. >>>> >>>> Specifically, can you confirm what platform (including version) you're >>>> building on, and if Linux, which I assume is the platform you're using, >>>> which distribution. >>>> >>>> Can you also confirm what version of Nektar++ you're trying to build, >>>> and the version of the system Lapack distribution that you're using. >>>> >>>> Thanks, >>>> >>>> Jeremy >>>> >>>> On 12 Oct 2018, at 01:05, Amitvikram Dutta <amitvdutta23(a)gmail.com> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I keep having the same problem while trying to install nektar++ with >>>> regards to the Lapack libraries. >>>> >>>> When I try to use the system Lapack installation I get the following >>>> message >>>> >>>> */scinet/bgq/Libraries/lapack/lib/liblapack.so: undefined reference to >>>> `_xlfEndIO(a)XLF_1.0'* >>>> >>>> while when I try to install using the ThirdParty Lapack supplied with >>>> the nektar++ source directory I get the following error >>>> >>>> *../../library/LibUtilities/libLibUtilities.so.4.4.1: undefined >>>> reference to `dtpmv_'* >>>> >>>> I have a feeling these errors have been encountered by the community at >>>> large before. Could someone point out where I'm going wrong? >>>> >>>> Sincerely, >>>> -- >>>> >>>> *Amitvikram Dutta* >>>> >>>> Graduate Research Assistant >>>> >>>> Fluid Mechanics Research Lab >>>> >>>> Multi-Physics Interaction Lab >>>> >>>> University of Waterloo >>>> _______________________________________________ >>>> Nektar-users mailing list >>>> Nektar-users(a)imperial.ac.uk >>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>>> >>>> >>>> -- >>> >>> *Amitvikram Dutta* >>> >>> Graduate Research Assistant >>> >>> Fluid Mechanics Research Lab >>> >>> Multi-Physics Interaction Lab >>> >>> University of Waterloo >>> >> >> -- >> Chris Cantwell >> Imperial College London >> South Kensington Campus >> London SW7 2AZ >> Email: c.cantwell(a)imperial.ac.uk >> www.imperial.ac.uk/people/c.cantwell >> >> >> -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > > > -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

4 9

How can I open or see Nektar documents?
by Dongmyung Suh 01 Feb '19

01 Feb '19

Hello, Nektar community, I installed Nektar from source code. After installation, I found developer-guide, doxygen, and user-guide in docs folder. But I don't know how to open and see them. Please let me know how to read them. Thank you Dongmyung Suh

4 5

Nektar hangs on NFS
by Fatih Ertinaz 01 Feb '19

01 Feb '19

Hello I deploy a small cluster on the cloud (not on IB). I setup the VMs, keys etc. and I use NFS for shared storage. This is a small cluster intended for 1-2 users, so presumably NFS should be fine. At least that's what I thought. Currently I am testing the tutorial case "basics-advection-diffusion". It runs when executed in serial or parallel using 1 node (4 cores). However, when I use 2 nodes it hangs during: > Initial Conditions: > - Field u: sin(k*x)*cos(k*y) > Writing: "ADR_mesh_aligned_0.chk" (0.0199919s, XML) I see that "ADR_mesh_aligned_0" and its content written successfully, however next directory cannot be created and solver remains idle. > mpirun -np 8 -mca btl_tcp_if_include eth0 -hostfile hosts \ > $NEKTAR_BIN/ADRSolver ADR_mesh_aligned.xml ADR_conditions.xml I tested a simple hostname command and an mpi parallel file write, both worked fine on two nodes with mpirun. Any suggestions highly appreciated. Thank you // Fatih

2 4

'std::bad_alloc' error in several tests
by Kurt Sansom 01 Feb '19

01 Feb '19

Hi am trying to compile the master branch, but when I go to test it everything works except for about some tests. it appears that they are all related to the code throwing 'std::bad_alloc'. Can anyone point me to something that might help me resolve this? Ubuntu 16.04, openmpi, most modules in cmake are on except python, CCM, CFI, Metis, petsc are off. using external OCE, and vtk. I tried a clean rebuild, and several other variants without there being any change. I tried to debug one of the tests using gdb without much clarity. 1 - NekMesh_Nektar++/InvalidTetFace (Failed) 2 - NekMesh_Nektar++/InvalidQuads (Failed) 3 - NekMesh_Nektar++/Tube45Refinement (Failed) 4 - NekMesh_Nektar++/Tube45Refinement_extractsurf (Failed) 5 - NekMesh_Nektar++/CylQuadBl (Failed) 35 - NekMesh_MeshGen/cylinder (Failed) 36 - NekMesh_MeshGen/sphere (Failed) 37 - NekMesh_MeshGen/2d-cad (Failed) 38 - NekMesh_MeshGen/2d-naca (Failed) 39 - NekMesh_MeshGen/geo (Failed) 40 - NekMesh_MeshGen/t106c (Failed) 41 - NekMesh_MeshGen/t106step (Failed) 43 - FieldConvert_chan3D_interppointsplane (Failed) 44 - FieldConvert_chan3D_interppointsbox (Failed) 46 - FieldConvert_bfs_probe (Failed) 52 - FieldConvert_chan3D_csv (Failed) 53 - FieldConvert_chan3D_pts (Failed) 58 - FieldConvert_chan3D_probe (Failed) 63 - FieldConvert_interpfield (Failed) 72 - FieldConvert_chan3D_interppointsplane_par (Failed) 73 - FieldConvert_chan3D_interppointsbox_par (Failed) 329 - IncNavierStokesSolver_Cyl_AdaptiveSFD (Failed) 558 - tutorial_basics-advection-diffusion-msh-align (Failed) 568 - tutorial_fundamentals-integration-std1D-python (Failed) 569 - tutorial_fundamentals-integration-std2D-python (Failed) 570 - tutorial_fundamentals-integration-loc2D-python (Failed) 571 - tutorial_fundamentals-differentiation-std1D-python (Failed) 572 - tutorial_fundamentals-differentiation-std2D-python (Failed) 573 - tutorial_fundamentals-differentiation-loc2D-python (Failed) 583 - tutorial_mesh-generation-2d-step (Failed) Regards, ~Kurt -- Kurt Sansom

2 1

Segmentation fault in the advectiondiffusion.xml
by Dongmyung Suh 01 Feb '19

01 Feb '19

Dear Nektar community, After I installed Nektar4.4.1 in my Ubuntu (18.04) by source code, I successfully run the two examples (1D Advection equ and 2D Helmholtz problem) in User guide, Chapter 6. But when I tried the third example (AdvectionDiffusion.xml, in 6.4.3 Advection dominated mass transport in a pipe), I bumped into a segmentation error. I am a newbie in Nektar, So I could not find which one is a problem in the input xml file. Could you give me an idea to solve the problem? I really want to learn Nektar. Thank you. Dongmyung Suh ---------------------------------------------------------------------------------------------------------------- T5500:~/Desktop/Nektar_exercise/AdvectionDiffusion$ ADRSolver AdvectionDiffusion.xml Warning: Level 0 assertion violation Using Default variable expansion definition for field: u [T5500:03146] *** Process received signal *** [T5500:03146] *Signal: Segmentation fault (11)* [T5500:03146] Signal code: Address not mapped (1) [T5500:03146] Failing at address: 0x8 [T5500:03146] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7fbe5b148f20] [T5500:03146] [ 1] /home/dongmyung/Software/nektar++-4.4.1/build/dist/lib64/nektar++-4.4.1/libSolverUtils.so.4.4.1(_ZN6Nektar11SolverUtils14UnsteadySystem17v_GenerateSummaryERSt6vectorISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_ESaISA_EE+0x28f)[0x7fbe5e33f9af] [T5500:03146] [ 2] /home/dongmyung/Software/nektar++-4.4.1/build/dist/lib64/nektar++-4.4.1/libSolverUtils.so.4.4.1(_ZN6Nektar11SolverUtils14DriverStandard9v_ExecuteERSo+0x4a4)[0x7fbe5e2e3b14] [T5500:03146] [ 3] ADRSolver(main+0x177)[0x55d5de973037] [T5500:03146] [ 4] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fbe5b12bb97] [T5500:03146] [ 5] ADRSolver(_start+0x2a)[0x55d5de98329a] [T5500:03146] *** End of error message *** Segmentation fault (core dumped) ---------------------------------------------------------------------------------------------------------------------

2 1

L2 error
by Amitvikram Dutta 01 Feb '19

01 Feb '19

Hi all, I'd like to clear up a point that has been bugging me for some time. Are the L2 and Linf norms in nektar++ always defined with respect to a given analytical solution for a problem? What do these terms represent in a case for which a solution is not specified? Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

3 2

please help for Field interpolation
by Moto Light 31 Jan '19

31 Jan '19

Hi All, i have a 3D case and i am trying to make a new domain with bigger downstream length, i already tried Fieldconvert to interpolate my old field to use it for the new 3D case and i done it in this next command line ============================ FieldConvert -m interpfield:fromxml=mesh_old.xml:fromfld=2Dmean.fld mesh_new.xml newfield.fld ============================ and i have error ==================== Segmentation fault (core dumped) ==================== I tried also to use mean field as a 2D file and made field interpolation and i have the same error any suggestions? Thanks,

1 0

Re: [Nektar-users] FW: Restarting a 3D1D case with a 2D converged case
by Amitvikram Dutta 30 Jan '19

30 Jan '19

Hi Andrea, Thanks for your suggestions. I was not aware that we could use the modal energy filter as a diagnostic tool. I will try it. I also was not aware that the SVV cutoff frequencies in different directions could be set separately. I have just been applying a single global frequency so far. Could you describe how this is done in the parameters section? Sincerely, On Wed, Jan 30, 2019 at 3:40 AM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfCassinelli, Andrea > *Sent:* January 29, 2019 1:29:32 PM (UTC-05:00) Eastern Time (US & Canada) > *To:* nektar-users > > *Subject:* Re: [Nektar-users] Restarting a 3D1D case with a 2D converged > case > > Hi Amitvikram, > > What you described seems to be the correct procedure (initialise the 3DH1D > field with well-established 2D field). What kind of initial conditions are > you using for the spanwise direction? I would suggest using low-magnitude > noise to kick the Fourier modes (i.e. <E VAR="w" VALUE="0.0001*awgn(1.0)" > />). > > I would also suggest to turn on the modal filter to see if the simulation > blows up because energy accumulates in the high frequency modes. Are you > using SVV for the homogeneous direction or just in the spectral/hp plane? > You can try to lower the cutoff frequency for the spanwise direction and > see if you still observe this behaviour. > > Hope this helps. > > Kind regards, > > Andrea > > > > On 29 Jan 2019, at 18:10, Amitvikram Dutta <amitvdutta23(a)gmail.com> wrote: > > Hi all, > > I'm studying 3D devlopement of jets and am using a 3D1D setup with Fourier > coefficients in the spanwise directions. Instead of starting a 3D1D case > from scratch (the mesh contains 32 million DOF in 3D) I was thinking of > trying out a few strategies in order to speed up convergence. > > I have tried out the steady-state module but it seems to take a rather > long time to converge as well. > > I was thinking therefore, whether it would be possible to start the case > in 2D, and once it reaches convergence, to switch over to a 3D 1D mode > using a 2D .chk file as a restart point. > > I have tried out a few cases with the procedure described above, but cases > always seem to blow up after restarting in the 3D 1D mode. I could explore > the parameter space by reducing the time-step or number of expansion modes > etc, but I'd like to know if there is a fundamental block to this kind of > approach, or indeed if there are better approaches to speeding up > convergence. > > Sincerely, > -- > > *Amitvikram Dutta* > > Graduate Research Assistant > > Fluid Mechanics Research Lab > > Multi-Physics Interaction Lab > > University of Waterloo > _______________________________________________ > Nektar-users mailing list > Nektar-users(a)imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > > > -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 1