From nek5000-users at lists.mcs.anl.gov Tue May 1 06:35:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 1 May 2012 06:35:46 -0500 (CDT) Subject: [Nek5000-users] Good input dataset for NEK5000 runs In-Reply-To: References: Message-ID: Hi Abhishek, I would recommend turbChannel. The example that is there has only 512 elements and thus probably wouldn't be suitable at 256 cores (though it will certainly work up to an including 512 cores). In general, there is a lower bound on the number of points per core, n/P, required to in order to have enough work per core to offset the communication overhead. For well-implemented domain-decomposition based strategies, this lower bound should be weakly dependent on the code as there is a basically a certain amount of work to be done (which grows as the domain volume - n/P) and a certain amount of communication (which grows as the surface area ~ (n/P)^2/3). If communication is slow compared to the computation rate, then n/P must be larger to give enough work. This increase in n/P is generally realized by decreasing the number of processors for the given problem (n). The point where communication time equals computation time is a reasonable estimate of the upper bound on P that can be effectively used (though we would typically take P smaller than this figure). The lower-bound n/P value for BG/P and BG/L architectures is n/P ~ 5000---10000 (points per core), at P=100,000. The number is not stronly dependent on P. (Again, this holds for any domain-decomposition strategy, not just Nek.) We find, for example, parallel efficiency of 0.8 for P=131072 and n=10^9 (n/P=7300). (See www.mcs.anl.gov/~fischer/sem1b www.mcs.anl.gov/~fischer/pubhtml Paul Fischer, James Lottes, David Pointer, and Andrew Siegel Petascale Algorithms for Reactor Hydrodynamics, J. Phys. Conf. Series (2008). for discussion.) NOTE that on a machine with a (relatively) slower interconnect or faster clock, you will need larger n/P to get the same parallel efficiency. You can get a lot of platform information by calling "platform_timer(1)" from the .usr file. (This is time consuming, so best done as an independent run.) The platform_timer(iverbose) call provides estimates of flop rates for matrix-matrix products relevant to nek and estimates of communication latency and bandwidth. From those, we can estimate the lower n/P bound. Coming back to your question. Let's assume you're running on a BG architecture and you need n/P ~ 5000-10000. If you run with ~5 elements per core and lx1=11, you would have n/P = 5 x 10^3 = 5000. If you want to run this at P=256, you would need E = 256 x 5 elements = 1250 elements to realize reasonable efficiency. In Nek, there are two ways to increase n: increase number of elements (E) or approximation order (N=lx1-1), for a total point count of n ~ EN^3. For the turbChannel case, you can increase E by increasing the number of elements in the box file, rerunning genbox followed by genmap to generate a new .rea file, and then run the code. You can also increase n by increasing lx1. The latter option is fine, but if you go too high you're probably not in the regime where you would likely be doing production runs, though we've certainly had cases at ANL and elsewhere where people have run with N=40 or more. I hope this helps. Paul On Mon, 30 Apr 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I am looking for a suitable input set for using NEK to compare some > platforms (with diff interconnects). What is a good input set to do > experiments up to 256 cores ? One from examples ? I came across papers > where people have used G6a but I am unable to find that. > > Thanks, > Abhishek > > > On Mon, Apr 30, 2012 at 3:55 PM, Abhishek Gupta wrote: > >> Hi, >> >> I am looking for a suitable input set for using NEK to compare some >> platforms (with diff interconnects). What is a good input set to do >> experiments up to 256 cores ? One from examples ? I came across papers >> where people have used G6a but I am unable to find that. >> >> Thanks, >> Abhishek >> >> > From nek5000-users at lists.mcs.anl.gov Wed May 2 05:09:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 02 May 2012 12:09:46 +0200 Subject: [Nek5000-users] Follow up: rotating disk with periodic boundaries (Nek5000-users Digest, Vol 37, Issue 20) Message-ID: <4FA107EA.2000500@mech.kth.se> Dear Nek users, earlier I wrote an e-mail concerning how to make an element periodic with itself (see below). The goal was to decrease the domain of my simulation over a rotating disk. I've now tried three different mesh setups where I don't need to make the element periodic with itself in two of them. Currently, I also try to use the cyclic boundary conditions which in my opinion should work. However, it doesn't. I still get the communication error in Nekton (see email below) and also I get an error from genmap. I attached a folder with figures of my meshes (named a,b,c from left to right) and necessary files in order to run the case. Do you think that the cyclic boundary conditions should work for my case? Maybe there is a quick-fix for this communication error? Or do you have any other suggestion on how to do this? I would like to avoid to remap the grid from a straight to a curved one since I would like to have fewer elements toward the center of the disk. Best regards, Ellinor On 03/28/2012 12:27 PM, nek5000-users-request at lists.mcs.anl.gov wrote: > Send Nek5000-users mailing list submissions to > nek5000-users at lists.mcs.anl.gov > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > or, via email, send a message with subject or body 'help' to > nek5000-users-request at lists.mcs.anl.gov > > You can reach the person managing the list at > nek5000-users-owner at lists.mcs.anl.gov > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nek5000-users digest..." > > > Today's Topics: > > 1. rotating disk with periodic boundaries > (nek5000-users at lists.mcs.anl.gov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 28 Mar 2012 12:27:25 +0200 > From: nek5000-users at lists.mcs.anl.gov > Subject: [Nek5000-users] rotating disk with periodic boundaries > To: nek5000-users at lists.mcs.anl.gov > Message-ID: <4F72E78D.5000802 at mech.kth.se> > Content-Type: text/plain; charset="iso-8859-1" > > Dear nek users, > I am doing simulations over a rotating disk with nekton and would like to > decrease my domain in order to save computational time. > > The mesh is currently very similar to that of a pipe, with inflow in one > end > (max(z)) and a rotating wall in the other end (z=0). Around the curved > edges I use the outflow boundary condition. > > The way I would like to decrease the domain in is by using periodic > boundary conditions in the rotational direction, that is cutting the > pipe in the > z-direction to only use a third or a quarter of the pipe. > > My problem is that when I try to do this, I have to make one element > periodic > with itself, this is since I would like to have few elements in the > middle of > the domain and thus not want to use the cylindrical coordinates. > > In some setups, I recieve an error when using genmap (when trying > different mesh > tolerance numbers), and in some setups I get a communication error when > running > the code; > > > genmap error: > > 4 z1 0.0000E+00 1.5224E-01 1.5224E-01 0.0000E+00 > 2 3 3 1.00000005E-03 1.00000000E+00 abort: FACE MATCH FAIL > 7 4 5 1.00000005E-03 2.54558474E-01 abort: FACE MATCH FAIL > > > communication error: > > veryfy mesh topology ... > ... > ... > WARNING1 Element mesh mismatch at: > i,j,k,ie: 1 1 1 1 > Near X = 0.59397000 0.59397000 0.00000000 , d: 0.0000000 > -0.11313799 1.4142136 > ... > ... > > > > The type of error seem to depend on how the elements are numbered in the > domain. > > I've understood that for using the periodic boundary conditions, one > need at > least three elements. Is there a way around this when it comes to my setup? > Or would there be an easy fix for this problem? > > > Best regards, > Ellinor > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: mesh.dra > URL: > > ------------------------------ > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > End of Nek5000-users Digest, Vol 37, Issue 20 > ********************************************* > > -------------- next part -------------- A non-text attachment was scrubbed... Name: mesh.tar.gz Type: application/x-gzip Size: 144365 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri May 4 06:55:03 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 May 2012 13:55:03 +0200 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: References: <4F7DC3FB.3020605@onera.fr> Message-ID: Hi Neks, another point I'm (even more) interested in is: how do you do your FFT analysis? I guess in a first step the grid is mapped onto a regular grid (ifreguo = .true.) and in a second step the FFT is computed at that grid. Then the question arises: What is a good choice for "nrg" (with nrg as the dimension of regular grid (nrg**ndim)...)? nrg=lx1 or lx1-1? Regards Jan 2012/4/13 Jan Frielinghausen : > Hi Neks, Hi Can, > I too would be very interested in getting more information about these routines. > regards > Jan > > Am 5. April 2012 18:10 schrieb ?: >> Hi neks ! >> >> For a given velocity field >> (vx(1:lx1,1:ly1,1:lz1,1:lelv),vy(1:lx1,1:ly1,1:lz1,1:lelv),vz(1:lx1,1:ly1,1:lz1,1:lelv)) >> i would like to calculate the energy spectrum, this implies FFT >> transformation on regular arrays >> vx(1:n,1:n,1:n),vy(1:n,1:n,1:n),vz(1:n,1:n,1:n) (need >> deltax=deltay=deltaz=cst). >> On the emailing-list it has been said : >> "We do have off-line serial routines >> that can transfer data from an nelx x nely x nelz array of Nth-order >> elements to an nxnxn array - this allows for analysis by FFTs etc" >> >> >> Can you please tell me more about this ? What are these routines ?? >> B.regards >> Can >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri May 4 07:48:18 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 4 May 2012 07:48:18 -0500 (CDT) Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: References: <4F7DC3FB.3020605@onera.fr> Message-ID: Dear All, This has been a topic of great interest of late and we've had a lot of discussion among the developers. Ultimately, the choice of approach has to be influenced by the anticipated scale of the analysis. If you're going to analyze 128^3, this can likely be done with matlab on a single workstation. If you're planning to look at 4096^3, then a custom approach would be required in order to go after the statistics of interest, in parallel. The latter case is harder - and it is certainly hard to provide a general solution. Katie has been working on putting our sem2lex (spectral element to lexicographical ordering) code into the tools directory, which is a stand-alone code that will take output fields associated with any SEM mesh generated by genbox (which ensures that the elements are ordered lexicographically, ex-ey-ez) and maps it to pointwise lexicographical ordering (i,j,k). Such data is then ready for processing in matlab or other code. This is a reasonable approach up to around 400 cubed, I would guess, but might be unwieldy after that. Probably sem2lex will work for even larger datasets. The question then is how you would process them. Regarding the question of resolution, I typically go with a one-to-one ratio --- If I have Ex elements in the x-direction of order N, then I set nx=N*Ex. (Note that N=lx1-1, where lx1 is specified in the SIZE file.) One can argue whether this choice of nx is over- or under-sampled. My sentiment is that you shouldn't attach too much significance to the upper part of the spectrum in any case since resolution is marginal there in any case. (Another way of thinking about it --- as you near the Nyquist limit of kmax=nx/2, the results are necessarily dominated by numerical truncation error, and not physics.) We hope to have the sem2lex in the repo soon (i.e., next week) and will send out an email when it's in place. I hope this helps. Paul On Fri, 4 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > another point I'm (even more) interested in is: how do you do your FFT analysis? > I guess in a first step the grid is mapped onto a regular grid > (ifreguo = .true.) and in a second step the FFT is computed at that > grid. > Then the question arises: What is a good choice for "nrg" (with nrg as > the dimension of regular grid (nrg**ndim)...)? nrg=lx1 or lx1-1? > Regards > Jan > > 2012/4/13 Jan Frielinghausen : >> Hi Neks, Hi Can, >> I too would be very interested in getting more information about these routines. >> regards >> Jan >> >> Am 5. April 2012 18:10 schrieb ?: >>> Hi neks ! >>> >>> For a given velocity field >>> (vx(1:lx1,1:ly1,1:lz1,1:lelv),vy(1:lx1,1:ly1,1:lz1,1:lelv),vz(1:lx1,1:ly1,1:lz1,1:lelv)) >>> i would like to calculate the energy spectrum, this implies FFT >>> transformation on regular arrays >>> vx(1:n,1:n,1:n),vy(1:n,1:n,1:n),vz(1:n,1:n,1:n) (need >>> deltax=deltay=deltaz=cst). >>> On the emailing-list it has been said : >>> "We do have off-line serial routines >>> that can transfer data from an nelx x nely x nelz array of Nth-order >>> elements to an nxnxn array - this allows for analysis by FFTs etc" >>> >>> >>> Can you please tell me more about this ? What are these routines ?? >>> B.regards >>> Can >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Fri May 4 07:51:15 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 04 May 2012 14:51:15 +0200 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: References: <4F7DC3FB.3020605@onera.fr> Message-ID: <4FA3D0C3.4090409@onera.fr> Le 04/05/2012 13:55, nek5000-users at lists.mcs.anl.gov a ?crit : > Hi Neks, > another point I'm (even more) interested in is: how do you do your FFT analysis? > I guess in a first step the grid is mapped onto a regular grid > (ifreguo = .true.) and in a second step the FFT is computed at that > grid. > Then the question arises: What is a good choice for "nrg" (with nrg as > the dimension of regular grid (nrg**ndim)...)? nrg=lx1 or lx1-1? > Regards > Jan > > 2012/4/13 Jan Frielinghausen: >> Hi Neks, Hi Can, >> I too would be very interested in getting more information about these routines. >> regards >> Jan >> >> Am 5. April 2012 18:10 schrieb: >>> Hi neks ! >>> >>> For a given velocity field >>> (vx(1:lx1,1:ly1,1:lz1,1:lelv),vy(1:lx1,1:ly1,1:lz1,1:lelv),vz(1:lx1,1:ly1,1:lz1,1:lelv)) >>> i would like to calculate the energy spectrum, this implies FFT >>> transformation on regular arrays >>> vx(1:n,1:n,1:n),vy(1:n,1:n,1:n),vz(1:n,1:n,1:n) (need >>> deltax=deltay=deltaz=cst). >>> On the emailing-list it has been said : >>> "We do have off-line serial routines >>> that can transfer data from an nelx x nely x nelz array of Nth-order >>> elements to an nxnxn array - this allows for analysis by FFTs etc" >>> >>> >>> Can you please tell me more about this ? What are these routines ?? >>> B.regards >>> Can >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > The solution (i think its more an hack than a real solution) i found, was to create an hpts.in file with the coordinates of every points of the regular mesh i wrote the fallowing routine for this : (My domain is a cube of length 2pi*2pi*2pi, you can surely adapt the fallowing routine for other simple geometries) subroutine generehptsin(ndummy,ldummy,uprn) implicit none c ndummy = number of grid points per dimension c ldummy = length in one dimension c uprn = dummy variable for output c you need nx=ny=nz and deltax=deltay=deltaz c For fft analysis you have to ensure that ndummy**3 is equal to 2^n (ex : 128 points = 2^7) integer ndummy,i,j,k,uprn real*8 ldummy,deltax, & x(0:ndummy-1),y(0:ndummy-1),z(0:ndummy-1) open(uprn,file='hpts.in',status='unknown') c compute deltax deltax=0 deltax=ldummy/(ndummy-1) c fil vectors : x,y,z x=0 y=0 z=0 do i=0, ndummy-1 x(i)=i*deltax y(i)=i*deltax z(i)=i*deltax enddo write(uprn,*)ndummy*ndummy*ndummy ! total number of grid points in the first line do k=0, ndummy-1 do j=0, ndummy-1 do i=0, ndummy-1 write(uprn,'(1p20E15.7)')x(i),y(j),z(k) enddo enddo enddo close(uprn) return end Then modify the hpts() subroutine slightly (just to be able to access to the "fieldout" matrix when you call hpts() in userchk()) Eg : modify "subroutine hpts()" to "subroutine hpts(fieldout)" (it's the first line of hpts routine in postpro.f) You will also probably want to comment the fallowing lines to avoid hpts to write in the hpts.out. ! write interpolation results to hpts.out c if(nid.eq.0) then c do ip = 1,npoints c write(50,'(1p20E15.7)') time, c & (fieldout(i,ip), i=1,nflds) c enddo c endif c if(nid.eq.0) write(6,*) 'done :: dump history points' Then, to express the velocity field in a v(i,j,k) layout, i wrote the fallowing routine : subroutine reformatfield(nfldm,fieldout, & ndummy,vxrdummy,vyrdummy,vzrdummy) c You have to call this in userchk routine without changing the first two input arguments implicit none c fieldout is now the output matrix of the hpts routine, we need this matrix c nfldm is the number of field you resolve c ndummy is the number of grid points per dimension c vxrdummx is the x component of the velocity field in a regular grid c vxrdummy is the y component of the velocity field in a regular grid c vxrdummz is the z component of the velocity field in a regular grid integer ndummy,i,j,k,z,nfldm real field1(ndummy*ndummy*ndummy), & field2(ndummy*ndummy*ndummy), & field3(ndummy*ndummy*ndummy), & fieldout(nfldm,ndummy*ndummy*ndummy), & vxrdummy(1:ndummy,1:ndummy,1:ndummy), & vyrdummy(1:ndummy,1:ndummy,1:ndummy), & vzrdummy(1:ndummy,1:ndummy,1:ndummy) do i=1,ndummy*ndummy*ndummy field1(i)=fieldout(1,i) ! vx field2(i)=fieldout(2,i) ! vy field3(i)=fieldout(3,i) ! vz enddo z=0 do k=1,ndummy do j=1,ndummy do i=1,ndummy vxrdummy(i,j,k)=field1(i+z) vyrdummy(i,j,k)=field2(i+z) vzrdummy(i,j,k)=field3(i+z) enddo z=z+ndummy enddo enddo return end This routine will output a velocity field expressed in a regular grid with v=v(i,j,k) layout. You can, from there, use any FFT routine for fft analysis. I used the "four1" routine that you can find on the "numerical recipies" tome Sorry for my poor english and hope that will help For your question i think nrg=nelx*lx1 (1D) because, the number of grid points on a 1D gll mesh is nelx * lx1 with lx1=N+1 B.regards From nek5000-users at lists.mcs.anl.gov Sat May 5 07:10:31 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 05 May 2012 14:10:31 +0200 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: <4FA3D0C3.4090409@onera.fr> References: <4F7DC3FB.3020605@onera.fr> <4FA3D0C3.4090409@onera.fr> Message-ID: <20120505141031.11244rgy0e9djph3@www.mech.kth.se> Hi All, In regards to the discussion on this issue. I have been lately interpolating from the SEM nek5000 grid onto an equidistant grid and performing FFT to obtain two-point correlations and energy spectrum for pipe flow simulations. During the simulation, I outpost fields from nek5000 containing the velocity and pressure. After the simulation ends, I would use a simplified version of nek5000 where I loop on these files and interpolate in parallel. Upon reading each file, I interpolate to a cylindrical mesh that is equidistant in the axial and azimuthal direction, and non-uniform in the radial direction. Since my grid is huge, I do the interpolation in tubes. I loop in the radial direction, and for each radial position, I generate the equidistant (z,theta)-grid then interpolate the velocities and pressure etc.. onto that grid using subroutines used in hpts. Each data in a tube is sent to a separate processors where I perform FFT analysis. The FFT analysis is performed using FFT subroutines included in a .f file which I added to nek5000. This procedure continues until I finish looping on all my files. Best George Quoting nek5000-users at lists.mcs.anl.gov: > Le 04/05/2012 13:55, nek5000-users at lists.mcs.anl.gov a ?crit : >> Hi Neks, >> another point I'm (even more) interested in is: how do you do your >> FFT analysis? >> I guess in a first step the grid is mapped onto a regular grid >> (ifreguo = .true.) and in a second step the FFT is computed at that >> grid. >> Then the question arises: What is a good choice for "nrg" (with nrg as >> the dimension of regular grid (nrg**ndim)...)? nrg=lx1 or lx1-1? >> Regards >> Jan >> >> 2012/4/13 Jan Frielinghausen: >>> Hi Neks, Hi Can, >>> I too would be very interested in getting more information about >>> these routines. >>> regards >>> Jan >>> >>> Am 5. April 2012 18:10 schrieb: >>>> Hi neks ! >>>> >>>> For a given velocity field >>>> (vx(1:lx1,1:ly1,1:lz1,1:lelv),vy(1:lx1,1:ly1,1:lz1,1:lelv),vz(1:lx1,1:ly1,1:lz1,1:lelv)) >>>> i would like to calculate the energy spectrum, this implies FFT >>>> transformation on regular arrays >>>> vx(1:n,1:n,1:n),vy(1:n,1:n,1:n),vz(1:n,1:n,1:n) (need >>>> deltax=deltay=deltaz=cst). >>>> On the emailing-list it has been said : >>>> "We do have off-line serial routines >>>> that can transfer data from an nelx x nely x nelz array of Nth-order >>>> elements to an nxnxn array - this allows for analysis by FFTs etc" >>>> >>>> >>>> Can you please tell me more about this ? What are these routines ?? >>>> B.regards >>>> Can >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > The solution (i think its more an hack than a real solution) i > found, was to create an hpts.in file with the coordinates of every > points of the regular mesh > i wrote the fallowing routine for this : > (My domain is a cube of length 2pi*2pi*2pi, you can surely adapt the > fallowing routine for other simple geometries) > > subroutine generehptsin(ndummy,ldummy,uprn) > implicit none > c ndummy = number of grid points per dimension > c ldummy = length in one dimension > c uprn = dummy variable for output > c you need nx=ny=nz and deltax=deltay=deltaz > c For fft analysis you have to ensure that ndummy**3 is equal to > 2^n (ex : 128 points = 2^7) > integer ndummy,i,j,k,uprn > real*8 ldummy,deltax, > & x(0:ndummy-1),y(0:ndummy-1),z(0:ndummy-1) > open(uprn,file='hpts.in',status='unknown') > c compute deltax > deltax=0 > deltax=ldummy/(ndummy-1) > c fil vectors : x,y,z > x=0 > y=0 > z=0 > do i=0, ndummy-1 > x(i)=i*deltax > y(i)=i*deltax > z(i)=i*deltax > enddo > write(uprn,*)ndummy*ndummy*ndummy ! total number of grid > points in the first line > do k=0, ndummy-1 > do j=0, ndummy-1 > do i=0, ndummy-1 > write(uprn,'(1p20E15.7)')x(i),y(j),z(k) > enddo > enddo > enddo > close(uprn) > return > end > > Then modify the hpts() subroutine slightly (just to be able to > access to the "fieldout" matrix when you call hpts() in userchk()) > Eg : modify "subroutine hpts()" to "subroutine hpts(fieldout)" > (it's the first line of hpts routine in postpro.f) > You will also probably want to comment the fallowing lines to avoid > hpts to write in the hpts.out. > > ! write interpolation results to hpts.out > c if(nid.eq.0) then > c do ip = 1,npoints > c write(50,'(1p20E15.7)') time, > c & (fieldout(i,ip), i=1,nflds) > c enddo > c endif > c if(nid.eq.0) write(6,*) 'done :: dump history points' > > > Then, to express the velocity field in a v(i,j,k) layout, i wrote > the fallowing routine : > > subroutine reformatfield(nfldm,fieldout, > & ndummy,vxrdummy,vyrdummy,vzrdummy) > > c You have to call this in userchk routine without changing the > first two input arguments > implicit none > c fieldout is now the output matrix of the hpts routine, we need this matrix > c nfldm is the number of field you resolve > c ndummy is the number of grid points per dimension > c vxrdummx is the x component of the velocity field in a regular grid > c vxrdummy is the y component of the velocity field in a regular grid > c vxrdummz is the z component of the velocity field in a regular grid > integer ndummy,i,j,k,z,nfldm > real field1(ndummy*ndummy*ndummy), > & field2(ndummy*ndummy*ndummy), > & field3(ndummy*ndummy*ndummy), > & fieldout(nfldm,ndummy*ndummy*ndummy), > & vxrdummy(1:ndummy,1:ndummy,1:ndummy), > & vyrdummy(1:ndummy,1:ndummy,1:ndummy), > & vzrdummy(1:ndummy,1:ndummy,1:ndummy) > > > > do i=1,ndummy*ndummy*ndummy > field1(i)=fieldout(1,i) ! vx > field2(i)=fieldout(2,i) ! vy > field3(i)=fieldout(3,i) ! vz > enddo > > z=0 > do k=1,ndummy > do j=1,ndummy > do i=1,ndummy > vxrdummy(i,j,k)=field1(i+z) > vyrdummy(i,j,k)=field2(i+z) > vzrdummy(i,j,k)=field3(i+z) > enddo > z=z+ndummy > enddo > enddo > return > end > > This routine will output a velocity field expressed in a regular > grid with v=v(i,j,k) layout. You can, from there, use any FFT > routine for fft analysis. > I used the "four1" routine that you can find on the "numerical recipies" tome > Sorry for my poor english and hope that will help > For your question i think nrg=nelx*lx1 (1D) because, the number of > grid points on a 1D gll mesh is nelx * lx1 with lx1=N+1 > B.regards > > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nek5000-users at lists.mcs.anl.gov Mon May 7 03:36:37 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 07 May 2012 10:36:37 +0200 Subject: [Nek5000-users] error in n2to3 Message-ID: <1336379797.10903.8.camel@skagsnebb.mech.kth.se> Hi Just to report. There is an integer variable mhd reading real number in the newest version of n2to3.f (line 286, subroutine rea23) and causing error message. Regards Adam From nek5000-users at lists.mcs.anl.gov Mon May 7 10:02:24 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 7 May 2012 10:02:24 -0500 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: <4FA3D0C3.4090409@onera.fr> References: <4F7DC3FB.3020605@onera.fr> <4FA3D0C3.4090409@onera.fr> Message-ID: Hi, I have added an interpolation tool to the repo, int_tp, in nek5_svn/trunk/tools/int_tp There is also a README in that directory with instructions on the details of using the tool. (Note - int_tp should be compiled as any standard nek tool in the trunk/tools/ directory with "maketools int_tp" or "maketools all") Let me know if you encounter complications. Thanks, Katie On Fri, May 4, 2012 at 7:51 AM, wrote: > Le 04/05/2012 13:55, nek5000-users at lists.mcs.anl.**gova ?crit : > > Hi Neks, >> another point I'm (even more) interested in is: how do you do your FFT >> analysis? >> I guess in a first step the grid is mapped onto a regular grid >> (ifreguo = .true.) and in a second step the FFT is computed at that >> grid. >> Then the question arises: What is a good choice for "nrg" (with nrg as >> the dimension of regular grid (nrg**ndim)...)? nrg=lx1 or lx1-1? >> Regards >> Jan >> >> 2012/4/13 Jan Frielinghausen >> >**: >> >>> Hi Neks, Hi Can, >>> I too would be very interested in getting more information about these >>> routines. >>> regards >>> Jan >>> >>> Am 5. April 2012 18:10 schrieb >>> >: >>> >>>> Hi neks ! >>>> >>>> For a given velocity field >>>> (vx(1:lx1,1:ly1,1:lz1,1:lelv),**vy(1:lx1,1:ly1,1:lz1,1:lelv),** >>>> vz(1:lx1,1:ly1,1:lz1,1:lelv)) >>>> i would like to calculate the energy spectrum, this implies FFT >>>> transformation on regular arrays >>>> vx(1:n,1:n,1:n),vy(1:n,1:n,1:**n),vz(1:n,1:n,1:n) (need >>>> deltax=deltay=deltaz=cst). >>>> On the emailing-list it has been said : >>>> "We do have off-line serial routines >>>> that can transfer data from an nelx x nely x nelz array of Nth-order >>>> elements to an nxnxn array - this allows for analysis by FFTs etc" >>>> >>>> >>>> Can you please tell me more about this ? What are these routines ?? >>>> B.regards >>>> Can >>>> >>>> ______________________________**_________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.**gov >>>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >>>> >>> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> >> The solution (i think its more an hack than a real solution) i found, > was to create an hpts.in file with the coordinates of every points of the > regular mesh > i wrote the fallowing routine for this : > (My domain is a cube of length 2pi*2pi*2pi, you can surely adapt the > fallowing routine for other simple geometries) > > subroutine generehptsin(ndummy,ldummy,**uprn) > implicit none > c ndummy = number of grid points per dimension > c ldummy = length in one dimension > c uprn = dummy variable for output > c you need nx=ny=nz and deltax=deltay=deltaz > c For fft analysis you have to ensure that ndummy**3 is equal to 2^n (ex > : 128 points = 2^7) > integer ndummy,i,j,k,uprn > real*8 ldummy,deltax, > & x(0:ndummy-1),y(0:ndummy-1),z(**0:ndummy-1) > open(uprn,file='hpts.in',**status='unknown') > c compute deltax > deltax=0 > deltax=ldummy/(ndummy-1) > c fil vectors : x,y,z > x=0 > y=0 > z=0 > do i=0, ndummy-1 > x(i)=i*deltax > y(i)=i*deltax > z(i)=i*deltax > enddo > write(uprn,*)ndummy*ndummy***ndummy ! total number of grid points > in the first line > do k=0, ndummy-1 > do j=0, ndummy-1 > do i=0, ndummy-1 > write(uprn,'(1p20E15.7)')x(i),**y(j),z(k) > enddo > enddo > enddo > close(uprn) > return > end > > Then modify the hpts() subroutine slightly (just to be able to access to > the "fieldout" matrix when you call hpts() in userchk()) > Eg : modify "subroutine hpts()" to "subroutine hpts(fieldout)" (it's the > first line of hpts routine in postpro.f) > You will also probably want to comment the fallowing lines to avoid hpts > to write in the hpts.out. > > ! write interpolation results to hpts.out > c if(nid.eq.0) then > c do ip = 1,npoints > c write(50,'(1p20E15.7)') time, > c & (fieldout(i,ip), i=1,nflds) > c enddo > c endif > c if(nid.eq.0) write(6,*) 'done :: dump history points' > > > Then, to express the velocity field in a v(i,j,k) layout, i wrote the > fallowing routine : > > subroutine reformatfield(nfldm,fieldout, > & ndummy,vxrdummy,vyrdummy,**vzrdummy) > > c You have to call this in userchk routine without changing the first two > input arguments > implicit none > c fieldout is now the output matrix of the hpts routine, we need this > matrix > c nfldm is the number of field you resolve > c ndummy is the number of grid points per dimension > c vxrdummx is the x component of the velocity field in a regular grid > c vxrdummy is the y component of the velocity field in a regular grid > c vxrdummz is the z component of the velocity field in a regular grid > integer ndummy,i,j,k,z,nfldm > real field1(ndummy*ndummy*ndummy), > & field2(ndummy*ndummy*ndummy), > & field3(ndummy*ndummy*ndummy), > & fieldout(nfldm,ndummy*ndummy***ndummy), > & vxrdummy(1:ndummy,1:ndummy,1:**ndummy), > & vyrdummy(1:ndummy,1:ndummy,1:**ndummy), > & vzrdummy(1:ndummy,1:ndummy,1:**ndummy) > > > > do i=1,ndummy*ndummy*ndummy > field1(i)=fieldout(1,i) ! vx > field2(i)=fieldout(2,i) ! vy > field3(i)=fieldout(3,i) ! vz > enddo > > z=0 > do k=1,ndummy > do j=1,ndummy > do i=1,ndummy > vxrdummy(i,j,k)=field1(i+z) > vyrdummy(i,j,k)=field2(i+z) > vzrdummy(i,j,k)=field3(i+z) > enddo > z=z+ndummy > enddo > enddo > return > end > > This routine will output a velocity field expressed in a regular grid with > v=v(i,j,k) layout. You can, from there, use any FFT routine for fft > analysis. > I used the "four1" routine that you can find on the "numerical recipies" > tome > Sorry for my poor english and hope that will help > For your question i think nrg=nelx*lx1 (1D) because, the number of grid > points on a 1D gll mesh is nelx * lx1 with lx1=N+1 > B.regards > > > > > ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 7 11:50:17 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 7 May 2012 11:50:17 -0500 Subject: [Nek5000-users] error in n2to3 In-Reply-To: <1336379797.10903.8.camel@skagsnebb.mech.kth.se> References: <1336379797.10903.8.camel@skagsnebb.mech.kth.se> Message-ID: Hi Adam, Thanks. Can you send me the error message you are getting? (And what compiler you are using. Just for future reference.) Thanks, Katie Email: klheisey at gmail.com On Mon, May 7, 2012 at 3:36 AM, wrote: > Hi > > Just to report. There is an integer variable mhd reading real number in > the newest version of n2to3.f (line 286, subroutine rea23) and causing > error message. > Regards > > Adam > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed May 9 07:10:08 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 09 May 2012 14:10:08 +0200 Subject: [Nek5000-users] error in n2to3 In-Reply-To: References: <1336379797.10903.8.camel@skagsnebb.mech.kth.se> Message-ID: <1336565408.15767.5.camel@skagsnebb.mech.kth.se> Hi Katie It was gfortran and gcc and the error message: At line 286 of file n2to3.f Fortran runtime error: Bad integer for item 1 in list input I've solved problem declaring mhd as real. However, there seem to be more bugs, since I've got following email: > I found another bug in the n2to3 routine. When I'm choosing the option > to create the re2 and rea file at the same time, the code gives an > error while running. I don't know if it's specific to my case, so if > you have another case to try this on it would be interesting to know > if it also gives an error. In such a case, it might be good to report > this together with the other bug you found. However, I couldn't figure > out how this bug arises. (Although, this bug is not a problem since > the option to do this in 2 steps exist, n2to3 and then reatore2) regards Adam On Mon, 2012-05-07 at 11:50 -0500, nek5000-users at lists.mcs.anl.gov wrote: > Hi Adam, > > Thanks. Can you send me the error message you are getting? (And what > compiler you are using. Just for future reference.) > > Thanks, > Katie > Email: klheisey at gmail.com > > On Mon, May 7, 2012 at 3:36 AM, > wrote: > Hi > > Just to report. There is an integer variable mhd reading real > number in > the newest version of n2to3.f (line 286, subroutine rea23) and > causing > error message. > Regards > > Adam > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Wed May 9 11:24:19 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 9 May 2012 11:24:19 -0500 Subject: [Nek5000-users] error in n2to3 In-Reply-To: <1336565408.15767.5.camel@skagsnebb.mech.kth.se> References: <1336379797.10903.8.camel@skagsnebb.mech.kth.se> <1336565408.15767.5.camel@skagsnebb.mech.kth.se> Message-ID: Hi Adam, Can you send a tar file to me at klheisey at gmail.com with the case that is giving an error? The mhd bug has been fixed. Thanks katie On Wed, May 9, 2012 at 7:10 AM, wrote: > Hi Katie > > It was gfortran and gcc and the error message: > > At line 286 of file n2to3.f > Fortran runtime error: Bad integer for item 1 in list input > > I've solved problem declaring mhd as real. However, there seem to be > more bugs, since I've got following email: > > > I found another bug in the n2to3 routine. When I'm choosing the option > > to create the re2 and rea file at the same time, the code gives an > > error while running. I don't know if it's specific to my case, so if > > you have another case to try this on it would be interesting to know > > if it also gives an error. In such a case, it might be good to report > > this together with the other bug you found. However, I couldn't figure > > out how this bug arises. (Although, this bug is not a problem since > > the option to do this in 2 steps exist, n2to3 and then reatore2) > > regards > Adam > > > On Mon, 2012-05-07 at 11:50 -0500, nek5000-users at lists.mcs.anl.gov > wrote: > > Hi Adam, > > > > Thanks. Can you send me the error message you are getting? (And what > > compiler you are using. Just for future reference.) > > > > Thanks, > > Katie > > Email: klheisey at gmail.com > > > > On Mon, May 7, 2012 at 3:36 AM, > > wrote: > > Hi > > > > Just to report. There is an integer variable mhd reading real > > number in > > the newest version of n2to3.f (line 286, subroutine rea23) and > > causing > > error message. > > Regards > > > > Adam > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 11 12:47:27 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 11 May 2012 17:47:27 +0000 Subject: [Nek5000-users] Using CVODE with a vector of absolute tolerances Message-ID: Dear all, I am trying to solve a catalytic combustion problem with nek5000 and I am using CVODE to integrate the temperature and species equations. I was doing some tests with the tolerances and I wanted to try different absolute tolerances for the equations. In the nek folder I changed some parameters in CVODE: - IATOL = 2; - real cv_atol(15) Then in cv_init I assign a value to each component of the vector cv_atol. When fcvmalloc is called, I get the error message: [CVODE ERROR] CVodeMalloc abstol has a negative component(s) (illegal). If I debug the code, before and after the call to fcvmalloc the vector cv_atol is fine. Does anybody experienced something similar or has a suggestion about that? In which folder is the source code of CVODE? Thanks in advance for your answer. Regards, Andreas. From nek5000-users at lists.mcs.anl.gov Thu May 17 01:33:53 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 17 May 2012 12:03:53 +0530 Subject: [Nek5000-users] compilation error Message-ID: Dear Sir, Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) environment the error is: *Unable to detect compiler! - don't know how to promote datatype REAL to 8 bytes - don't know how to invoke the C pre-processor (CPP) before compilation Please edit the makefile and specify the requested compiler flags using the P variable.* ** *generating makefile ...* ** Plz help me in this regard -- *Vinaya Sivanandan* *Pune* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 17 03:35:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 17 May 2012 10:35:46 +0200 Subject: [Nek5000-users] Adjoint outflow boundary condition Message-ID: Hi Nek's, I'd like to use the adjoint linear solver. I have a problem concerning the outflow condition. Th proper boundary condition would be: (p-(1/Re)grad(u))*n=(U*n)*u where: -n is the normal -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 17 03:41:14 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 17 May 2012 10:41:14 +0200 Subject: [Nek5000-users] Adjoint outflow boundary condition In-Reply-To: References: Message-ID: Hi Nek's, I'd like to use the adjoint linear solver. I have a problem concerning the outflow condition. The proper boundary condition would be: (p-(1/Re)grad(u))*n=(U*n)*u where: -n is the normal - u is the adjoint velocity vector - U is the base flow velocity vector - p is the adjoint pressure -Re Reynolds number How can I apply this condition on the outflow? Best Regards, Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu May 17 07:21:58 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 17 May 2012 07:21:58 -0500 (CDT) Subject: [Nek5000-users] compilation error In-Reply-To: References: Message-ID: Are you using gfortran and gcc? I would suggest setting these as your compiler in makenek and also settig IFMPI to false in the makenek script. Then, makenek clean before resuming your attempt to compile. Best regards, Paul On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Sir, > > Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) > environment > the error is: > *Unable to detect compiler! > - don't know how to promote datatype REAL to 8 bytes > - don't know how to invoke the C pre-processor (CPP) before > compilation > Please edit the makefile and specify the requested compiler flags > using the P variable.* > ** > *generating makefile ...* > ** > Plz help me in this regard > -- > *Vinaya Sivanandan* > *Pune* > ** > From nek5000-users at lists.mcs.anl.gov Thu May 17 07:29:12 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 17 May 2012 07:29:12 -0500 (CDT) Subject: [Nek5000-users] Adjoint outflow boundary condition In-Reply-To: References: Message-ID: Hi Andrea, We can certainly add an inhomogeneity to the natural boundary condition of the Stokes problem (which I believe is what you propose below). I wonder, however, if the notion of adjoints with outflow boundary condition is even stable, since you have information coming from a region that is normally an energy sink. Don't you have to change the BCs to make this work? Think of the convection-diffusion equation with outflow. What would be the proper formulation of the adjoint problem? In the forward case, the outflow boundary condition yields negative eigenvalues, corresponding to energy leaving the domain. In the adjoint, where the flow is reversed, this would imply positive eigenvalues and growth of disturbances coming from the outflow boundary. Of course, I could be completely wrong about this and would welcome any comments from someone more knowledgeable about the adjoint problem. In particular, is there a convection-diffusion example we could consider as a starting point? Paul On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > > I'd like to use the adjoint linear solver. I have a problem concerning the > outflow condition. The proper boundary condition would be: > > (p-(1/Re)grad(u))*n=(U*n)*u > > where: -n is the normal > - u is the adjoint velocity vector > - U is the base flow velocity vector > - p is the adjoint pressure > -Re Reynolds number > > How can I apply this condition on the outflow? > > Best Regards, > > Andrea > From nek5000-users at lists.mcs.anl.gov Fri May 18 01:03:45 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 11:33:45 +0530 Subject: [Nek5000-users] compilation error In-Reply-To: References: Message-ID: Dear Sir, Thank you for your kind response. I was not using using gfortran but using gcc( 3.4.6 version ) and g77. After using gfortran(GNU Fortran 95 (GCC) 4.1.0 and gcc( 3.4.6 version ). I could compile makenek but with warnings.Below are the warnings which I get while compiling. */home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/errmem.c: In function `fail': /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/errmem.c:15: warning: `noreturn' function does return gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/crystal.c -o obj/jl_crystal.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts.c -o obj/jl2_findpts.o In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9584* * IF(DFLAG) 50,10,30 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9623* * IF(DFLAG)120,80,100 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9764* * GO TO IGO,(120,150,180,210) 1 Warning: Obsolete: Assigned GOTO statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9770* * ASSIGN 120 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9782* * ASSIGN 150 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9795* * ASSIGN 180 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9806* * ASSIGN 210 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9815* * IF(DFLAG)250,230,240 1 Warning: Obsolete: arithmetic IF statement at (1) gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_local.c -o obj/jl2_findpts_local.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/obbox.c -o obj/jl2_obbox.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/poly.c -o obj/jl2_poly.o In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17100* * IF(SFLAG) 50,10,30 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17139* * IF(SFLAG)120,80,100 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17277* * GO TO IGO,(120,150,180,210) 1 Warning: Obsolete: Assigned GOTO statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17283* * ASSIGN 120 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17295* * ASSIGN 150 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17308* * ASSIGN 180 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17319* * ASSIGN 210 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17328* * IF(SFLAG)250,230,240 1 Warning: Obsolete: arithmetic IF statement at (1) gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/lob_bnd.c -o obj/jl2_lob_bnd.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_el_3.c -o obj/jl2_findpts_el_3.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_el_2.c -o obj/jl2_findpts_el_2.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/sparse_cholesky.c -o obj/jl2_sparse_cholesky.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/xxt.c -o obj/jl2_xxt.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/fcrs.c -o obj/jl2_fcrs.o gfortran -c -O2 -fcray-pointer -fdefault-real-8 -x f77-cpp-input -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -I/home/secg/cfd/vinayas/nek5000/testnek/rayleigh1 -I/home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek -I./ /home/secg/cfd/vinayas/nek5000/testnek/rayleigh1/rayleigh.f -o obj/rayleigh.o gfortran -o nek5000 obj/rayleigh.o obj/drive.o obj/drive1.o obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o ############################################################# # Compilation successful! # ############################################################# text data bss dec hex filename 2073815 2992 24176824 26253631 190993f nek5000* Thanks and regards Vinaya On Thu, May 17, 2012 at 5:51 PM, wrote: > > Are you using gfortran and gcc? > > I would suggest setting these as your compiler in makenek > and also settig IFMPI to false in the makenek script. > > Then, > > makenek clean > > before resuming your attempt to compile. > > Best regards, > > Paul > > > > > On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.**govwrote: > > Dear Sir, >> >> Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) >> environment >> the error is: >> *Unable to detect compiler! >> >> - don't know how to promote datatype REAL to 8 bytes >> - don't know how to invoke the C pre-processor (CPP) before >> compilation >> Please edit the makefile and specify the requested compiler flags >> using the P variable.* >> ** >> *generating makefile ...* >> ** >> >> Plz help me in this regard >> -- >> *Vinaya Sivanandan* >> *Pune* >> ** >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -- *Vinaya Sivanandan* *Pune* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 18 01:37:04 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 01:37:04 -0500 (CDT) Subject: [Nek5000-users] compilation error In-Reply-To: References: Message-ID: Hi, Warnings are fairly standard. Is it able to run? Paul On Fri, 18 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Sir, > Thank you for your kind response. > > > I was not using using gfortran but using gcc( 3.4.6 version ) and g77. > After using gfortran(GNU Fortran 95 (GCC) 4.1.0 and gcc( 3.4.6 version ). I > could compile makenek but with warnings.Below are the warnings which I get > while compiling. > > > > > */home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/errmem.c: In function > `fail': > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/errmem.c:15: warning: > `noreturn' function does return > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/crystal.c -o > obj/jl_crystal.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts.c -o > obj/jl2_findpts.o > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9584* > * IF(DFLAG) 50,10,30 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9623* > * IF(DFLAG)120,80,100 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9764* > * GO TO IGO,(120,150,180,210) > 1 > Warning: Obsolete: Assigned GOTO statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9770* > * ASSIGN 120 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9782* > * ASSIGN 150 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9795* > * ASSIGN 180 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9806* > * ASSIGN 210 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:9815* > * IF(DFLAG)250,230,240 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_local.c > -o obj/jl2_findpts_local.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/obbox.c -o > obj/jl2_obbox.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/poly.c -o > obj/jl2_poly.o > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17100* > * IF(SFLAG) 50,10,30 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17139* > * IF(SFLAG)120,80,100 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17277* > * GO TO IGO,(120,150,180,210) > 1 > Warning: Obsolete: Assigned GOTO statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17283* > * ASSIGN 120 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17295* > * ASSIGN 150 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17308* > * ASSIGN 180 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17319* > * ASSIGN 210 TO IGO > 1 > Warning: Obsolete: ASSIGN statement at (1) > In file > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/3rd_party/blas.f:17328* > * IF(SFLAG)250,230,240 > 1 > Warning: Obsolete: arithmetic IF statement at (1) > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/lob_bnd.c -o > obj/jl2_lob_bnd.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_el_3.c > -o obj/jl2_findpts_el_3.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/findpts_el_2.c > -o obj/jl2_findpts_el_2.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/sparse_cholesky.c > -o obj/jl2_sparse_cholesky.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/xxt.c -o > obj/jl2_xxt.o > gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -DPREFIX=jl_ > /home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek/jl/../jl2/fcrs.c -o > obj/jl2_fcrs.o > gfortran -c -O2 -fcray-pointer -fdefault-real-8 -x f77-cpp-input > -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG > -I/home/secg/cfd/vinayas/nek5000/testnek/rayleigh1 > -I/home/secg/cfd/vinayas/nek5000/nek5_svn/trunk/nek -I./ > /home/secg/cfd/vinayas/nek5000/testnek/rayleigh1/rayleigh.f -o > obj/rayleigh.o > gfortran -o nek5000 obj/rayleigh.o obj/drive.o obj/drive1.o obj/drive2.o > obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o > obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o > obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o > obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o > obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o > obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o > obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o > obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o > obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o > obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o > obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o > obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o > obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o > obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o > obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o > obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o > obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o > obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o > obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o > obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o > ############################################################# > # Compilation successful! # > ############################################################# > text data bss dec hex filename > 2073815 2992 24176824 26253631 190993f nek5000* > > Thanks and regards > Vinaya > > On Thu, May 17, 2012 at 5:51 PM, wrote: > >> >> Are you using gfortran and gcc? >> >> I would suggest setting these as your compiler in makenek >> and also settig IFMPI to false in the makenek script. >> >> Then, >> >> makenek clean >> >> before resuming your attempt to compile. >> >> Best regards, >> >> Paul >> >> >> >> >> On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> Dear Sir, >>> >>> Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) >>> environment >>> the error is: >>> *Unable to detect compiler! >>> >>> - don't know how to promote datatype REAL to 8 bytes >>> - don't know how to invoke the C pre-processor (CPP) before >>> compilation >>> Please edit the makefile and specify the requested compiler flags >>> using the P variable.* >>> ** >>> *generating makefile ...* >>> ** >>> >>> Plz help me in this regard >>> -- >>> *Vinaya Sivanandan* >>> *Pune* >>> ** >>> >>> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> > > > > -- > *Vinaya Sivanandan* > *Pune* > ** > From nek5000-users at lists.mcs.anl.gov Fri May 18 02:22:38 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 12:52:38 +0530 Subject: [Nek5000-users] compilation error In-Reply-To: References: Message-ID: Dear Sir, Yes, it is able to run. Thanks a lot. with regards, Vinaya On Fri, May 18, 2012 at 12:07 PM, wrote: > > Hi, > > Warnings are fairly standard. > > Is it able to run? > > Paul > > > On Fri, 18 May 2012, nek5000-users at lists.mcs.anl.**govwrote: > > Dear Sir, >> >> Thank you for your kind response. >> >> >> I was not using using gfortran but using gcc( 3.4.6 version ) and g77. >> After using gfortran(GNU Fortran 95 (GCC) 4.1.0 and gcc( 3.4.6 version ). >> I >> could compile makenek but with warnings.Below are the warnings which I >> get >> while compiling. >> >> >> >> >> */home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**errmem.c: In >> function >> >> `fail': >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**errmem.c:15: >> warning: >> `noreturn' function does return >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**crystal.c -o >> obj/jl_crystal.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/findpts.c >> -o >> obj/jl2_findpts.o >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9584* >> * IF(DFLAG) 50,10,30 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9623* >> * IF(DFLAG)120,80,100 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9764* >> * GO TO IGO,(120,150,180,210) >> >> 1 >> Warning: Obsolete: Assigned GOTO statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9770* >> * ASSIGN 120 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9782* >> * ASSIGN 150 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9795* >> * ASSIGN 180 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9806* >> * ASSIGN 210 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:9815* >> * IF(DFLAG)250,230,240 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >> ../jl2/findpts_local.c >> -o obj/jl2_findpts_local.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/obbox.c >> -o >> obj/jl2_obbox.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/poly.c -o >> obj/jl2_poly.o >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17100* >> * IF(SFLAG) 50,10,30 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17139* >> * IF(SFLAG)120,80,100 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17277* >> * GO TO IGO,(120,150,180,210) >> >> 1 >> Warning: Obsolete: Assigned GOTO statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17283* >> * ASSIGN 120 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17295* >> * ASSIGN 150 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17308* >> * ASSIGN 180 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17319* >> * ASSIGN 210 TO IGO >> >> 1 >> Warning: Obsolete: ASSIGN statement at (1) >> In file >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >> 3rd_party/blas.f:17328* >> * IF(SFLAG)250,230,240 >> >> 1 >> Warning: Obsolete: arithmetic IF statement at (1) >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/lob_bnd.c >> -o >> obj/jl2_lob_bnd.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >> ../jl2/findpts_el_3.c >> -o obj/jl2_findpts_el_3.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >> ../jl2/findpts_el_2.c >> -o obj/jl2_findpts_el_2.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >> ../jl2/sparse_cholesky.c >> -o obj/jl2_sparse_cholesky.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/xxt.c -o >> obj/jl2_xxt.o >> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -DPREFIX=jl_ >> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/fcrs.c -o >> obj/jl2_fcrs.o >> gfortran -c -O2 -fcray-pointer -fdefault-real-8 -x f77-cpp-input >> -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >> -I/home/secg/cfd/vinayas/**nek5000/testnek/rayleigh1 >> -I/home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek -I./ >> /home/secg/cfd/vinayas/**nek5000/testnek/rayleigh1/**rayleigh.f -o >> obj/rayleigh.o >> gfortran -o nek5000 obj/rayleigh.o obj/drive.o obj/drive1.o obj/drive2.o >> obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o >> obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o >> obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o >> obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o >> obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o >> obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o >> obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o >> obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o >> obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o >> obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o >> obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o >> obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o >> obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o >> obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o >> obj/jl2_sarray_sort.o >> obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o >> obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o >> obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o >> obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o >> obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o >> obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o >> ##############################**##############################**# >> # Compilation successful! # >> ##############################**##############################**# >> text data bss dec hex filename >> 2073815 2992 24176824 26253631 190993f nek5000* >> >> >> Thanks and regards >> Vinaya >> >> On Thu, May 17, 2012 at 5:51 PM, > >> wrote: >> >> >>> Are you using gfortran and gcc? >>> >>> I would suggest setting these as your compiler in makenek >>> and also settig IFMPI to false in the makenek script. >>> >>> Then, >>> >>> makenek clean >>> >>> before resuming your attempt to compile. >>> >>> Best regards, >>> >>> Paul >>> >>> >>> >>> >>> On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.****gov< >>> nek5000-users at lists.mcs.**anl.gov >>> >wrote: >>> >>> Dear Sir, >>> >>>> >>>> Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) >>>> environment >>>> the error is: >>>> *Unable to detect compiler! >>>> >>>> - don't know how to promote datatype REAL to 8 bytes >>>> - don't know how to invoke the C pre-processor (CPP) before >>>> compilation >>>> Please edit the makefile and specify the requested compiler flags >>>> using the P variable.* >>>> ** >>>> *generating makefile ...* >>>> ** >>>> >>>> Plz help me in this regard >>>> -- >>>> *Vinaya Sivanandan* >>>> *Pune* >>>> ** >>>> >>>> ______________________________****_________________ >>>> >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.****gov >>> > >>> https://lists.mcs.anl.gov/****mailman/listinfo/nek5000-users >>> ** >>> **> >>> >>> >> >> >> -- >> *Vinaya Sivanandan* >> *Pune* >> ** >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -- *Vinaya Sivanandan* *Pune* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 18 03:38:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 10:38:46 +0200 Subject: [Nek5000-users] Adjoint outflow boundary condition Message-ID: Hi Paul, thank you for your help. The boundary conditions for the adjoint problem are chosen so as to nullify the boundary terms obtained during the derivation of the linearized NS adjoint equation. An exhaustive description of the derivation procedure for our case could be found for example on "Marquet et. al., Sensitivity analysis and passive control of cylinder flow, JFM 2008". Just to be sure, what kind of outflow condition is applied in NEK? I assumed that it is the traction free, maybe I am wrong. However, I think I solve my issue by imposing a different boundary condition, which is reasonable for the adjoint field that I expect. Best Regards, Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 18 03:44:03 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 14:14:03 +0530 Subject: [Nek5000-users] compilation error In-Reply-To: References: Message-ID: Dear Sir, As in my previous mail I had told that Iam able to run, but the run was not successful. ERROR: Cannot open SESSION.NAME! ierr= 1 Plz help in this regard. with regards, On Fri, May 18, 2012 at 12:52 PM, vinaya sivanandan < vinaya.sivanandan at gmail.com> wrote: > Dear Sir, > Yes, it is able to run. > Thanks a lot. > > with regards, > Vinaya > > > > On Fri, May 18, 2012 at 12:07 PM, wrote: > >> >> Hi, >> >> Warnings are fairly standard. >> >> Is it able to run? >> >> Paul >> >> >> On Fri, 18 May 2012, nek5000-users at lists.mcs.anl.**govwrote: >> >> Dear Sir, >>> >>> Thank you for your kind response. >>> >>> >>> I was not using using gfortran but using gcc( 3.4.6 version ) and g77. >>> After using gfortran(GNU Fortran 95 (GCC) 4.1.0 and gcc( 3.4.6 version >>> ). I >>> could compile makenek but with warnings.Below are the warnings which I >>> get >>> while compiling. >>> >>> >>> >>> >>> */home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**errmem.c: In >>> function >>> >>> `fail': >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**errmem.c:15: >>> warning: >>> `noreturn' function does return >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**crystal.c -o >>> obj/jl_crystal.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/findpts.c >>> -o >>> obj/jl2_findpts.o >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9584* >>> * IF(DFLAG) 50,10,30 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9623* >>> * IF(DFLAG)120,80,100 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9764* >>> * GO TO IGO,(120,150,180,210) >>> >>> 1 >>> Warning: Obsolete: Assigned GOTO statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9770* >>> * ASSIGN 120 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9782* >>> * ASSIGN 150 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9795* >>> * ASSIGN 180 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9806* >>> * ASSIGN 210 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:9815* >>> * IF(DFLAG)250,230,240 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >>> ../jl2/findpts_local.c >>> -o obj/jl2_findpts_local.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/obbox.c >>> -o >>> obj/jl2_obbox.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/poly.c >>> -o >>> obj/jl2_poly.o >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17100* >>> * IF(SFLAG) 50,10,30 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17139* >>> * IF(SFLAG)120,80,100 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17277* >>> * GO TO IGO,(120,150,180,210) >>> >>> 1 >>> Warning: Obsolete: Assigned GOTO statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17283* >>> * ASSIGN 120 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17295* >>> * ASSIGN 150 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17308* >>> * ASSIGN 180 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17319* >>> * ASSIGN 210 TO IGO >>> >>> 1 >>> Warning: Obsolete: ASSIGN statement at (1) >>> In file >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/** >>> 3rd_party/blas.f:17328* >>> * IF(SFLAG)250,230,240 >>> >>> 1 >>> Warning: Obsolete: arithmetic IF statement at (1) >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/lob_bnd.c >>> -o >>> obj/jl2_lob_bnd.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >>> ../jl2/findpts_el_3.c >>> -o obj/jl2_findpts_el_3.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >>> ../jl2/findpts_el_2.c >>> -o obj/jl2_findpts_el_2.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/** >>> ../jl2/sparse_cholesky.c >>> -o obj/jl2_sparse_cholesky.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/xxt.c -o >>> obj/jl2_xxt.o >>> gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -DPREFIX=jl_ >>> /home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek/jl/**../jl2/fcrs.c >>> -o >>> obj/jl2_fcrs.o >>> gfortran -c -O2 -fcray-pointer -fdefault-real-8 -x f77-cpp-input >>> -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG >>> -I/home/secg/cfd/vinayas/**nek5000/testnek/rayleigh1 >>> -I/home/secg/cfd/vinayas/**nek5000/nek5_svn/trunk/nek -I./ >>> /home/secg/cfd/vinayas/**nek5000/testnek/rayleigh1/**rayleigh.f -o >>> obj/rayleigh.o >>> gfortran -o nek5000 obj/rayleigh.o obj/drive.o obj/drive1.o obj/drive2.o >>> obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o >>> obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o >>> obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o >>> obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o >>> obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o >>> obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o >>> obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o >>> obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o >>> obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o >>> obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o >>> obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o >>> obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o >>> obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o >>> obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o >>> obj/jl2_sarray_sort.o >>> obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o >>> obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o >>> obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o >>> obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o >>> obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o >>> obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o >>> ##############################**##############################**# >>> # Compilation successful! # >>> ##############################**##############################**# >>> text data bss dec hex filename >>> 2073815 2992 24176824 26253631 190993f nek5000* >>> >>> >>> Thanks and regards >>> Vinaya >>> >>> On Thu, May 17, 2012 at 5:51 PM, > >>> wrote: >>> >>> >>>> Are you using gfortran and gcc? >>>> >>>> I would suggest setting these as your compiler in makenek >>>> and also settig IFMPI to false in the makenek script. >>>> >>>> Then, >>>> >>>> makenek clean >>>> >>>> before resuming your attempt to compile. >>>> >>>> Best regards, >>>> >>>> Paul >>>> >>>> >>>> >>>> >>>> On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.****gov< >>>> nek5000-users at lists.mcs.**anl.gov >>>> >wrote: >>>> >>>> Dear Sir, >>>> >>>>> >>>>> Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) >>>>> environment >>>>> the error is: >>>>> *Unable to detect compiler! >>>>> >>>>> - don't know how to promote datatype REAL to 8 bytes >>>>> - don't know how to invoke the C pre-processor (CPP) before >>>>> compilation >>>>> Please edit the makefile and specify the requested compiler flags >>>>> using the P variable.* >>>>> ** >>>>> *generating makefile ...* >>>>> ** >>>>> >>>>> Plz help me in this regard >>>>> -- >>>>> *Vinaya Sivanandan* >>>>> *Pune* >>>>> ** >>>>> >>>>> ______________________________****_________________ >>>>> >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.****gov >>>> > >>>> https://lists.mcs.anl.gov/****mailman/listinfo/nek5000-users >>>> ** >>>> **> >>>> >>>> >>> >>> >>> -- >>> *Vinaya Sivanandan* >>> *Pune* >>> ** >>> >>> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> > > > > -- > *Vinaya Sivanandan* > *Pune* > ** > > -- *Vinaya Sivanandan* *Pune* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri May 18 06:58:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 18 May 2012 06:58:49 -0500 (CDT) Subject: [Nek5000-users] compilation error In-Reply-To: Message-ID: <1346985918.19422.1337342329321.JavaMail.root@zimbra-mb2.anl.gov> Hi Vinaya, You can run Nek5000 with scripts: http://nek5000.mcs.anl.gov/index.php/Scripts that create SESSION.NAME. Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Friday, May 18, 2012 3:44:03 AM Subject: Re: [Nek5000-users] compilation error Dear Sir, As in my previous mail I had told that Iam able to run, but the run was not successful. ERROR: Cannot open SESSION.NAME ! ierr= 1 Plz help in this regard. with regards, On Fri, May 18, 2012 at 12:52 PM, vinaya sivanandan < vinaya.sivanandan at gmail.com > wrote: Dear Sir, Yes, it is able to run. Thanks a lot. with regards, Vinaya On Fri, May 18, 2012 at 12:07 PM, < nek5000-users at lists.mcs.anl.gov > wrote: Hi, Warnings are fairly standard. Is it able to run? Paul On Fri, 18 May 2012, nek5000-users at lists.mcs.anl. gov wrote: Dear Sir, Thank you for your kind response. I was not using using gfortran but using gcc( 3.4.6 version ) and g77. After using gfortran(GNU Fortran 95 (GCC) 4.1.0 and gcc( 3.4.6 version ). I could compile makenek but with warnings.Below are the warnings which I get while compiling. */home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ errmem.c: In function `fail': /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ errmem.c:15: warning: `noreturn' function does return gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ crystal.c -o obj/jl_crystal.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/findpts.c -o obj/jl2_findpts.o In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9584* * IF(DFLAG) 50,10,30 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9623* * IF(DFLAG)120,80,100 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9764* * GO TO IGO,(120,150,180,210) 1 Warning: Obsolete: Assigned GOTO statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9770* * ASSIGN 120 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9782* * ASSIGN 150 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9795* * ASSIGN 180 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9806* * ASSIGN 210 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:9815* * IF(DFLAG)250,230,240 1 Warning: Obsolete: arithmetic IF statement at (1) gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/findpts_local.c -o obj/jl2_findpts_local.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/obbox.c -o obj/jl2_obbox.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/poly.c -o obj/jl2_poly.o In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17100* * IF(SFLAG) 50,10,30 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17139* * IF(SFLAG)120,80,100 1 Warning: Obsolete: arithmetic IF statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17277* * GO TO IGO,(120,150,180,210) 1 Warning: Obsolete: Assigned GOTO statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17283* * ASSIGN 120 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17295* * ASSIGN 150 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17308* * ASSIGN 180 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17319* * ASSIGN 210 TO IGO 1 Warning: Obsolete: ASSIGN statement at (1) In file /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/ 3rd_party/blas.f:17328* * IF(SFLAG)250,230,240 1 Warning: Obsolete: arithmetic IF statement at (1) gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/lob_bnd.c -o obj/jl2_lob_bnd.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/findpts_el_3.c -o obj/jl2_findpts_el_3.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/findpts_el_2.c -o obj/jl2_findpts_el_2.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/sparse_cholesky.c -o obj/jl2_sparse_cholesky.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/xxt.c -o obj/jl2_xxt.o gcc -c -O2 -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -DPREFIX=jl_ /home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek/jl/ ../jl2/fcrs.c -o obj/jl2_fcrs.o gfortran -c -O2 -fcray-pointer -fdefault-real-8 -x f77-cpp-input -DPTRSIZE8 -DLONGINT8 -DUNDERSCORE -DGLOBAL_LONG_LONG -I/home/secg/cfd/vinayas/ nek5000/testnek/rayleigh1 -I/home/secg/cfd/vinayas/ nek5000/nek5_svn/trunk/nek -I./ /home/secg/cfd/vinayas/ nek5000/testnek/rayleigh1/ rayleigh.f -o obj/rayleigh.o gfortran -o nek5000 obj/rayleigh.o obj/drive.o obj/drive1.o obj/drive2.o obj/plan4.o obj/bdry.o obj/coef.o obj/conduct.o obj/connect1.o obj/connect2.o obj/dssum.o obj/edgec.o obj/eigsolv.o obj/gauss.o obj/genxyz.o obj/navier1.o obj/makeq.o obj/navier0.o obj/navier2.o obj/navier3.o obj/navier4.o obj/prepost.o obj/speclib.o obj/map2.o obj/turb.o obj/mvmesh.o obj/ic.o obj/ssolv.o obj/planx.o obj/math.o obj/mxm_wrapper.o obj/hmholtz.o obj/gfdm_par.o obj/gfdm_op.o obj/gfdm_solve.o obj/subs1.o obj/subs2.o obj/genbox.o obj/gmres.o obj/hsmg.o obj/convect.o obj/induct.o obj/perturb.o obj/navier5.o obj/navier6.o obj/navier7.o obj/navier8.o obj/fast3d.o obj/fasts.o obj/calcz.o obj/byte.o obj/chelpers.o obj/byte_mpi.o obj/postpro.o obj/cvode_driver.o obj/nek_comm.o obj/init_plugin.o obj/setprop.o obj/qthermal.o obj/cvode_aux.o obj/makeq_aux.o obj/papi.o obj/ssygv.o obj/dsygv.o obj/mxm_std.o obj/blas.o obj/comm_mpi.o obj/mpi_dummy.o obj/jl2_gs.o obj/jl2_sort.o obj/jl2_sarray_transfer.o obj/jl2_sarray_sort.o obj/jl2_gs_local.o obj/jl2_crystal.o obj/jl2_comm.o obj/jl2_tensor.o obj/jl2_fail.o obj/jl2_fcrystal.o obj/jl_tuple_list.o obj/jl_transfer.o obj/jl_sort.o obj/jl_fcrystal.o obj/jl_errmem.o obj/jl_crystal.o obj/jl2_findpts.o obj/jl2_findpts_local.o obj/jl2_obbox.o obj/jl2_poly.o obj/jl2_lob_bnd.o obj/jl2_findpts_el_3.o obj/jl2_findpts_el_2.o obj/jl2_sparse_cholesky.o obj/jl2_xxt.o obj/jl2_fcrs.o ############################## ############################## # # Compilation successful! # ############################## ############################## # text data bss dec hex filename 2073815 2992 24176824 26253631 190993f nek5000* Thanks and regards Vinaya On Thu, May 17, 2012 at 5:51 PM, < nek5000-users at lists.mcs.anl. gov > wrote: Are you using gfortran and gcc? I would suggest setting these as your compiler in makenek and also settig IFMPI to false in the makenek script. Then, makenek clean before resuming your attempt to compile. Best regards, Paul On Thu, 17 May 2012, nek5000-users at lists.mcs.anl.** gov< nek5000-users at lists.mcs. anl.gov >wrote: Dear Sir, Iam trying to compile makenek in (x86_64 x86_64 x86_64 GNU/Linux) environment the error is: *Unable to detect compiler! - don't know how to promote datatype REAL to 8 bytes - don't know how to invoke the C pre-processor (CPP) before compilation Please edit the makefile and specify the requested compiler flags using the P variable.* ** *generating makefile ...* ** Plz help me in this regard -- *Vinaya Sivanandan* *Pune* ** ______________________________ **_________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.** gov < Nek5000-users at lists.mcs.anl. gov > https://lists.mcs.anl.gov/** mailman/listinfo/nek5000-users < https://lists.mcs.anl.gov/ mailman/listinfo/nek5000-users > -- *Vinaya Sivanandan* *Pune* ** ______________________________ _________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl. gov https://lists.mcs.anl.gov/ mailman/listinfo/nek5000-users -- Vinaya Sivanandan Pune -- Vinaya Sivanandan Pune _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon May 21 04:06:45 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 May 2012 11:06:45 +0200 Subject: [Nek5000-users] Mesh issue Message-ID: Hi Nek's, I'm trying to mesh an inclined flat plate (dimension 1*1*1) in a large rectangular box ([-5,5]**3). I'm using Gambit to mesh the flat plate and then I'm using a MatLab program found on this website to convert the mesh file (from Gambit .neu) in the correct format for Nek5000 (.dat). The MatLab conversion don't detect errors. But when I'm checking the .dat file I see some errors in the fluid boundary condition part : E 17650 2 17660 4.00000 0.00000 0.00000 0.00000 17650 3 0 0.00000 0.00000 0.00000 0.00000 E 17650 4 17640 2.00000 0.00000 0.00000 0.00000 There are some blanks in the first column of this file instead of a letter (E,v,O ...) . Did somebody already saw this error? Is there another way to mesh an inclined flat plate? Best Regards, Hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 21 05:47:47 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 May 2012 05:47:47 -0500 (CDT) Subject: [Nek5000-users] Mesh issue In-Reply-To: References: Message-ID: Hi Hugo, What are the boundary conditions on your box? Is there a reason not to simply tilt the box and realize the incline in this manner? Boundary conditions invariably have 3 characters in Nek. I don't know which converter you are using, but " " as a bc would translate either to "E " if it's an interior element boundary, or to something unknown otherwise. Best regards, Paul On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I'm trying to mesh an inclined flat plate (dimension 1*1*1) in a large > rectangular box ([-5,5]**3). > I'm using Gambit to mesh the flat plate and then I'm using a MatLab program > found on this website to convert the mesh file (from Gambit .neu) in the > correct format for Nek5000 (.dat). > > The MatLab conversion don't detect errors. But when I'm checking the .dat > file I see some errors in the fluid boundary condition part : > > E 17650 2 17660 4.00000 0.00000 0.00000 0.00000 > 17650 3 0 0.00000 0.00000 0.00000 0.00000 > E 17650 4 17640 2.00000 0.00000 0.00000 0.00000 > > There are some blanks in the first column of this file instead of a letter > (E,v,O ...) . > > Did somebody already saw this error? > Is there another way to mesh an inclined flat plate? > > Best Regards, > > Hugo > > From nek5000-users at lists.mcs.anl.gov Mon May 21 06:41:59 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 May 2012 13:41:59 +0200 Subject: [Nek5000-users] Mesh issue In-Reply-To: References: Message-ID: Hi Paul, Thanks for your quick answer. The boundary conditions of the box are : - W on the 4 sides of the box, - v for the inlet, - O for the outlet, - W for the 6 faces of the plate (placed at the center of the box). I didn't try to do the mesh by tilting the box to do the incline, but I don't really see how to make it. I'm using a MatLab program found on the mailing list of Nek (https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-June/000645.html). I noticed that for each blank in the boundary condition the figure in the 4th and the 5th column were 0 (which seems to correspond to a BC like W, v or O). 17650 3 *0* *0.00000* 0.00000 0.00000 0.00000 Best regards, Hugo Le 21/05/2012 12:47, nek5000-users at lists.mcs.anl.gov a ?crit : > > Hi Hugo, > > What are the boundary conditions on your box? > > Is there a reason not to simply tilt the box and realize > the incline in this manner? > > Boundary conditions invariably have 3 characters in Nek. > I don't know which converter you are using, but " " as > a bc would translate either to "E " if it's an interior > element boundary, or to something unknown otherwise. > > Best regards, > > Paul > > On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Nek's, >> >> I'm trying to mesh an inclined flat plate (dimension 1*1*1) in a >> large rectangular box ([-5,5]**3). >> I'm using Gambit to mesh the flat plate and then I'm using a MatLab >> program found on this website to convert the mesh file (from Gambit >> .neu) in the correct format for Nek5000 (.dat). >> >> The MatLab conversion don't detect errors. But when I'm checking the >> .dat file I see some errors in the fluid boundary condition part : >> >> E 17650 2 17660 4.00000 0.00000 0.00000 0.00000 >> 17650 3 0 0.00000 0.00000 0.00000 0.00000 >> E 17650 4 17640 2.00000 0.00000 0.00000 0.00000 >> >> There are some blanks in the first column of this file instead of a >> letter (E,v,O ...) . >> >> Did somebody already saw this error? >> Is there another way to mesh an inclined flat plate? >> >> Best Regards, >> >> Hugo >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon May 21 06:53:07 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 May 2012 06:53:07 -0500 (CDT) Subject: [Nek5000-users] Mesh issue In-Reply-To: References: Message-ID: Hi Hugo, Can you tell me again the plate dimension ? (Is it really 1x1x1 ?) What is the angle of incline? Paul On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks for your quick answer. > > The boundary conditions of the box are : > - W on the 4 sides of the box, > - v for the inlet, > - O for the outlet, > - W for the 6 faces of the plate (placed at the center of the box). > > I didn't try to do the mesh by tilting the box to do the incline, but I don't > really see how to make it. > > I'm using a MatLab program found on the mailing list of Nek > (https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-June/000645.html). > I noticed that for each blank in the boundary condition the figure in the 4th > and the 5th column were 0 (which seems to correspond to a BC like W, v or O). > 17650 3 *0* *0.00000* 0.00000 0.00000 0.00000 > > Best regards, > > Hugo > > > Le 21/05/2012 12:47, nek5000-users at lists.mcs.anl.gov a ?crit : >> >> Hi Hugo, >> >> What are the boundary conditions on your box? >> >> Is there a reason not to simply tilt the box and realize >> the incline in this manner? >> >> Boundary conditions invariably have 3 characters in Nek. >> I don't know which converter you are using, but " " as >> a bc would translate either to "E " if it's an interior >> element boundary, or to something unknown otherwise. >> >> Best regards, >> >> Paul >> >> On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi Nek's, >>> >>> I'm trying to mesh an inclined flat plate (dimension 1*1*1) in a large >>> rectangular box ([-5,5]**3). >>> I'm using Gambit to mesh the flat plate and then I'm using a MatLab >>> program found on this website to convert the mesh file (from Gambit .neu) >>> in the correct format for Nek5000 (.dat). >>> >>> The MatLab conversion don't detect errors. But when I'm checking the .dat >>> file I see some errors in the fluid boundary condition part : >>> >>> E 17650 2 17660 4.00000 0.00000 0.00000 0.00000 >>> 17650 3 0 0.00000 0.00000 0.00000 0.00000 >>> E 17650 4 17640 2.00000 0.00000 0.00000 0.00000 >>> >>> There are some blanks in the first column of this file instead of a letter >>> (E,v,O ...) . >>> >>> Did somebody already saw this error? >>> Is there another way to mesh an inclined flat plate? >>> >>> Best Regards, >>> >>> Hugo >>> >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > From nek5000-users at lists.mcs.anl.gov Mon May 21 07:00:24 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 21 May 2012 14:00:24 +0200 Subject: [Nek5000-users] Mesh issue In-Reply-To: References: Message-ID: Sorry, I did a mistake the dimensions are 1*0.05*1. I will try several angles of incline but for now it's 45?. Hugo Le 21/05/2012 13:53, nek5000-users at lists.mcs.anl.gov a ?crit : > > Hi Hugo, > > Can you tell me again the plate dimension ? (Is it really 1x1x1 ?) > > What is the angle of incline? > > Paul > > > On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Paul, >> >> Thanks for your quick answer. >> >> The boundary conditions of the box are : >> - W on the 4 sides of the box, >> - v for the inlet, >> - O for the outlet, >> - W for the 6 faces of the plate (placed at the center of the box). >> >> I didn't try to do the mesh by tilting the box to do the incline, but >> I don't really see how to make it. >> >> I'm using a MatLab program found on the mailing list of Nek >> (https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-June/000645.html). >> I noticed that for each blank in the boundary condition the figure in >> the 4th and the 5th column were 0 (which seems to correspond to a BC >> like W, v or O). >> 17650 3 *0* *0.00000* 0.00000 0.00000 0.00000 >> >> Best regards, >> >> Hugo >> >> >> Le 21/05/2012 12:47, nek5000-users at lists.mcs.anl.gov a ?crit : >>> >>> Hi Hugo, >>> >>> What are the boundary conditions on your box? >>> >>> Is there a reason not to simply tilt the box and realize >>> the incline in this manner? >>> >>> Boundary conditions invariably have 3 characters in Nek. >>> I don't know which converter you are using, but " " as >>> a bc would translate either to "E " if it's an interior >>> element boundary, or to something unknown otherwise. >>> >>> Best regards, >>> >>> Paul >>> >>> On Mon, 21 May 2012, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi Nek's, >>>> >>>> I'm trying to mesh an inclined flat plate (dimension 1*1*1) in a >>>> large rectangular box ([-5,5]**3). >>>> I'm using Gambit to mesh the flat plate and then I'm using a MatLab >>>> program found on this website to convert the mesh file (from Gambit >>>> .neu) in the correct format for Nek5000 (.dat). >>>> >>>> The MatLab conversion don't detect errors. But when I'm checking >>>> the .dat file I see some errors in the fluid boundary condition part : >>>> >>>> E 17650 2 17660 4.00000 0.00000 0.00000 0.00000 >>>> 17650 3 0 0.00000 0.00000 0.00000 0.00000 >>>> E 17650 4 17640 2.00000 0.00000 0.00000 0.00000 >>>> >>>> There are some blanks in the first column of this file instead of a >>>> letter (E,v,O ...) . >>>> >>>> Did somebody already saw this error? >>>> Is there another way to mesh an inclined flat plate? >>>> >>>> Best Regards, >>>> >>>> Hugo >>>> >>>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: