June 2010 - Nek5000-users - mailman3.cels.anl.gov

problem with closed internal boundaries
by nek5000-users＠lists.mcs.anl.gov 23 Jul '13

23 Jul '13

Hello Neks, I'm trying to model a flow past an obstacle in a channel. As a first step I would like to do a 2D simulation. I'm encountering some problems during the geometry data generation in the nek5000 execution : it looks like the program can only generate NaN values although genmap seems to work well on the .rea file. I can also reopen the rea file with prenek without any problems. Do you have any idea what is going wrong here? Is it problematic to have a closed internal boundary condition? Thanks in advance for any help. Best, Michael B

1 9

Periodic B.C and Genmap Issue
by nek5000-users＠lists.mcs.anl.gov 09 Nov '12

09 Nov '12

Hi Paul, This post is in reference to the previous post by Michael (dated Jun 22). When I try to get a map file for a rea file that has periodic vertices, I get the following error. The rea file was generated the same way as before (Gambit -> Nek through Matlab). I checked on Matlab by plotting the periodic vertices and confirmed for a few faces that they are indeed periodic. Also, as you had earlier suggested (with the new genmap), I tried changing the tolerances fro 0.09 to 0.2 and I get the same periodic mismatch error. Could you provide any leads on where things are going wrong ? Please find below the error message. Thanks. <error> Input (.rea) file name: domain Input mesh tolerance (default 0.2): NOTE: smaller is better, but generous is more forgiving for bad meshes. 0.09 reading .rea file data ... start locglob_lexico: 8 3912 31296 8.99999999999999967E-002 locglob: 1 1 31296 locglob: 2 36 31296 locglob: 3 1224 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 locglob: 1 4851 31296 locglob: 2 4851 31296 locglob: 3 4851 31296 done locglob_lexico: 4851 4851 31296 10 start periodic vtx: 3912 4851 abort: PERIODIC MISMATCH 2: 1093 1 P ie 0 1 je 4.14470000000000029E-003 0.0000000000000000 bc 8 quit </error> Regards Shriram

1 10

Re: [Nek5000-users] Vanishing Jacobian error description
by nek5000-users＠lists.mcs.anl.gov 10 Mar '11

10 Mar '11

Hi Paul, Here is the rea, usr, & SIZE file I am using. I ran it again without the curved side information and it worked, so I think the problem is somewhere in the curved side section of the rea. The geometry is a square base lofted into a circle in the +z direction. The mesh was generated in gambit. I've developed a matlab code that will take a mesh created in gambit and generate the required REA formatting. I have created some basic shapes to test the matlab portion and the curved side portion, and it worked in most cases (not this one yet). I'm not sure what is going on with the curved side data in this case however. Thanks for looking at this, Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: "Nekton User List" <nek5000-users(a)lists.mcs.anl.gov> Sent: Tuesday, April 20, 2010 3:36:44 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] Vanishing Jacobian error description Michael, The code is trying to check to ensure that the mesh is valid. Sometimes, however, there are other causes for the problem. Can you send a gzip'd rea/usr file, and I can take a look later tonight. Paul On Tue, 20 Apr 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > Hi, > > I am running into an issue with 'Vanishing Jacobian'. To help understand what the problem > is, could someone explain what is meant in the error? Specifically, what it means by "Xth node" of the element. > Also, I ran into this issue when I was deforming geometries in the usr file, where one of the elements > would overlap another by mistake. However in this case I know there are no overlaps. > > Here is a portion: > > 0 ERROR: Vanishing Jacobian near 91th node of element 69. > 1.40692804605498586E-002 -7.79619559165757245E-003 > 0 xyz: 2.65874E-01 3.54498E-01 2.87050E+00 > 0 xyz: 2.07855E-01 1.77249E-01 2.87050E+00 > > > 0 ERROR: Vanishing Jacobian near 76th node of element 70. > 2.59472856644434001E-002 -2.12442422718029170E-002 > 0 xyz: 2.11655E-01 4.23310E-01 2.62500E+00 > 0 xyz: 3.54498E-01 1.77249E-01 2.87050E+00 > > Thanks for any help deciphering this error! > > - Michael > > > > > > _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 4

Visit and NEK 3D data
by nek5000-users＠lists.mcs.anl.gov 06 Jan '11

06 Jan '11

