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

New Recycling BC based on interpolation
by nek5000-users＠lists.mcs.anl.gov 19 Jul '10

19 Jul '10

Hi Michael and Markus, Here is a test case for an unsteady pipe flow with Michael's GambitPipe.rea file which sets inlet Recycling BCs based on interpolation from a cross-section downstream that you specify by a multiple of the inlet normal: http://www.mcs.anl.gov/~obabko/z4.tgz Let me know if you have any questions. Best, Aleks ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Thursday, July 8, 2010 5:06:48 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? No worries, just checkin in to see how it was going, thanks for the update! Look forward to trying it out! - Michael

1 5

Uservp, eddy diffusivity and explvis
by nek5000-users＠lists.mcs.anl.gov 18 Jul '10

18 Jul '10

Howdy, I was trying to test an eddy viscosity model for an internal flow problem with heat transfer - set up very similar to turbChannel. The domain contains a stagnating region, from which the attached picture shows a slice (flow in x from left, wall at bottom and right side is also wall, the flow goes around this cylinder in/out of the in-plane/y-direction). The viscosity computation kicks in after the 2nd time step, before that diffusivity is just equal param(2) (rho is unity). What happens though is that as soon as I start the simulation with uservp (param 30 > 0), the velocity goes nuts in the stagnation region, starting from step 0, even though viscosity does not (yet) change. After some debugging, I found that this behavior is caused by the following line which I took from turbChannel: "if(ifsplit .and. param(30).gt.0) ifexplvis = .true." ifsplit is true in my case, so this condition is met and yields the weird behavior as seen in the plot. When I comment it out, however, everything seems normal and even the eddy viscosity computation seems to work well, although I haven't done long term testing yet. What would you advise me to do? I am using rev548. Thanks, Markus

1 0

Re: [Nek5000-users] New Recycling BC based on interpolation
by nek5000-users＠lists.mcs.anl.gov 16 Jul '10

16 Jul '10

Hi Paul, Thanks for the emails. At present, it seems easier and more straight forward to use a discriminator for RBC so long as it doesn't effect any other routine (like you mentioned other routines that use 'v '). I think, but could be wrong, that the recycling routine negates using the 'v ' boundary condition for that particular inlet? I think that as long as the discriminator change doesn't effect anything and at the same time, not calling it 'v ' doesn't cause any issues that the discriminator would be easier. In the mean time I can try creating the bc() based on cbc and geometry location and use that. - Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Friday, July 16, 2010 5:32:17 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC based on interpolation Hi Michael, As a follow-up --- if you need me to code up a more sophisticated discriminator, I'm happy to do so. Paul On Fri, 16 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > > > Hi Michael, > > Thanks for the suggestion --- I think it's a good one, but we're > not quite there yet. I have a couple of comments - > > Technically "R " is the same as "v " --- because it is a time-space > varying prescribed Dirichlet condition. > > Why not simply populate bc(4,f,e,1) with 1,2,3,... to indicate that it is a > Recycle bc of type 1,2,3,... ? For every cbc, there > are 6 bc() entries (i.e, bc(k,f,e,1) for k=1 to 6). For "v ", the first one > of these (k=1) is reserved. > > That being said, genmap doesn't care about any bc other than "O " and > "P " (in fact, only "P " at this point), so you could in fact do what > you propose right now, as long as you replace in usrdat or usrdat2 with > the functionally correct "v " bc. > > At present I'm a bit reluctant to make a change to the repo that is > still in flux w.r.t. development -- There are a few issues to resolve. > Presumably what one wants to be able to specify is the translation > distance -- with respect to what? -- and the scale factor as a function > of time. We have selected w.r.t. to the unit normal on the R face. In > exact arithmetic there's no difficulty - but in some tricky situations > there will be problems. Rather than try to engineer a solution for all > possible scenarios I think it's best to handle this on a case-by-case > basis until we get a handle on what works and what doesn't. > > There are also performance issues to be investigated, particularly at > high processor counts. > > In a few months I expect we'll have a consolidated code team such > that we can implement changes (at least the mechanics of them) > without much difficulty. Right now (through the summer) we're > a bit saturated. > > Paul > > > On Fri, 16 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > >> Oh ok. >> >> Let's say that I leave one inlet as 'v ', but then change the other >> inlet to some other variable 'v1 ' or 'X ' or whatever. Would this be >> ok, without interfering with other routines? >> >> I suppose where this discussion is heading is: What is the possibility >> of adding a recycling boundary condition explicity in Nek, such that >> you can apply it like any other boundary condition, say R for example. >> So, in the routine you now search for this recycling flag 'R', and >> then run through the setup, rescale etc...? >> >> -Michael >> >> ----- Original Message ----- >> From: nek5000-users(a)lists.mcs.anl.gov >> To: nek5000-users(a)lists.mcs.anl.gov >> Sent: Friday, July 16, 2010 4:47:11 PM GMT -06:00 US/Canada Central >> Subject: Re: [Nek5000-users] New Recycling BC based on interpolation >> >> >> Hi Michael, >> >> Use whatever discrimination you like --- I would not suggest >> modifying the character bcs, however, save that you can enter >> values in bc(k,f,e,1) for k > 1, for any cbc(f,e,1) = 'v ' >> >> The reason for this is that nek checks explicitly for cbc='v ' >> (v, followed by two spaces) in many locations. >> >> The correct place for discriminating parameters is in the >> arracy bc(). >> >> Normally I discriminate by geometry --- e.g., x < x0, or >> something similar, occasionally involving the unit normals on >> the face in question - as that can be a stronger discriminator. >> >> Paul >> >> >> On Fri, 16 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: >> >>> Hi Aleks, >>> >>> Thank you very much for looking into this. I already have a question; I >>> noticed that you marked several notes dealing with "RBC single inlet -- >>> modify for other cases". I am assuming this means that you have one inlet >>> that you want to recycle, but another inlet that you do not want to >>> recycle, which just happens to be my case. >>> >>> Can I distinguish in the rea between the two by "v1 " and "v2 " without >>> giving genmap any problems, and then modify the checks in the usr file >>> accordingly? Also, the subroutine rescale_inflow mentions to modify for >>> multiple inlets as well but I do not see where any modification >>> could/needs to be done for it. >>> >>> - Michael >>> >>> ----- Original Message ----- >>> From: nek5000-users(a)lists.mcs.anl.gov >>> To: nek5000-users(a)lists.mcs.anl.gov >>> Sent: Friday, July 16, 2010 3:03:52 PM GMT -06:00 US/Canada Central >>> Subject: [Nek5000-users] New Recycling BC based on interpolation >>> >>> Hi Michael and Markus, >>> >>> Here is a test case for an unsteady pipe flow with Michael's >>> GambitPipe.rea file which sets inlet Recycling BCs based on interpolation >>> from a cross-section downstream that you specify by a multiple of the >>> inlet normal: >>> >>> http://www.mcs.anl.gov/~obabko/z4.tgz >>> >>> >>> Let me know if you have any questions. >>> Best, >>> Aleks >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users(a)lists.mcs.anl.gov >>> To: nek5000-users(a)lists.mcs.anl.gov >>> Sent: Thursday, July 8, 2010 5:06:48 PM GMT -06:00 US/Canada Central >>> Subject: Re: [Nek5000-users] New Recycling BC method? >>> >>> >>> >>> >>> >>> No worries, just checkin in to see how it was going, thanks for the >>> update! Look forward to trying it out! >>> >>> >>> >>> - Michael >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 2

Re: [Nek5000-users] New Recycling BC based on interpolation
by nek5000-users＠lists.mcs.anl.gov 16 Jul '10

16 Jul '10

Hi Aleks, Thank you very much for looking into this. I already have a question; I noticed that you marked several notes dealing with "RBC single inlet -- modify for other cases". I am assuming this means that you have one inlet that you want to recycle, but another inlet that you do not want to recycle, which just happens to be my case. Can I distinguish in the rea between the two by "v1 " and "v2 " without giving genmap any problems, and then modify the checks in the usr file accordingly? Also, the subroutine rescale_inflow mentions to modify for multiple inlets as well but I do not see where any modification could/needs to be done for it. - Michael ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Friday, July 16, 2010 3:03:52 PM GMT -06:00 US/Canada Central Subject: [Nek5000-users] New Recycling BC based on interpolation Hi Michael and Markus, Here is a test case for an unsteady pipe flow with Michael's GambitPipe.rea file which sets inlet Recycling BCs based on interpolation from a cross-section downstream that you specify by a multiple of the inlet normal: http://www.mcs.anl.gov/~obabko/z4.tgz Let me know if you have any questions. Best, Aleks ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Thursday, July 8, 2010 5:06:48 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC method? No worries, just checkin in to see how it was going, thanks for the update! Look forward to trying it out! - Michael _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 4

