- Nektar-users - imperial.ac.uk

Restarting from a directory
by Kamil Ozden 10 Nov '14

10 Nov '14

Dear All, I want to use the .fld directory (includes 12 .fld files as P0000000.fld etc. and one Info.xml file) of an analysis (run with 12 processors) as initial condition to another analysis. I've changed the name of the file from /*Re_1000_v2.fld*/ to /*Re_1000_v2.rst*/ and generated an initlal condition part in my .xml file as follows: /*<FUNCTION NAME="InitialConditions">*//* *//* <F VAR="u" FILE="Re_1000_v2.rst/" />*//* *//* <F VAR="v" FILE="Re_1000_v2.rst/" />*//* *//* <F VAR="w" FILE="Re_1000_v2.rst/" />*//* *//* <F VAR="p" FILE="Re_1000_v2.rst/" />*//* *//* </FUNCTION>*/ but I'm getting segmentation fault as follows: /*mpirun noticed that process rank 1 with PID 98467 on node levrek1.yonetim exited on signal 11 (Segmentation fault)*/ Am I doing something wrong about restarting by using a .fld directory? What is the way of doing this? Regards, Kamil

2 3

Combining .fld and .chk files
by Kamil ÖZDEN 08 Nov '14

08 Nov '14

Dear All, When I run an analysis with multiprocessor I got .fld and .chk files in directories as much as number of processors like /*P0000000.fld,P0000001.fld*/... etc. How can I combine these files into a single .fld and .chk file? There are some utilites in /*~/build/utilities/PostProcessing */directory like /*CombinePartitions, FldAddFld etc.*/ but as far as I see there are no information in user guide about how to use these. Regards, Kamil

2 1

History Point problem
by Kamil ÖZDEN 08 Nov '14

08 Nov '14

Dear All, When I try to run an analysis by requesting a History File, Nektar++ 4.0 tells me that: /*History point 0,0,0 cannot be found in the mesh.*/ but in the .xml file 0, 0, 0 point exists as vertex as you see below: /* <V ID="9761">0.00000000e+00 0.00000000e+00 0.00000000e+00</V>*/ When I remove history points part from the .xml file, it runs without problem. What may be the reason for this problem? NOTE: The mesh is composed of both pyrisms and hexahedras. So .xml file includes two composites. Regards, Kamil.

2 2

Iterative Solvers for Incompressible Navier Stokes Equation
by Kamil ÖZDEN 05 Nov '14

05 Nov '14

Dear All, I'm solving a pipe flow problem with Incompressible Navier Stokes solver in a cluster with mpirun command. I saw that only IterativeFull solver reduces the run time of analysis when number of CPU is increased. Is this expected in Nektar? Regards, Kamil

2 1

Re: [Nektar-users] Gitlab downtime: Monday 20th October, 10am-5pm
by David Moxey 30 Oct '14

30 Oct '14