Hello all, I am running into a problem with Visit and NEK 3D data files. Visit (version 1.12.2) reads them in, but the mesh is all jumbled up. If anyone could try Visit on this file, I'd be grateful, perhaps there is some setting in Visit that I overlooked. The data file (4MB) is: http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/si… I use the following meta data file: NEK5000 version: 1.0 filetemplate: c203d.fld%02d firsttimestep: 2 numtimesteps: 1 Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universität Wien (Technical University of Vienna) Inst. f. Strömungsmechanik und Wärmeübertragung (Institute of Fluid Mechanics and Heat Transfer) Resselgasse 3 1040 Wien Tel: +4315880132232 Fax: +4315880132299 Cell:+436765203470 fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.h…

1 29

Re: [Nek5000-users] New Recycling BC method?
by nek5000-users＠lists.mcs.anl.gov 08 Jul '10

08 Jul '10

Paul, See attached for the rea. Thanks, Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Wednesday, June 16, 2010 9:47:29 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? 960 is ok On Wed, 16 Jun 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > > > Paul, > > > > The rea I have now from matlab/gambit has 960 elements. Do you want me to create another, smaller rea that may make it easier to work with? > > > > The geometry by the way is a simple pipe flow. > > > > - Michael > > > ----- Original Message ----- > From: nek5000-users(a)lists.mcs.anl.gov > To: nek5000-users(a)lists.mcs.anl.gov > Sent: Wednesday, June 16, 2010 9:39:59 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Micheal, I agree completely that it's best to avoid mix & match meshing. If you want to send me a gzipped .rea file produced by Gambit, I can take a look and see if I have any ideas. Paul On Wed, 16 Jun 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > > > Hi Paul, > > > > Thanks for the reply. The reason for the interest is due to the Gambit to Nek matlab code. We have had great success importing complex geometries with it, but now we run into the issue of the recycling boundary condition. Gambit's ordering of the elements is not always consistent which makes it impossible to use the current technique. > > > > Our solution was to create the portion that has the recycling in prex and then merge it with the complex part created in Gambit. However, this is proving to be very time consuming and troublesome (Element Mismatch Errors). So, to avoid this I would like to come up with a new recycling method that does not depend on the elements being in a specific order. My u nderstanding is that the current method looks at the inflow, counts a certain number of elements up, copies this outflow from face 6 and puts it back into the inflow face 5. > > > > What I would like to do is replace how the inflow plane is connected to the outflow plane. My idea was to use the connectivity matrix to figure out what the element numbers and outflow faces are at a certain distance away from the inflow plane, and use these faces to connect. The cross-section for the inflow and outflow plane would be the same, but you couldn't necessarily say that it is located, say inflow + 30 elements for example, OR that the outflow and inflow faces are all the same (face 5 for inflow, face 6 for outflow for example). > > > > Do you think this is possible? In a way, you would be creating a new connectivity matrix that governs the recycling BC. > > > > Thanks! > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users@lists. mcs . anl .gov > To: nek5000-use rs@lists. mcs . anl .gov > Sent: Wednesday, June 16, 2010 9:08:00 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > Hi Michael, Access to the connectivity array wouldn't help in this case, given that the recycling bc needs to establish a _new_ connectivity that has nothing to do with the existing one. The examples use this approach of establishing a new connectivity. I'm confident that we can make the existing approach for any mesh that can legitimally employ the recycling bc - i.e., any mesh that has the same cross-sectional distribution of elements at the two planes of interest. An alternative is to use the general purpose interpolation routines. There may (or may not) be a performance issue -- we're looking into this w/ the help of a summer student. Please let me know if I can assist you w/ your specific case. Paul > I am still trying to figure this idea out, but I think I would need to > access the connectivity/boundary condition information that is contained > in the rea file. Does anyone know the array, or what to call in order to > access this in the usr file? Thanks again for a ny help! > > > > - Michael M. > > > ----- Original Message ----- > From: nek5000-users@lists. mcs . anl .gov > To: " Nekton User List" > Sent: Tuesday, June 15, 2010 9:02:00 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC method? > > > > > Hello All, > > > > I am wondering if there is another technique to set up a recycling boundary condition that does not depend on the elements being in a certain order (say based on element coordinates for instance)? I would like to pick the recycling plane based on a given offset distance rather than a number of elements. > > > > Also, the outflow plane faces may not all necessarily be face 6 (and face 5 for the inflow plane). > > > > I have tried going through the examples where a recycling BC is used however I am finding it difficult to understand as my knowledge of Fortan is still growing. Thanks for any help anyone can provide with this idea. > > > > Regards, > > Michael M. > > > > ___________________ ____________________________ Nek5000-users mailing list Nek5000-users@lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users@lists. mcs . anl .gov https ://lists. mcs . anl .gov/mailman/ listinfo /nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 8

Compute the derivatives
by nek5000-users＠lists.mcs.anl.gov 01 Jul '10

01 Jul '10

Hi Nek's, I have a home-made global stability code, but in order to use it I first need to compute the derivatives of my base flow: dUdX, dUdY, dVdX, dVdY. How could one compute these derivatives using Nek 5k and drop them along with X Y U V in the blah.f**** file (or perhaps another .f**** file) ? I assume I have to make use of the subroutine *dudxyz (du,u,rm1,sm1,tm1,jm1,imsh,isd)*, but I'm not sure what to put as inputs. Regards, JC

1 6

E INVALID BC FOUND in genfast
by nek5000-users＠lists.mcs.anl.gov 30 Jun '10

30 Jun '10

Hi all, I am getting the following error when I try to run nek : *0 3912 BC FAIL* *EXIT: E INVALID BC FOUND in genfast 3912* * * I grep-ed to the source code to get an idea of what the error actually means, but I couldn't comprehend whats going on in the code (fast3d.f) . Could anybody tell me what this error actually means ? I checked the Boundary condition of the particular element (3912) and everything seems to be OK. Thanks for any help. Regards Shriram Jagannathan

1 5

Re: [Nek5000-users] Helmholtz error
by nek5000-users＠lists.mcs.anl.gov 29 Jun '10

29 Jun '10

Hi David, The disadvatage of setting p94 to zero is that there is no accelerated convergence in pressure solver due to projection to the solution space. Setting DT>0 will results in an attempt to adjust DT to keep CFL constant set by p25 (COURANT) Another way of setting an iteration tolerence in pressure solver is explicitly to p21 (DIVERGENCE). Best, Aleks On Tue, 29 Jun 2010, David Goluskin wrote: > Thanks, Paul. That fixed it. Is there any disadvantage to having param 94 > set to zero rather than 5? Also, what does setting DT > 0 do? I have > indeed set DIVERGENCE to zero, as you told me this makes tolrel and tolabs > take over. What happens when DIVERGENCE is nonzero? > > Thanks, > > David >

1 0

Helmholtz error
by nek5000-users＠lists.mcs.anl.gov 29 Jun '10

29 Jun '10