Re: [Nek5000-users] New Recycling BC based on interpolation
by nek5000-users＠lists.mcs.anl.gov 16 Jul '10

16 Jul '10

Hi Michael, In this test case, we just only one inlet with 'v ' for Recycling BCs and 'W ' for no-slip wall and there was no need for further discriminator like coordinates, faces, etc. as Paul has just suggested. In case you need to use RBC for two inlets both with RBCs but different ubar/s1, you can have in addition to total number of points npts also an array of number of points for each inlet like napts = [npts1,npts2] which you can set in set_inflow/get_shift. Then in rescale_inflow instead of a single loop over total npts you need to have subloops over the conent of napts each of them rescaling to the different value of ubar according to the inlet. Best, Aleks ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Friday, July 16, 2010 4:47:11 PM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] New Recycling BC based on interpolation Hi Michael, Use whatever discrimination you like --- I would not suggest modifying the character bcs, however, save that you can enter values in bc(k,f,e,1) for k > 1, for any cbc(f,e,1) = 'v ' The reason for this is that nek checks explicitly for cbc='v ' (v, followed by two spaces) in many locations. The correct place for discriminating parameters is in the arracy bc(). Normally I discriminate by geometry --- e.g., x < x0, or something similar, occasionally involving the unit normals on the face in question - as that can be a stronger discriminator. Paul On Fri, 16 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: > Hi Aleks, > > Thank you very much for looking into this. I already have a question; I noticed that you marked several notes dealing with "RBC single inlet -- modify for other cases". I am assuming this means that you have one inlet that you want to recycle, but another inlet that you do not want to recycle, which just happens to be my case. > > Can I distinguish in the rea between the two by "v1 " and "v2 " without giving genmap any problems, and then modify the checks in the usr file accordingly? Also, the subroutine rescale_inflow mentions to modify for multiple inlets as well but I do not see where any modification could/needs to be done for it. > > - Michael > > ----- Original Message ----- > From: nek5000-users(a)lists.mcs.anl.gov > To: nek5000-users(a)lists.mcs.anl.gov > Sent: Friday, July 16, 2010 3:03:52 PM GMT -06:00 US/Canada Central > Subject: [Nek5000-users] New Recycling BC based on interpolation > > Hi Michael and Markus, > > Here is a test case for an unsteady pipe flow with Michael's GambitPipe.rea file which sets inlet Recycling BCs based on interpolation from a cross-section downstream that you specify by a multiple of the inlet normal: > > http://www.mcs.anl.gov/~obabko/z4.tgz > > > Let me know if you have any questions. > Best, > Aleks > > > > > ----- Original Message ----- > From: nek5000-users(a)lists.mcs.anl.gov > To: nek5000-users(a)lists.mcs.anl.gov > Sent: Thursday, July 8, 2010 5:06:48 PM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] New Recycling BC method? > > > > > > No worries, just checkin in to see how it was going, thanks for the update! Look forward to trying it out! > > > > - Michael > > _______________________________________________ > 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 0

r,s,t index for given point
by nek5000-users＠lists.mcs.anl.gov 16 Jul '10

16 Jul '10

Howdy Neks, is there a function in Nek that for a given point in x,y,z would return processor number, element number and r,s,t index of the nearest GLL grid point? I was desperately trying to figure out how the interpolation routines (f.e. for history points) would help me, but I only got garbage (-1, 0 and 1) back for the variables I would expect contain r,s,t. It worked with the element number, however. Thanks, Markus

1 18

Marangoni flow
by nek5000-users＠lists.mcs.anl.gov 16 Jul '10

16 Jul '10