Hi Dirk, I am forwarding this to the mailing list since we've had a few people encounter this. As the note from ssh says, the key for the SSH server has changed. It will show an error since this is an obvious sign of DNS spoofing or other man-in-the-middle attacks. However I can assure you this is not the case here - we've simply changed server! To get rid of the error, you will need to edit the ~/.ssh/known_hosts file, and remove the offending entry. This will be different for different people: however it will tell you which line to remove: > Offending RSA key in /Users/Ekelschot/.ssh/known_hosts:1 Hopefully this is clear enough. Cheers, Dave > On 30 Oct 2014, at 10:24, Ekelschot, Dirk <d.ekelschot12(a)imperial.ac.uk> wrote: > > Hi Dave, > > I have tried to clone a fresh version of nektar using > > git remote set-url origin git@gitlab.nektar.info:nektar/nektar.gi > > But I get the following warning/error > > git clone git@gitlab.nektar.info:nektar/nektar.git > Cloning into 'nektar'... > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > The RSA host key for gitlab.nektar.info has changed, > and the key for the corresponding IP address 155.198.35.162 > is unknown. This could either mean that > DNS SPOOFING is happening or the IP address for the host > and its host key have changed at the same time. > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > 64:14:1b:f0:53:9b:88:4d:12:5f:a8:a2:dc:a0:65:fe. > Please contact your system administrator. > Add correct host key in /Users/Ekelschot/.ssh/known_hosts to get rid of this message. > Offending RSA key in /Users/Ekelschot/.ssh/known_hosts:1 > RSA host key for gitlab.nektar.info has changed and you have requested strict checking. > Host key verification failed. > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > > I added a new ssh key but I still get it. Do you know what I can do to prevent this? > > Cheers, > > Dirk > > On 22 Oct 2014, at 16:59, David Moxey <d.moxey(a)imperial.ac.uk> wrote: > >> Dear all, >> >> Imperial ICT have just informed me that the DNS records have been updated. Since DNS can take 24-48hrs to propagate, you may not be able to access gitlab using gitlab.nektar.info immediately. However, hopefully by Friday your local nameservers will have recognised the update. >> >> Once that's happened, just issue: >> >> git remote set-url origin git@gitlab.nektar.info:nektar/nektar.git >> >> to change your repository settings again. >> >> Thanks, >> >> Dave >> >>> On 20 Oct 2014, at 17:10, David Moxey <d.moxey(a)imperial.ac.uk> wrote: >>> >>> Dear all, >>> >>> The new version of gitlab is now up and running. Unfortunately, Imperial ICT have been unresponsive in terms of updating our DNS records, so you will need to use the IP address temporarily until I can get this sorted out. >>> >>> You can access the site at: >>> >>> http://155.198.35.162/ >>> >>> A reminder that some project paths have changed. In particular you should update your existing Nektar++ repositories by issuing the command >>> >>> git remote set-url origin git@155.198.35.162:nektar/nektar.git >>> >>> Please let me know if you encounter any problems. >>> >>> Thanks, >>> >>> Dave >>> >>>> On 20 Oct 2014, at 10:17, David Moxey <d.moxey(a)imperial.ac.uk> wrote: >>>> >>>> Dear all, >>>> >>>> A reminder of today's maintenance. I will be taking gitlab offline in the next 15-20 minutes. >>>> >>>> Thanks, >>>> >>>> Dave >>>> >>>>> On 14 Oct 2014, at 14:46, David Moxey <d.moxey(a)imperial.ac.uk> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> For those of you using gitlab to access the Nektar++ git repository, on Monday 20th October I will be performing a transfer to another machine. This is to both give us some new functionality, fix some bugs, and patch various security issues which are present in the current version. >>>>> >>>>> Please note: >>>>> >>>>> - the server will, in all likelihood, be offline for most of the day; >>>>> - you can still use your local git repositories, and none of your local data/branches will be affected; >>>>> - but you won't be able to push those changes back up to gitlab until the maintenance is complete. >>>>> >>>>> Another important point is that currently, one clones the repository by doing: >>>>> >>>>> git clone git@gitlab.nektar.info:nektar.git >>>>> >>>>> This will be changing. The new address will be (but is not yet): >>>>> >>>>> git clone git@gitlab.nektar.info:nektar/nektar.git >>>>> >>>>> For existing repositories, there is no need to clone another version. You should run the command: >>>>> >>>>> git remote set-url origin git@gitlab.nektar.info:nektar/nektar.git >>>>> >>>>> and this will update the url. >>>>> >>>>> I will be in touch again with another reminder and to let you know when the maintenance is complete. >>>>> >>>>> Thanks, >>>>> >>>>> Dave >>>>> _______________________________________________ >>>>> Nektar-users mailing list >>>>> Nektar-users(a)imperial.ac.uk >>>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>>> >>>> -- >>>> David Moxey >>>> Research Associate >>>> Department of Aeronautics >>>> Imperial College London >>>> South Kensington Campus >>>> Room 363, Roderic Hill Building >>>> London, SW7 2AZ >>>> d.moxey(a)imperial.ac.uk >>>> www.imperial.ac.uk/people/d.moxey >>>> >>>> >>>> _______________________________________________ >>>> Nektar-users mailing list >>>> Nektar-users(a)imperial.ac.uk >>>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >>> >>> -- >>> David Moxey >>> Research Associate >>> Department of Aeronautics >>> Imperial College London >>> South Kensington Campus >>> Room 363, Roderic Hill Building >>> London, SW7 2AZ >>> d.moxey(a)imperial.ac.uk >>> www.imperial.ac.uk/people/d.moxey >>> >>> >>> _______________________________________________ >>> Nektar-users mailing list >>> Nektar-users(a)imperial.ac.uk >>> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users >> >> -- >> David Moxey (Research Associate) >> d.moxey(a)imperial.ac.uk | www.imperial.ac.uk/people/d.moxey >> >> Room 363, Department of Aeronautics, >> Imperial College London, >> London, SW7 2AZ, UK. >> >> >> _______________________________________________ >> Nektar-users mailing list >> Nektar-users(a)imperial.ac.uk >> https://mailman.ic.ac.uk/mailman/listinfo/nektar-users > -- David Moxey (Research Associate) d.moxey(a)imperial.ac.uk | www.imperial.ac.uk/people/d.moxey Room 363, Department of Aeronautics, Imperial College London, London, SW7 2AZ, UK.

1 0

Gitlab downtime: Monday 20th October, 10am-5pm
by David Moxey 22 Oct '14

22 Oct '14

Dear all, For those of you using gitlab to access the Nektar++ git repository, on Monday 20th October I will be performing a transfer to another machine. This is to both give us some new functionality, fix some bugs, and patch various security issues which are present in the current version. Please note: - the server will, in all likelihood, be offline for most of the day; - you can still use your local git repositories, and none of your local data/branches will be affected; - but you won't be able to push those changes back up to gitlab until the maintenance is complete. Another important point is that currently, one clones the repository by doing: git clone git@gitlab.nektar.info:nektar.git This will be changing. The new address will be (but is not yet): git clone git@gitlab.nektar.info:nektar/nektar.git For existing repositories, there is no need to clone another version. You should run the command: git remote set-url origin git@gitlab.nektar.info:nektar/nektar.git and this will update the url. I will be in touch again with another reminder and to let you know when the maintenance is complete. Thanks, Dave

1 3

OS X 10.10 Yosemite
by David Moxey 18 Oct '14

18 Oct '14

Dear all, As you may know OS X 10.10 was just released. In the interests of testing the waters, I've performed the upgrade and tested our build process. Everything seems to work, subject to the following two caveats: 1. You need Xcode 6.1 -- currently the app store only has 6.0.1 listed. 6.1 is available at http://developer.apple.com/ for download. Probably 6.1 will go up in the next couple of days. 2. There is no binary installer for MacPorts, so you need to build it from source. Also, note that there are no MacPorts binary downloads for 10.10, so you need to build everything from source. Therefore packages such as openmpi will build gcc and that can take an hour or two, depending on your machine. I would recommend waiting a couple of weeks for these issues to be resolved unless you are willing to put up with them. Thanks, Dave -- David Moxey Research Associate Department of Aeronautics Imperial College London South Kensington Campus Room 363, Roderic Hill Building London, SW7 2AZ d.moxey(a)imperial.ac.uk www.imperial.ac.uk/people/d.moxey

1 0

Cannot get the correct centerline velocity for laminar pipe flow
by Cuneyt Sert 12 Oct '14

12 Oct '14

Dear All, We want to use Nektar++ to perform DNS of blood flow inside constricted vessels. Unfortunately the learning process turned out to be quite slow. We started with the following simple laminar pipe flow problem Diameter = 0.2 m Length = 8 m Kin. viscosity = 2 (10^-3) m2/s Inlet velocity = 1m/s Outlet pressure = 0 Pa Re = 100 Fully developed centerline velocity is known to be 2 m/s. With a fine enough mesh we expect to get this value exactly. But the best we got was 1.974 m/s. We generated the mesh using Gmsh and we suspect that the problem might be related to the curved edge definitions. In the process we observed quite bizarre behaviors, such as even worse centerline velocities as the polynomial order inside the elements is increased. That's why my student Kamil previously asked here couple of questions about this, but I guess some questions remained unanswered or maybe we couldn't interpret the answers properly. To make sure that we're doing everything else right, we generated a similar duct flow problem with straight surfaces. Fully developed centerline velocity is again known and we can easily get that value correct up to 3-4 digits. At this point we're not sure about what we're doing wrong in the pipe flow case. Is it really a curvature issue or something else? We'd really appreciate if you can shed some light. We can share the XML file if that might help to resolve the problem. Thanks in advance for the help and thanks for sharing this flow solver with us. Cuneyt Sert

2 2

Nektar++ running problem with .xml files including curved edges
by Kamil Ozden 04 Oct '14

04 Oct '14

Dear All, About 3 weeks ago I made an update in my computer and after that installed the last version of Nektar in the repository without problem. However, after this installation when I tried to run an analysis with an xml file including Curved edges I got the following error: Initial Conditions: - Field u: 0 - Field v: 0 - Field w: 1 - Field p: 0 Writing: "Re100_v11_2_0.chk" [Dell-Workstation:56500] *** Process received signal *** [Dell-Workstation:56500] Signal: Segmentation fault (11) [Dell-Workstation:56500] Signal code: Address not mapped (1) [Dell-Workstation:56500] Failing at address: 0x9a1b000 [Dell-Workstation:56500] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x36c30) [0x7f5d2d442c30] [Dell-Workstation:56500] [ 1] /usr/lib/libblas.so.3(dgemm_incopy_NEHALEM+0x39e) [0x7f5d2e9a979e] [Dell-Workstation:56500] *** End of error message *** Segmentation fault (core dumped) What may be the reason for this error? Regards, Kamil

3 2

Re: [Nektar-users] Transferring curved edge information to Nektar++
by Kamil Ozden 03 Oct '14

03 Oct '14

Dear All, Regarding my previous question I found that there is an option in Gmsh to get higher order elements for reflecting curvature of the edges into .xml file. However, when I increase the order of the element from 1 to a higher order (e.g. 3) and convert the .xml file to .vtu file I got the message: /*Warning: Level 0 assertion violation*//* *//*3D deformed Jacobian not positive (element ID = 359) (first vertex ID = 206)*/ and the mesh that MeshConvert obtained from Gmsh's .msh file looks like: As far as I know "Jacobian not positive" means there are intersecting elements. What may be the reason for this problem? Regards, Kamil On 18-09-2014 11:36, Kamil Ozden wrote: > Dear All, > > I mesh a circular pipe in Gmsh very coarsely as below and turn it into > a xml file via MeshConvert. However, the curved edge information is > not transferred to the xml file (as seen in the figure at right). How > can I succeed this? Is there any way of doing it in Gmsh or is this > directly related with Nektar++ ?

4 5