February 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

Adaptive Selective frequency damping method for flow past cylinder at Re 100.
by wasim sarwar 17 Mar '19

17 Mar '19

Dear all, I have been trying to use Selective frequency damping (SFD) method adopted in the SteadyState Driver, in order to get an unstable steady state solution whose stability is to be determined. I see in the nektar++ user guide there are two approaches: classical one, and the adaptedSFD. I am trying to validate the case of flow past circular cylinder at Re=100 studied by Jordi link herein https://spiral.imperial.ac.uk/bitstream/10044/1/31875/.../Jordi-B-2016-PhD-… <https://spiral.imperial.ac.uk/bitstream/10044/1/31875/3/Jordi-B-2016-PhD-Th…> . With the values of growth rate and frequency mentioned in this thesis, i am able to achieve convergence upto O(-8) for the classical approach. The problem arises when I use AdaptedSFD method. Initially, AdaptedSFD runs smoothly untill tolerance O(-2), then it switches to stability analysis to estimate growth rate and frequency which is used to predict next value of control coefficient and filter width. The problem lies in the estimation of growth rate and frequency which give nonphysical large values of order 10. I have attached the Session.xml, Session_LinNS.xml, and output results generated. Any help is highly appreciated. Cheers Wasim

2 1

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

Pressure inflow BC
by Amitvikram Dutta 17 Mar '19

17 Mar '19

Hi all, Is it possible to have a pressure boundary condition that guarantees inflow? I'd like to explain in more detail. I have a jet simulation where I'm attempting to simulate entrainment of the jet air from behind the jet. Unfortunately, at the boundaries at the to and bottom of the domain, where the flow should be coming into the domain, the flow instead goes out of the domain. I have set the BCs at this domain to be the same as for outlets, i.e., Zero velocity gradients and zero pressure. It was my hope that the velocities would settle to their correct value over the course of the simulation. However instead I ran into the problem just described. I'd appreciate some insight if possible. Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 1

Error in running the tutorial
by zxiong＠sas.upenn.edu 12 Mar '19

12 Mar '19

Dear all, When I try to compile the tutorial code of tutorial http://doc.nektar.info/tutorials/latest/fundamentals/differentiation/fundam… , I follow the instruction of task 1.1: I first use cmake command to generate makefile and then type 'make' but the terminal give me error messages like this:(I can successfully run tutorial code in http://doc.nektar.info/tutorials/latest/fundamentals/integration/fundamenta…, but I can't compile the code of this one). What should I do? *Scanning dependencies of target StdDifferentiation2D* [ 16%] Building CXX object CMakeFiles/StdDifferentiation2D.dir/StdDifferentiation2D.cpp.o */Users/zhenxiong/Desktop/independent_study/turotials/fundamentals-differentiation/tutorial/StdDifferentiation2D.cpp:57:21: **error: * * no viable overloaded '='* derivMatrixDir1 = LibUtilities::PointsManager()[quadPointsKeyDir1]->GetD(); * ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3786:17: note: * candidate function not viable: no known conversion from 'const Nektar::LibUtilities::Points<double>::MatrixSharedPtrType' (aka 'const shared_ptr<NekMatrix<double> >') to 'const std::__1::shared_ptr<Nektar::NekMatrix<double, Nektar::StandardMatrixTag> >' for 1st argument shared_ptr& operator=(const shared_ptr& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3797:17: note: * candidate function not viable: no known conversion from 'const Nektar::LibUtilities::Points<double>::MatrixSharedPtrType' (aka 'const shared_ptr<NekMatrix<double> >') to 'std::__1::shared_ptr<Nektar::NekMatrix<double, Nektar::StandardMatrixTag> >' for 1st argument shared_ptr& operator=(shared_ptr&& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3794:9: note: * candidate template ignored: could not match 'std::__1::shared_ptr' against 'boost::shared_ptr' operator=(const shared_ptr<_Yp>& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3805:9: note: * candidate template ignored: could not match 'std::__1::shared_ptr' against 'boost::shared_ptr' operator=(shared_ptr<_Yp>&& __r); * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3815:9: note: * candidate template ignored: could not match 'auto_ptr' against 'shared_ptr' operator=(auto_ptr<_Yp>&& __r); * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3839:9: note: * candidate template ignored: could not match 'unique_ptr' against 'shared_ptr' operator=(unique_ptr<_Yp, _Dp>&& __r); * ^* */Users/zhenxiong/Desktop/independent_study/turotials/fundamentals-differentiation/tutorial/StdDifferentiation2D.cpp:60:21: **error: * * no viable overloaded '='* derivMatrixDir2 = LibUtilities::PointsManager()[quadPointsKeyDir2]->GetD(); * ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3786:17: note: * candidate function not viable: no known conversion from 'const Nektar::LibUtilities::Points<double>::MatrixSharedPtrType' (aka 'const shared_ptr<NekMatrix<double> >') to 'const std::__1::shared_ptr<Nektar::NekMatrix<double, Nektar::StandardMatrixTag> >' for 1st argument shared_ptr& operator=(const shared_ptr& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3797:17: note: * candidate function not viable: no known conversion from 'const Nektar::LibUtilities::Points<double>::MatrixSharedPtrType' (aka 'const shared_ptr<NekMatrix<double> >') to 'std::__1::shared_ptr<Nektar::NekMatrix<double, Nektar::StandardMatrixTag> >' for 1st argument shared_ptr& operator=(shared_ptr&& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3794:9: note: * candidate template ignored: could not match 'std::__1::shared_ptr' against 'boost::shared_ptr' operator=(const shared_ptr<_Yp>& __r) _NOEXCEPT; * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3805:9: note: * candidate template ignored: could not match 'std::__1::shared_ptr' against 'boost::shared_ptr' operator=(shared_ptr<_Yp>&& __r); * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3815:9: note: * candidate template ignored: could not match 'auto_ptr' against 'shared_ptr' operator=(auto_ptr<_Yp>&& __r); * ^* */Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3839:9: note: * candidate template ignored: could not match 'unique_ptr' against 'shared_ptr' operator=(unique_ptr<_Yp, _Dp>&& __r); * ^* 2 errors generated. make[2]: *** [CMakeFiles/StdDifferentiation2D.dir/StdDifferentiation2D.cpp.o] Error 1 make[1]: *** [CMakeFiles/StdDifferentiation2D.dir/all] Error 2 make: *** [all] Error 2 Best, Zhen