Hello all, At present we are working on understanding some rotating/traveling waves that occur in a cylindrical geometry. In particular, the effect of the grid on the solution is of interest. The results from the following grid in the xy plane, (it is simply extruded in the z direction) exhibit a somewhat unexpected (chaotic) behavior. Would welcome any and all comments concerning the quality of this mesh. http://www.cct.lsu.edu/~fmuldoo/temp/m-3.png P.S. The reason for looking at a mesh with m=3 symmetry is due to the existence of either m=3 and m=4 rotating/traveling waves; meshes with m=3 and m=5 symmetry have also been looked at and give identical (non chaotic) results. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universität Wien (Vienna Technical University) 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 6

Re: [Nek5000-users] r,s,t index for given point
by nek5000-users＠lists.mcs.anl.gov 13 Jul '10

13 Jul '10

Thanks, that helped a lot! ----- Original Message ----- From: nek5000-users(a)lists.mcs.anl.gov To: nek5000-users(a)lists.mcs.anl.gov Sent: Tuesday, July 13, 2010 4:38:28 AM GMT -06:00 US/Canada Central Subject: Re: [Nek5000-users] r,s,t index for given point Hi Michael, Points in the volume are stored in lexicographical order: real u(lx1,ly1,lz1) implies that u(i+1,j,k) follows u(i,j,k) in memory, so the data layout (in memory) is: u(1,1,1) u(2,1,1)...u(lx1,1,1) u(1,2,1) u(2,2,1)... u(lx1,ly1,lz1) For u(i,j,k) the i index is associated with r, j with s, and k with t. There are two numberings of the faces. The one that you're most likely to interact with, and which is used for assigning bcs, unit normals, surface Jacobians, etc. is what we refer to as the "preprocessor notation". In 2D, preprocessor notation uses the counter-clockwise ordering: ^ s | Face 3 +-----------+ | | | | | | Face 4 | +-----|--> r | | | | Face 2 +-----------+ Face 1 In 3D, it's the same, save that you also have Face 5 assocated with t=-1 and Face 6 associated with t=+1. When you traverse a face, the indices describing that 2D manifold advance in positive order and in that case the associated face objects (e.g., unit normals and area) will have unit stride. There are two ways to stride across a face f=1,...,6 (and there are many routines implementing these). Here is one: integer e,f call facind (i0,i1,j0,j1,k0,k1,f) ia = 0 flux = 0 do k=k0,k1 do j=j0,j1 do i=i0,i1 ia = ia + 1 flux = flux + ( vx(i,j,k,e)*unx(ia,1,f,e) $ vy(i,j,k,e)*uny(ia,1,f,e) $ vz(i,j,k,e)*unz(ia,1,f,e) )*area(ia,1,f,e) enddo enddo enddo Here is another: call facind2 (js1,jf1,jskip1,js2,jf2,jskip2,f) ia = 0 flux = 0 do j2=js2,jf2,jskip2 do j1=js1,jf1,jskip1 ia = ia+1 flux = flux + ( vx(j1,j2,1,e)*unx(ia,1,f,e) $ + vy(j1,j2,1,e)*uny(ia,1,f,e) $ + vz(j1,j2,1,e)*unz(ia,1,f,e) )*area(ia,1,f,e) enddo enddo I like the second approach because it is faster. Note that unx,uny,unz are _face_ based structures, while vx vy vz are volumetric. I think if you study these loops for a bit you should be able to see the connections between the two data layouts. Paul On Mon, 12 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: Hi Paul, To expand on this topic, I am wondering what the convention being used to number the GL points for an element is? Could you explain this? Thinking of it terms of the r-s-t diagram for a nekton element, I know from previous examples that face 5 contains points 1 to lx1*ly1. Also, face 6 should contain points (lz1-1)*lx1*ly1 to lx1*ly1*lz1. What I am trying to figure out, is what points are on the remaining faces, and understanding the convention I think would be useful. Thanks for the help! > > - Michael > > > ----- Original Message ----- > From: nek5000-users(a)lists.mcs.anl.gov > To: nek5000-users(a)lists.mcs.anl.gov > Sent: Monday, July 12, 2010 5:13:47 AM GMT -06:00 US/Canada Central > Subject: Re: [Nek5000-users] r,s,t index for given point > > fixed in r548. > Stefan > > On Jul 12, 2010, at 10:49 AM, nek5000-users(a)lists.mcs.anl.gov wrote: > >> >> Hi Markus, >> >> lglel reads "local to global element number" so input is >> local element number and output is global element number. >> >> I'll be seeing Stefan this week so I'm sure we can straighten >> out the interpolation routines. >> >> You're right about the other points - the ntotv wasn't flagged >> by my compiler and the .his file was taken care of by my own >> scripts, so I didn't catch either of them. Sorry about that. >> I've updated the source so that those issues should be >> resolved. >> >> Paul >> >> >> On Mon, 12 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> that was not it, I'm afraid (though I thought gllel transforms from local to global). >>> >>> But I also realized that the hpts routine does not deliver the correct values for me. To test this, I set up a simple 3d box with inflow, outflow and symmetry all around, Re very low, initial condition=boundary condition and 4 points. >>> Please find all files attached, the output for the first point is OK, but then the values seem to shift positions and don't make sense. >>> >>> Also, when running it for 1 step or more, I get the error message: >>> " >>> dump history points >>> done :: dump history points >>> hisfile: >>> /Users/m0s1978/nektonruns/rectest/rectest.his >>> ERROR: .sch file already exists. ierr= 1 >>> " >>> >>> And lastly, the newest repo won't compile, here is the error message: >>> " >>> Error: /Users/m0s1978/nek5trial/trunk/nek/drive2.f, line 1551: This name has already been assigned a data type. [NVTOT] >>> integer*8 ntot,nvtot,nptot >>> ---------------------^ >>> " >>> >>> Thanks for any help, >>> Markus >>> >>> >>> nek5000-users(a)lists.mcs.anl.gov wrote: >>>> Hi Markus, >>>> It's possible that it's returning the local (to the processor) >>>> element number. You would get the global (to the computational >>>> domain, defined by the .rea file) element number via: >>>> >>>> integer e,eg >>>> >>>> eg = lglel(e) >>>> Paul >>>> On Sun, 11 Jul 2010, nek5000-users(a)lists.mcs.anl.gov wrote: >>>>> Hi again, >>>>> Regarding finding element numbers (such as what gllel would return) for arbitrary history points, I was experimenting with the history point routine hpts a little and it seems that this function call: >>>>> >>>>> call findpts(inth_hpts,rcode,1, >>>>> & proc,1, >>>>> & elid,1, >>>>> & rst,ndim, >>>>> & dist,1, >>>>> & pts(1,1),ndim, >>>>> & pts(2,1),ndim, >>>>> & pts(3,1),ndim,npoints) >>>>> does not return the same element number (elid) as it can be found in the .rea file, for instance. >>>>> For a handful of manually set points, I checked that the returned element number does not provide the right coordinates to enclose the desired point. >>>>> Is there a way to transform the function return or am I missing something else? >>>>> Thanks, >>>>> Markus >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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 > _______________________________________________ Nek5000-users mailing list Nek5000-users(a)lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users

1 0

prex mesh precision
by nek5000-users＠lists.mcs.anl.gov 13 Jul '10

13 Jul '10

Hello all, I was wondering what would be involved in getting "prex"/"prenek" to perform all calculations in double precision and to output a mesh in this precision. In the cases we are looking at which involve understanding stability boundaries and growth rates, the high accuracy of NEK is the prime reason for using it. There is some concern that an inaccurate representation of the boundary could potentially be a source of meaningful error, in particular in the course of grid refinement studies. Putting my two cents in, it seems somewhat incongruous for the fundamental geometry definition for such a highly accurate method/code to be in single precision. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering Technische Universität Wien (Vienna Technical University) 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 2

Re: [Nek5000-users] Compute the derivatives
by nek5000-users＠lists.mcs.anl.gov 12 Jul '10

12 Jul '10

Thanks a lot for you answer. But if I compute all my derivates in this way, I have deviation in my momentum equations... In the stagnation point of my sphere (u=v=w=0) I get the following: -1/rho dp/dx = 0.4125 nu (d2u/dx2 + d2u/dy2 + d2u/dz2) = 0.3775 --> delta = 3.5e-2 Do you have an idea from where this delta might result?? Best, Fred

1 3