Hi nek users, I'm getting an error I don't understand, perhaps someone can help. I'm simulating the Boussinesq equations in a 2D box of aspect ratio 2 with periodic side BC, stress-free velocity and fixed-flux temperature on the top and bottom, and at a Rayleigh number of 10^8. My time step is 2^-6; and longer and there are CFL problems. The part of the logfile where the error first appears is below. Any idea? Thanks a lot, David 321 Hmholtz VELX: 1 1.8722E-04 9.4841E-04 3.0177E-02 321 5.5836E+03 3.0971E-03 1.8028E+06 16 alph1x 321 halpha 16 9.1147E+00 1.6433E-01 1.6202E-03 1.5295E-03 3.2457E-04 9.6963E-05 5.3573E-05 2.3766E-05 1.5049E-05 1.1283E-05 321 Hmholtz VELY: 1 4.5111E-04 3.0971E-03 3.0177E-02 321 16 alpha: 4.3959E-02 1.3360E-03 1.2680E-04 6.4401E-06 -3.8972E-06 3.2052E-06 7.4030E-06 3.4569E-06 2.8993E-06 1.4221E-06 321 16 3.5585E-04 1.2617E-07 2.8203E+03 alph12 321 U-Pres gmres: 3 2.6567E-09 4.1491E-09 1.2617E-07 1.5726E-03 2.5913E-03 321 DNORM, DIVEX 7.71505530689053011E-6 2.65666629955944499E-9 321 6.4200E-04 6.4809E-03 Fluid done 321 6.420000E-04 7.911223E-01 1.711772E+00 umax 321 0.6420E-03 t_av= 0.5000E+00 Ek= 0.1953E+00 Nu= 0.1000E+01 Step 322, t= 6.4400000E-04, DT= 2.0000000E-06, C= 0.000 5.4661E+00 9.7695E-03 Solving for heat Solving for fluid 322 Hmholtz TEMP: 1 9.9844E-03 6.0396E-01 2.4836E-02 322 6.4400E-04 1.0539E-03 Heat done 322 2.0339E+03 5.8756E-03 3.4616E+05 17 alph1x 322 halpha 17 3.3193E+00 1.0787E-01 5.3974E-04 9.8243E-04 3.7291E-04 2.3705E-04 5.1605E-05 3.4660E-05 1.1899E-05 1.1993E-05 322 Hmholtz VELX: 1 1.2039E-03 5.8756E-03 3.0705E-02 322 5.6870E+03 NaN NaN 17 alph1x 322 halpha 17 9.2834E+00 1.7756E-01 1.8590E-03 1.7684E-03 3.7603E-04 1.1302E-04 6.3138E-05 2.9137E-05 1.9115E-05 1.5046E-05 322 5000 **ERROR**: Failed in HMHOLTZ: VELY NaN NaN 3.0705E-02 322 17 alpha: NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN 322 17 NaN NaN NaN alph12 322 U-Pres gmres: 100 NaN 4.1491E-09 NaN 5.2696E-02 8.8512E-02 322 DNORM, DIVEX NaN NaN 322 6.4400E-04 6.0996E-01 Fluid done 322 6.440000E-04 -9.900000E+21 -9.900000E+21 umax 322 0.6440E-03 t_av= 0.5000E+00 Ek= NaN Nu= NaN Step 323, t= 6.4600000E-04, DT= 2.0000000E-06, C= 0.000 6.0793E+00 6.1319E-01 Solving for heat Solving for fluid 323 5000 **ERROR**: Failed in HMHOLTZ: TEMP NaN NaN 2.4836E-02 323 6.4600E-04 5.2047E-01 Heat done 323 NaN NaN NaN 18 alph1x 323 halpha 18 NaN NaN NaN NaN NaN

1 1

Re: [Nek5000-users] Periodic Mismatch 1
by nek5000-users＠lists.mcs.anl.gov 29 Jun '10

29 Jun '10

Hi, I was able to solve this by removing the element face count column. I now run into the following issue shown below. I was able to find the subroutine spec_bis_conn where this error occurs. I believe this has to do with the periodic faces I have set up. My question is whether the periodic faces need to be continuous: For example, the geometry is similar to fluid flow over a flat plate on both sides. The fluid is periodic, but separated by the solid thickness (this is a Conj HT problem). Essentially there is a "gap" in the periodic fluid portion if you can imagine. I saw a note in the routine that says something like "ensure that all graphs are connected", not sure if this is what it means. I tried making the fluid periodic on only one side of the plate and it worked, however when I make the other side (bottom of the plate) periodic with itself I get the following error. Any thoughts? Thanks - Michael M. start rec_bisect: 2006 done: 0.0% done: 1.0% done: 2.0% done: 3.0% infinite loop not connected 1 63 1 0 not connected 1 32 2 0 not connected 1 16 3 0 not connected 1 8 4 0 not connected 1 4 5 0 done: 4.0% not connected 13 31 6 0 Segmentation fault (core dumped) ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: "Nekton User List" <nek5000-users(a)lists.mcs.anl.gov> Sent: Tuesday, June 29, 2010 11:53:10 AM GMT -06:00 Guadalajara / Mexico City / Monterrey Subject: Re: [Nek5000-users] Periodic Mismatch 1 Hi, I am getting a 'Periodic Mismatch 1' error: abort: PERIODIC MISMATCH 1: 1 3 P ie 1 6 E je 6 1 E ke I grep'd to the error in genmap.f and from what I can tell this bit of code is checking to ensure that the elements and faces I have said are periodic, match up with the other corresponding elements and faces. From the error, it seems to think that face 3 of element 1 is Periodic, and then returns this error because of course it is not. I have attached the rea. I am not sure what the issue is here, and why it is not recognizing face 1 as periodic (as you will see in the rea, Elem 1 face 1 is periodic with elem 6 face 3). This error occurs at the first element. The values in the error message all seem to come from the periodic condition I have specified, but it is almost as if they are not in the correct order in the rea. >From my understanding: " P 1 1.00 6.00000 3.00000 0.00000 0.00000 0.00000 " states that element 1 face 1 is periodic with element 6 face 3. Thanks for any help with this, Michael M. _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 0