2 1

Appropriate Polynomial Order
by Amitvikram Dutta 04 Mar '19

04 Mar '19

Hi all, I have 2 separate questions. On Pasquetti's paper where he carries out the investigation of the effect of SVV parameters on the flow past a cylinder, the polynomial orders used are very high i.e. N ~ 60 with roughly 10.8 million DOF. In contrast, in the AIAA paper "Implicit Large-Eddy Simulation of a Wingtip Vortex" , by Lombard et. al. the mesh uses tetrahedra and prismatic elements, adopts N = 6 and obtains roughly 16 million DOF. My question is therefore, if I'm using a simple structured mesh at a very low Re of 4000 is the choice of N=6 wihich corresponds roughly to 32 Million DOF in the 3D case appropriate? Or should I change to a much higher order as Pasquetti did in his study, while coarsening my "mesh" to achieve the same DOF as I currently have. Sincerely, -- *Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo

2 2

Re: [Nektar-users] FW: Error in apply Dong outflow BCs
by Amitvikram Dutta 03 Mar '19

03 Mar '19

Hi Spencer, This is a very simple 2 dimesnional mesh with no curved elements. So I do not think this is a meshing issue. In fact changing the outflow Robin BCs to a more conventional Nuemann form for velocity immediately allows the solution to run smoothly. Sincerely, On Wed, Feb 27, 2019 at 3:26 AM Amitvikram Dutta < amitvikram.dutta(a)uwaterloo.ca> wrote: > > ------------------------------ > *From:* nektar-users-bounces(a)imperial.ac.ukOn Behalf OfSherwin, Spencer J > *Sent:* February 27, 2019 3:25:43 AM (UTC-05:00) Eastern Time (US & > Canada) > *To:* Amitvikram Dutta > *Cc:* nektar-users > *Subject:* Re: [Nektar-users] Error in apply Dong outflow BCs > > Hi Amitvikram, > > What sort of mesh were you running? Perhaps this is a 3D element we have > not fully tested ? > > Cheers, > Spencer > > Sent from my iPhone > > On 27 Feb 2019, at 07:09, Amitvikram Dutta <amitvdutta23(a)gmail.com> wrote: > > Hi all, > > I'm testing out the Robin type BCs for the outflow as given in the user > guide. > Which takes the form of the following > > > <R VAR="u" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep"/> > <R VAR="v" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep"/> > <R VAR="p" USERDEFINEDTYPE="HOutflow" VALUE="0" > PRIMCOEFF="1.0/(D0*Kinvis)"/> > > Upon startup, this gives the error > > Fatal : Level 0 assertion violation > Could not identify matrix type from dimension > > I havent come across this error before. Could someone point out what the > error is? > 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

SVV for passive scalar transport
by Vishal Saini 03 Mar '19

03 Mar '19

Hi all, I'd like to study scalar mixing in the jets-in-cross-flow case using IncNavierStokesSolver (an SVV-LES simulation). According to the user guide, I can simply add a transport equation for a scalar in the condition file. However, I'm not sure what would be the easiest way to apply the SVV filter on the scalar field. Have someone tried this before? Any help is much appreciated. BR, Vishal --- *Vishal SAINI* Master of Research, University of Cambridge. Master in Turbulence EC Lille, ENSIP and ENSMAFrance. Contact: vs434(a)cam.ac.uk, vishal.saini.nitj(a)gmail.com <vishal.saini.nitj(a)gmail.com> (+44) 7 459 186 139 (UK) (+33) 7 58 24 84 02 (France)

2 1

Error in apply Dong outflow BCs
by Amitvikram Dutta 27 Feb '19

27 Feb '19

Hi all, I'm testing out the Robin type BCs for the outflow as given in the user guide. Which takes the form of the following <R VAR="u" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep"/> <R VAR="v" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="D0/TimeStep"/> <R VAR="p" USERDEFINEDTYPE="HOutflow" VALUE="0" PRIMCOEFF="1.0/(D0*Kinvis)"/> Upon startup, this gives the error Fatal : Level 0 assertion violation Could not identify matrix type from dimension I havent come across this error before. Could someone point out what the error is? 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