From nek5000-users at lists.mcs.anl.gov Wed Jun 1 04:43:01 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 1 Jun 2011 11:43:01 +0200 Subject: [Nek5000-users] Subroutine opdssum In-Reply-To: References: Message-ID: Hi Andrea, First let me point out that there is a bug in qthermal(). We should perform the direct stiffness summation on the v-mesh instead of T-mesh. Back to your question: You are right, the direct stiffness summation is a special gather-scatter (gs) operation. In general you need two parameters to define a gs-operation: - operation (e.g. +, *, max, min, ...) - operands We compute the operands at run-time using the global glo_num array (defined in CB c_is1). This array is an input for gs_setup() and tells the gs-code what data items it should act on. The gs_setup() call will return a gs-handle which we store for all fields in gsh_fld. It's just a handle so the actual value doesn't matter. In fact we use a zero-based index. Typically there are only two "active" gs-handles for the fields. One for the v-mesh and one for the T-mesh. The reason so switch ifield before a dssum() call is simply related to a bad design in the API. It's a workaround to use the correct handle. -Stefan On 5/31/11, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > thank you very much for your help: the answer is very clear. > I was asking that question because I have a problem with conjugate heat > transfer and Low Mach number formulation (I already posted a question about > that) and I was trying to understand what is going on in qthermal.f . > When at line 41 of qthermal.f the subroutine opdssum is called, ifield= 2 > (temperature field), and when vec_dssum is called, gs_op_many is executed > with gsh_fld(ifldt)=1 (where ifldt=ifield). > Then at line 50, ifield is changed to 1 (velocity field). After that dssum > is called and gs_op is executed with gsh_fld(ifldt)= 0. > I don't understand why gsh_fld(2) is equal to 1 while gsh_fld(1) is equal to > 0. What is the difference in the two operations? > > Thanks in advance for your help. > > With best regards, > Andrea. > > > -----Original Message----- > From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of > nek5000-users at lists.mcs.anl.gov > Sent: Tue 5/31/2011 1:10 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Subroutine opdssum > > > Dear Andreas, > > gsh_fld(ifldt) refers to the gather-scatter handle for field "ifldt" > > ifldt would be a flag refering to the field (1=velocity, 2=temperature, > etc.) for which the gather-scatter (gs) operation is being performed. > > At present, the situation is not entirely satisfactory because ifield > is a global variable that can be in an ambiguous state. In the past, > opdssum (like all other "op" commands) would be applied only on a vector > field - for which there is only one mesh (or topology), namely, velocity. > In MHD, one also has the B-field but this field generally matches the > topology of the velocity. This state of affairs will change in the near > future when we support a B-field external to the velocity field. > > I hope this clarifies a bit... > > Paul > > > > On Sat, 28 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear all, >> >> I was looking into the subroutine "vec_dssum", which is called in >> "opdssum". >> At a certain point there is a call to "gs_op_many" (a gather scatter >> operation I guess, isn't it?) and one of the arguments which is passed to >> this subroutine is "gsh_fld(ifldt)". I printed to screen the content of >> "gsh_fld" but I don't understand what is the meaning of it. >> >> Thanks in advance for your help. >> >> Regards, >> Andreas. >> _______________________________________________ >> 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 Jun 1 07:34:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 1 Jun 2011 14:34:58 +0200 Subject: [Nek5000-users] Subroutine opdssum References: Message-ID: Hi Stefan, thank you very much for your answer. In my case qthermal() gives problems only when I use conjugate heat transfer and there are no boundary conditions for the field "temperature" at the interface between fluid and solid. When I put a boundary condition like 't ' at the boundaries of the fluid domain, I have no problems both with and without conjugate heat transfer. Thanks again, Andrea. -----Original Message----- From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov Sent: Wed 6/1/2011 11:43 AM To: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Subroutine opdssum Hi Andrea, First let me point out that there is a bug in qthermal(). We should perform the direct stiffness summation on the v-mesh instead of T-mesh. Back to your question: You are right, the direct stiffness summation is a special gather-scatter (gs) operation. In general you need two parameters to define a gs-operation: - operation (e.g. +, *, max, min, ...) - operands We compute the operands at run-time using the global glo_num array (defined in CB c_is1). This array is an input for gs_setup() and tells the gs-code what data items it should act on. The gs_setup() call will return a gs-handle which we store for all fields in gsh_fld. It's just a handle so the actual value doesn't matter. In fact we use a zero-based index. Typically there are only two "active" gs-handles for the fields. One for the v-mesh and one for the T-mesh. The reason so switch ifield before a dssum() call is simply related to a bad design in the API. It's a workaround to use the correct handle. -Stefan On 5/31/11, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > thank you very much for your help: the answer is very clear. > I was asking that question because I have a problem with conjugate heat > transfer and Low Mach number formulation (I already posted a question about > that) and I was trying to understand what is going on in qthermal.f . > When at line 41 of qthermal.f the subroutine opdssum is called, ifield= 2 > (temperature field), and when vec_dssum is called, gs_op_many is executed > with gsh_fld(ifldt)=1 (where ifldt=ifield). > Then at line 50, ifield is changed to 1 (velocity field). After that dssum > is called and gs_op is executed with gsh_fld(ifldt)= 0. > I don't understand why gsh_fld(2) is equal to 1 while gsh_fld(1) is equal to > 0. What is the difference in the two operations? > > Thanks in advance for your help. > > With best regards, > Andrea. > > > -----Original Message----- > From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of > nek5000-users at lists.mcs.anl.gov > Sent: Tue 5/31/2011 1:10 AM > To: nek5000-users at lists.mcs.anl.gov > Subject: Re: [Nek5000-users] Subroutine opdssum > > > Dear Andreas, > > gsh_fld(ifldt) refers to the gather-scatter handle for field "ifldt" > > ifldt would be a flag refering to the field (1=velocity, 2=temperature, > etc.) for which the gather-scatter (gs) operation is being performed. > > At present, the situation is not entirely satisfactory because ifield > is a global variable that can be in an ambiguous state. In the past, > opdssum (like all other "op" commands) would be applied only on a vector > field - for which there is only one mesh (or topology), namely, velocity. > In MHD, one also has the B-field but this field generally matches the > topology of the velocity. This state of affairs will change in the near > future when we support a B-field external to the velocity field. > > I hope this clarifies a bit... > > Paul > > > > On Sat, 28 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear all, >> >> I was looking into the subroutine "vec_dssum", which is called in >> "opdssum". >> At a certain point there is a call to "gs_op_many" (a gather scatter >> operation I guess, isn't it?) and one of the arguments which is passed to >> this subroutine is "gsh_fld(ifldt)". I printed to screen the content of >> "gsh_fld" but I don't understand what is the meaning of it. >> >> Thanks in advance for your help. >> >> Regards, >> Andreas. >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 5031 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 1 15:20:28 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 1 Jun 2011 15:20:28 -0500 Subject: [Nek5000-users] Error in generalev Message-ID: Hello Neks, I've recently come across an error I haven't seen before. It occurs in the routine "generalev" at the beginning of my run. It looks like the matrix "a" and "b" being fed to the routine have an Infinity or NaN at position (0,0). Are there any ideas of what could cause this type of error? I have attached the logfile to this email. Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke -------------- next part -------------- A non-text attachment was scrubbed... Name: output Type: application/octet-stream Size: 68454 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 1 18:38:35 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 1 Jun 2011 18:38:35 -0500 (CDT) Subject: [Nek5000-users] Error in generalev In-Reply-To: References: Message-ID: Hi Josh, Have you tried to compile with trapping floating point exception? E.g., the compiler flag for pgf77 is -Ktrap=fp Then you may get a better idea where Inf & Nan first appear... Best, Aleks On Wed, 1 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I've recently come across an error I haven't seen before. It occurs > in the routine "generalev" at the beginning of my run. > > It looks like the matrix "a" and "b" being fed to the routine have an > Infinity or NaN at position (0,0). Are there any ideas of what could > cause this type of error? > > I have attached the logfile to this email. > > Thanks, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > From nek5000-users at lists.mcs.anl.gov Thu Jun 2 05:07:22 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 02 Jun 2011 13:07:22 +0300 Subject: [Nek5000-users] Kernel Panic(s) Message-ID: <20110602130722.14051fv4gazxqvve@webmail.uowm.gr> Dear Nekies, We've been encountering some regular kernel panics during almost all of our latest runs (the moment neks is issued, panic occurs, not even logfile created). I haven't tried to capture much data of the logs yet (e.g. using kdump+kexec). I am aware that it could be virtually anything causing that, but my initial question would be are there any known specific issues with nek5k that might trigger that kind of kernel Oopsing? From nek5000-users at lists.mcs.anl.gov Thu Jun 2 06:42:35 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 2 Jun 2011 13:42:35 +0200 Subject: [Nek5000-users] Kernel Panic(s) In-Reply-To: <20110602130722.14051fv4gazxqvve@webmail.uowm.gr> References: <20110602130722.14051fv4gazxqvve@webmail.uowm.gr> Message-ID: Not that I know of. -Stefan On 6/2/11, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nekies, > > We've been encountering some regular kernel panics during almost all > of our latest runs (the moment neks is issued, panic occurs, not even > logfile created). I haven't tried to capture much data of the logs yet > (e.g. using kdump+kexec). > > I am aware that it could be virtually anything causing that, but my > initial question would be are there any known specific issues with > nek5k that might trigger that kind of kernel Oopsing? > > > > _______________________________________________ > 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 Thu Jun 2 07:11:56 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 2 Jun 2011 07:11:56 -0500 (CDT) Subject: [Nek5000-users] Kernel Panic(s) In-Reply-To: <20110602130722.14051fv4gazxqvve@webmail.uowm.gr> References: <20110602130722.14051fv4gazxqvve@webmail.uowm.gr> Message-ID: What platform are you using? What compiler? and which command do you use to launch nek? Paul On Thu, 2 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear Nekies, > > We've been encountering some regular kernel panics during almost all of our > latest runs (the moment neks is issued, panic occurs, not even logfile > created). I haven't tried to capture much data of the logs yet (e.g. using > kdump+kexec). > > I am aware that it could be virtually anything causing that, but my initial > question would be are there any known specific issues with nek5k that might > trigger that kind of kernel Oopsing? > > > > _______________________________________________ > 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 Thu Jun 2 08:56:50 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 02 Jun 2011 16:56:50 +0300 Subject: [Nek5000-users] Kernel Panic(s) Message-ID: <20110602165650.20714jy1r73ygq76@webmail.uowm.gr> Paul and Stefan, thanks for your fast replies. Heres the info you asked for :) release: Red Hat Enterprise Linux AS release 4 (Nahant Update 4) kernel: 2.6.9-42.9hp compiler: pgf90 7.1-1 64-bit target on x86-64 Linux -tp k8-64e launch command: mpirun -machinefile machines -np $2 ./nek5000 >logfile & Best, nab From nek5000-users at lists.mcs.anl.gov Thu Jun 2 09:43:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 2 Jun 2011 09:43:51 -0500 (CDT) Subject: [Nek5000-users] Kernel Panic(s) In-Reply-To: <20110602165650.20714jy1r73ygq76@webmail.uowm.gr> References: <20110602165650.20714jy1r73ygq76@webmail.uowm.gr> Message-ID: Hi Nab, I have been running Nek5000 on a local Linux cluster with the kernel 2.6.17.14, compiler pgf77 and following submission script below. Have you managed to compile and run the code sequentially (IFMPI="false" in makenek) for one of the examples (nek5_svn/examples) witn the script nek or nekb in nek5_svn/trunk/tools/scripts? Then compiled w/ MPI and submitted on one precessor with the script below? Best, Aleks ### set np=32 # procs set m=dnodes/16nod_32cpu # machine node file set d=. ##$home # run directory set e=$d/nek5000 # executable # echo $1 > SESSION.NAME echo `pwd`'/' >> SESSION.NAME touch $1.rea rm -f ioinfo mv -f $1.his $1.his1 mv -f $1.sch $1.sch1 # rm -f $1.log2.$np cp -f $1.log1.$np $1.log2.$np rm -f $1.log1.$np cp -f $1.log.$np $1.log1.$np nohup mpirun -np $np -machinefile $m -s $e > $1.log.$np & sleep 2 rm -f logfile ln $1.log.$np logfile On Thu, 2 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Paul and Stefan, thanks for your fast replies. Heres the info you asked for > :) > > release: > Red Hat Enterprise Linux AS release 4 (Nahant Update 4) > > kernel: > 2.6.9-42.9hp > > compiler: > pgf90 7.1-1 64-bit target on x86-64 Linux -tp k8-64e > > > launch command: > mpirun -machinefile machines -np $2 ./nek5000 >logfile & > > Best, > nab > > _______________________________________________ > 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 Thu Jun 2 13:16:46 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 2 Jun 2011 13:16:46 -0500 Subject: [Nek5000-users] Error in generalev In-Reply-To: References: Message-ID: Hello Aleks, I compiled with the option for trapping a floating point exception, and it gives the message that it trapped the exception in the same spot as before (which is very odd). It might be worth mentioning that if I run in post-processing mode (nsteps=0), it still traps an exception while in userchk (although I don't think it's anything specific in my userchk, as I've used the same .usr file before). The floating point exception occurs when I make a call to col3 with vx and vx (to get the velocity squared), but when I calculate the max and min velocities earlier in userchk, I don't have any issues. My guess is that something with my geometry is wrong, but it passes the various geometry checks I see in the logfile. I'm not sure what is causing the failure at this point--any thoughts? Josh On Wed, Jun 1, 2011 at 6:38 PM, wrote: > Hi Josh, > > Have you tried to compile with trapping floating point exception? > > E.g., the compiler flag for pgf77 is > > -Ktrap=fp > > Then you may get a better idea where Inf & Nan first appear... > > Best, > Aleks > > > > On Wed, 1 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Neks, >> >> I've recently come across an error I haven't seen before. ? ?It occurs >> in the routine "generalev" at the beginning of my run. >> >> It looks like the matrix "a" and "b" being fed to the routine have an >> Infinity or NaN at position (0,0). ?Are there any ideas of what could >> cause this type of error? >> >> I have attached the logfile to this email. >> >> Thanks, >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Thu Jun 2 14:29:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 2 Jun 2011 14:29:51 -0500 Subject: [Nek5000-users] Error in generalev In-Reply-To: References: Message-ID: Hi Josh, Can you send me your files for this case. (.map, .rea, .usr, and SIZE). I think you are probably right about the geometry being the issue, possibly the boundary conditions. I will take a look at it and see if anything sticks out or if we can reproduce the problem locally. Also, how did you create the mesh for this case? Thanks, Katie On Thu, Jun 2, 2011 at 1:16 PM, wrote: > Hello Aleks, > > I compiled with the option for trapping a floating point exception, > and it gives the message that it trapped the exception in the same > spot as before (which is very odd). > > It might be worth mentioning that if I run in post-processing mode > (nsteps=0), it still traps an exception while in userchk (although I > don't think it's anything specific in my userchk, as I've used the > same .usr file before). The floating point exception occurs when I > make a call to col3 with vx and vx (to get the velocity squared), but > when I calculate the max and min velocities earlier in userchk, I > don't have any issues. > > My guess is that something with my geometry is wrong, but it passes > the various geometry checks I see in the logfile. I'm not sure what > is causing the failure at this point--any thoughts? > > Josh > > On Wed, Jun 1, 2011 at 6:38 PM, wrote: > > Hi Josh, > > > > Have you tried to compile with trapping floating point exception? > > > > E.g., the compiler flag for pgf77 is > > > > -Ktrap=fp > > > > Then you may get a better idea where Inf & Nan first appear... > > > > Best, > > Aleks > > > > > > > > On Wed, 1 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > > > >> Hello Neks, > >> > >> I've recently come across an error I haven't seen before. It occurs > >> in the routine "generalev" at the beginning of my run. > >> > >> It looks like the matrix "a" and "b" being fed to the routine have an > >> Infinity or NaN at position (0,0). Are there any ideas of what could > >> cause this type of error? > >> > >> I have attached the logfile to this email. > >> > >> Thanks, > >> > >> -- > >> Josh Camp > >> > >> "All that is necessary for the triumph of evil is that good men do > >> nothing" -- Edmund Burke > >> > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 Jun 3 03:19:02 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 3 Jun 2011 10:19:02 +0200 Subject: [Nek5000-users] Kernel Panic(s) In-Reply-To: References: <20110602165650.20714jy1r73ygq76@webmail.uowm.gr> Message-ID: Hi Nab, Please post the kernel panic/oops call trace. I guess this is not a Nek related problem. Something is wrong with your system. -Stefan On 6/2/11, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nab, > > I have been running Nek5000 on a local Linux cluster with the kernel > 2.6.17.14, compiler pgf77 and following submission script below. > > Have you managed to compile and run the code sequentially (IFMPI="false" > in makenek) for one of the examples (nek5_svn/examples) witn the script > nek or nekb in nek5_svn/trunk/tools/scripts? > Then compiled w/ MPI and submitted on one precessor with the script below? > > Best, > Aleks > > > ### > set np=32 # procs > set m=dnodes/16nod_32cpu # machine node file > set d=. ##$home # run directory > set e=$d/nek5000 # executable > # > echo $1 > SESSION.NAME > echo `pwd`'/' >> SESSION.NAME > touch $1.rea > rm -f ioinfo > mv -f $1.his $1.his1 > mv -f $1.sch $1.sch1 > # > rm -f $1.log2.$np > cp -f $1.log1.$np $1.log2.$np > rm -f $1.log1.$np > cp -f $1.log.$np $1.log1.$np > nohup mpirun -np $np -machinefile $m -s $e > $1.log.$np & > sleep 2 > rm -f logfile > ln $1.log.$np logfile > > > > > > On Thu, 2 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Paul and Stefan, thanks for your fast replies. Heres the info you asked >> for >> :) >> >> release: >> Red Hat Enterprise Linux AS release 4 (Nahant Update 4) >> >> kernel: >> 2.6.9-42.9hp >> >> compiler: >> pgf90 7.1-1 64-bit target on x86-64 Linux -tp k8-64e >> >> >> launch command: >> mpirun -machinefile machines -np $2 ./nek5000 >logfile & >> >> Best, >> nab >> >> _______________________________________________ >> 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 Jun 3 04:31:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 3 Jun 2011 04:31:57 -0500 (CDT) Subject: [Nek5000-users] Error in generalev In-Reply-To: References: Message-ID: Hi Josh, Sorry for the delay in processing this... it took awhile for an idea to register here. My guess is that you have an invalid BC --- If you can send a .rea/.usr/SIZE tarfile (e.g., to our ftp site) I can try to inspect it. You could also do this by trapping the offending element from where the code bails in generalev... Sorry for the trouble. Paul On Wed, 1 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello Neks, > > I've recently come across an error I haven't seen before. It occurs > in the routine "generalev" at the beginning of my run. > > It looks like the matrix "a" and "b" being fed to the routine have an > Infinity or NaN at position (0,0). Are there any ideas of what could > cause this type of error? > > I have attached the logfile to this email. > > Thanks, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > From nek5000-users at lists.mcs.anl.gov Fri Jun 3 06:54:54 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 03 Jun 2011 14:54:54 +0300 Subject: [Nek5000-users] Kernel Panic(s) In-Reply-To: References: <20110602165650.20714jy1r73ygq76@webmail.uowm.gr> Message-ID: <20110603145454.15806eikdicjfbm6@webmail.uowm.gr> Hi again Nekies, Aleks, i am quite sure Stefan is right. Nek used to run fine, it's just that the larger the cases get, the more frequent the panics occur... So my bet is something wrong with the Infiniband kernel module or something in the interconnection area. Stefan my first approach was to make the net.core.optmem_max three times larger. Anyhow, I ll trace it and get back to you. Thank you all for your interest. ~nab Quoting nek5000-users at lists.mcs.anl.gov: > Hi Nab, > > Please post the kernel panic/oops call trace. I guess this is not a > Nek related problem. Something is wrong with your system. > > -Stefan > > On 6/2/11, nek5000-users at lists.mcs.anl.gov > wrote: >> Hi Nab, >> >> I have been running Nek5000 on a local Linux cluster with the kernel >> 2.6.17.14, compiler pgf77 and following submission script below. >> >> Have you managed to compile and run the code sequentially (IFMPI="false" >> in makenek) for one of the examples (nek5_svn/examples) witn the script >> nek or nekb in nek5_svn/trunk/tools/scripts? >> Then compiled w/ MPI and submitted on one precessor with the script below? >> >> Best, >> Aleks >> >> >> ### >> set np=32 # procs >> set m=dnodes/16nod_32cpu # machine node file >> set d=. ##$home # run directory >> set e=$d/nek5000 # executable >> # >> echo $1 > SESSION.NAME >> echo `pwd`'/' >> SESSION.NAME >> touch $1.rea >> rm -f ioinfo >> mv -f $1.his $1.his1 >> mv -f $1.sch $1.sch1 >> # >> rm -f $1.log2.$np >> cp -f $1.log1.$np $1.log2.$np >> rm -f $1.log1.$np >> cp -f $1.log.$np $1.log1.$np >> nohup mpirun -np $np -machinefile $m -s $e > $1.log.$np & >> sleep 2 >> rm -f logfile >> ln $1.log.$np logfile >> >> >> >> >> >> On Thu, 2 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Paul and Stefan, thanks for your fast replies. Heres the info you asked >>> for >>> :) >>> >>> release: >>> Red Hat Enterprise Linux AS release 4 (Nahant Update 4) >>> >>> kernel: >>> 2.6.9-42.9hp >>> >>> compiler: >>> pgf90 7.1-1 64-bit target on x86-64 Linux -tp k8-64e >>> >>> >>> launch command: >>> mpirun -machinefile machines -np $2 ./nek5000 >logfile & >>> >>> Best, >>> nab >>> >>> _______________________________________________ >>> 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 > From nek5000-users at lists.mcs.anl.gov Fri Jun 3 06:55:12 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 3 Jun 2011 06:55:12 -0500 Subject: [Nek5000-users] Error in generalev In-Reply-To: References: Message-ID: Hi Paul, After Katie's response, I took a closer look at the .rea file and we indeed have some incorrect boundary conditions. Thanks for the suggestion! Josh On Fri, Jun 3, 2011 at 4:31 AM, wrote: > > Hi Josh, > > Sorry for the delay in processing this... it took awhile for > an idea to register here. > > My guess is that you have an invalid BC --- If you can > send a .rea/.usr/SIZE tarfile (e.g., to our ftp site) > I can try to inspect it. > > You could also do this by trapping the offending element > from where the code bails in generalev... > > Sorry for the trouble. > > Paul > > > On Wed, 1 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello Neks, >> >> I've recently come across an error I haven't seen before. ? ?It occurs >> in the routine "generalev" at the beginning of my run. >> >> It looks like the matrix "a" and "b" being fed to the routine have an >> Infinity or NaN at position (0,0). ?Are there any ideas of what could >> cause this type of error? >> >> I have attached the logfile to this email. >> >> Thanks, >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Tue Jun 7 11:14:27 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 7 Jun 2011 16:14:27 +0000 Subject: [Nek5000-users] Periodic bc for bent 2D channel Message-ID: Hello; I have a question regarding the Periodic BC in Nek5000. I already setup a simulation, it is a 2D channel generated by genbox. Using userdat2 I would be able able to bend it to (0,pi/2) as Half Arch with flow direction from up-left to right-bottom; however when I tried to run it, it seems the periodic bc do not take care of the change in the direction of the flow at the boundary. Now since the left-side periodic domain is in the same position as before, but the right-side one face downward with a 90 deg rotation, I would like to define the Periodic bc as (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in the source code I did not find any relevant information regarding this adjustment or at least re-define the Periodic bc. I really appreciate if you could help me by this. Many thanks Azad -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 7 11:23:38 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 7 Jun 2011 18:23:38 +0200 Subject: [Nek5000-users] Periodic bc for bent 2D channel In-Reply-To: References: Message-ID: Hi Azad I guess you're looking for a cyclic boundary condition. We implemented something like this for 2D geometries some time ago.Just set the logical flag IFCYCLIC to true in your rea-file and give it a whirl. -Stefan On 6/7/11, nek5000-users at lists.mcs.anl.gov wrote: > Hello; > > > I have a question regarding the Periodic BC in Nek5000. I already setup a > simulation, it is a 2D channel generated by genbox. Using userdat2 I would > be able able to bend it to (0,pi/2) as Half Arch with flow direction from > up-left to right-bottom; however when I tried to run it, it seems the > periodic bc do not take care of the change in the direction of the flow at > the boundary. Now since the left-side periodic domain is in the same > position as before, but the right-side one face downward with a 90 deg > rotation, I would like to define the Periodic bc as > (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in > the source code I did not find any relevant information regarding this > adjustment or at least re-define the Periodic bc. I really appreciate if you > could help me by this. > > > Many thanks > > Azad > From nek5000-users at lists.mcs.anl.gov Tue Jun 7 11:35:21 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 7 Jun 2011 11:35:21 -0500 (CDT) Subject: [Nek5000-users] Periodic bc for bent 2D channel In-Reply-To: Message-ID: <842151599.12710.1307464521780.JavaMail.root@zimbra.anl.gov> Hi Azad, I think that a correct way of implementing this (non-affine) transformation would be in userdat instead of userdat2 -- there you can just adjust element vertex coordinate arrays xc,yc,zc INPUT:69: COMMON /INPUT5/ XC(8,LELT),YC(8,LELT),ZC(8,LELT) which are a part of TOTAL The piece of the code should be something like subroutine usrdat include 'SIZE' include 'TOTAL' ntot = 8*nelt do i=1,ntot xc(i,1) = ... ... Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, June 7, 2011 11:14:27 AM Subject: [Nek5000-users] Periodic bc for bent 2D channel Hello; I have a question regarding the Periodic BC in Nek5000. I already setup a simulation, it is a 2D channel generated by genbox. Using userdat2 I would be able able to bend it to (0,pi/2) as Half Arch with flow direction from up-left to right-bottom; however when I tried to run it, it seems the periodic bc do not take care of the change in the direction of the flow at the boundary. Now since the left-side periodic domain is in the same position as before, but the right-side one face downward with a 90 deg rotation, I would like to define the Periodic bc as (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in the source code I did not find any relevant information regarding this adjustment or at least re-define the Periodic bc. I really appreciate if you could help me by this. Many thanks Azad _______________________________________________ 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 Tue Jun 7 11:46:42 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 7 Jun 2011 18:46:42 +0200 Subject: [Nek5000-users] Periodic bc for bent 2D channel In-Reply-To: <842151599.12710.1307464521780.JavaMail.root@zimbra.anl.gov> References: <842151599.12710.1307464521780.JavaMail.root@zimbra.anl.gov> Message-ID: It depends ... If you modify the element vertices you should do it in usrdat(), as suggested by Aleks. If you want modify the SEM mesh (in our case the GLL points) you're ok with usrdat2(). -Stefan On 6/7/11, nek5000-users at lists.mcs.anl.gov wrote: > Hi Azad, > > > I think that a correct way of implementing this (non-affine) transformation > would be in userdat instead of userdat2 -- there you can just adjust element > vertex coordinate arrays xc,yc,zc > > INPUT:69: COMMON /INPUT5/ XC(8,LELT),YC(8,LELT),ZC(8,LELT) > > which are a part of TOTAL > > > The piece of the code should be something like > > subroutine usrdat > include 'SIZE' > include 'TOTAL' > > ntot = 8*nelt > > do i=1,ntot > > xc(i,1) = ... > > ... > > > Best, > Aleks > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, June 7, 2011 11:14:27 AM > Subject: [Nek5000-users] Periodic bc for bent 2D channel > > > > > > Hello; > > > > > I have a question regarding the Periodic BC in Nek5000. I already setup a > simulation, it is a 2D channel generated by genbox. Using userdat2 I would > be able able to bend it to (0,pi/2) as Half Arch with flow direction from > up-left to right-bottom; however when I tried to run it, it seems the > periodic bc do not take care of the change in the direction of the flow at > the boundary. Now since the left-side periodic domain is in the same > position as before, but the right-side one face downward with a 90 deg > rotation, I would like to define the Periodic bc as > (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in > the source code I did not find any relevant information regarding this > adjustment or at least re-define the Periodic bc. I really appreciate if you > could help me by this. > > > > > Many thanks > > Azad > _______________________________________________ > 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 Thu Jun 9 04:50:08 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 9 Jun 2011 11:50:08 +0200 Subject: [Nek5000-users] Adjoint perturbation In-Reply-To: References: Message-ID: Hi Neks, I was just wondering if the adjoint linear solver has already been released in the current repo or not? Regards, On 6 May 2011 15:49, wrote: > > > Dear Jean-Christophe, > > My apologies for the delay in getting back to you - we've been > saturated with proposal writing on our end. > > Your approach looks reasonable -- though I would avoid at all > costs the f90 type declarations and stick with the std f77-based > approach to be consistent with the code. > > I'll look into your proposed approach. I should point out also > that we've recently had an adjoint solver developed by some colleagues that > is ready to go into the svn repo. I've just > been delayed in getting it in because of travel and proposals. > My hope is that this will be in the repo in about 10-15 days. > > Regarding the proper choice of gradm1 vs wgradm1, the question > ultimately comes down to the degree of differentiability of the > input --- functions in nek are only C0 and hence one-time differentiable. > This applies also to the test functions. Thus, the std. practice > is to move a derivative from the solution to the test functions (i.e., > to use the weak derivative) whenever the solution is to be differentiated > twice. > > Regards, > > Paul > > > > > > On Thu, 5 May 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Nek's, >> >> >> I am interested into the linear adjoint perturbation. The equations read: >> >> -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) >> >> div(u) = 0 >> >> Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - >> transpose(Grad(U)) >> u + 1/Re Laplacian(u) - grad(p) >> Only small modifications to the perturbation mode are necessary, mainly to >> evaluate the tranpose gradient terms. Here is what I've done to evaluate >> these: >> >> subroutine conv_adj(conv_x,conv_y,conv_z,u_x,u_y,u_z) ! used to be >> conv1n >> >> >> include 'SIZE' >> >> include 'DXYZ' >> >> include 'INPUT' >> >> include 'GEOM' >> >> include 'SOLN' >> >> include 'TSTEP' >> >> >> parameter (lt=lx1*ly1*lz1*lelt) >> >> real u_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> real u_y (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> real u_z (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> >> real u_xx (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> real u_xy (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> real u_xz (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> >> real u_yx (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >> >> real u_yy (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >> >> real u_yz (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >> >> >> real u_zx (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >> >> real u_zy (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >> >> real u_zz (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >> >> >> real conv_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >> >> real conv_y (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >> >> real conv_z (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >> >> >> *call gradm1(u_xx,u_xy,u_xz,u_x)* >> >> * call gradm1(u_yx,u_yy,u_yz,u_y)* >> >> * call gradm1(u_zx,u_zy,u_zz,u_z)* >> >> * >> * >> >> * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* >> >> * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* >> >> * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* >> >> >> return >> >> end >> >> However, I'm not sure I've done it properly or not (arrays declaration for >> instance). Especially, I had no idea wheter I have to use the gradm1 >> subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've >> slightly change the advap subroutine the following way: >> >> subroutine advabp >> >> C >> >> C Eulerian scheme, add convection term to forcing function >> >> C at current time step. >> >> C >> >> include 'SIZE' >> >> include 'INPUT' >> >> include 'SOLN' >> >> include 'MASS' >> >> include 'TSTEP' >> >> C >> >> COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) >> >> $ , TA2 (LX1*LY1*LZ1*LELV) >> >> $ , TA3 (LX1*LY1*LZ1*LELV) >> >> $ , TB1 (LX1*LY1*LZ1*LELV) >> >> $ , TB2 (LX1*LY1*LZ1*LELV) >> >> $ , TB3 (LX1*LY1*LZ1*LELV) >> >> C >> >> ntot1 = nx1*ny1*nz1*nelv >> >> ntot2 = nx2*ny2*nz2*nelv >> >> c >> >> if (if3d) then >> >> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >> velocity >> >> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- du >> >> * call conv_adj(ta1,ta2,ta3,tb1,tb2,tb3)* >> >> * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* >> >> *c* >> >> * do i=1,ntot1* >> >> * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield)* >> >> * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* >> >> * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* >> >> * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* >> >> * enddo* >> >> c >> >> call convop (ta1,vxp(1,jp)) ! U.grad dU >> >> call convop (ta2,vyp(1,jp)) >> >> call convop (ta3,vzp(1,jp)) >> >> c >> >> do i=1,ntot1 >> >> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >> >> *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* >> >> * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* >> >> * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* >> >> enddo >> >> c >> >> else ! 2D >> >> c >> >> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >> velocity >> >> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- dU >> >> call convop (ta1,tb1) ! du.grad U >> >> call convop (ta2,tb2) >> >> call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity >> >> c >> >> do i=1,ntot1 >> >> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >> >> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >> >> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >> >> enddo >> >> c >> >> call convop (ta1,vxp(1,jp)) ! U.grad dU >> >> call convop (ta2,vyp(1,jp)) >> >> c >> >> do i=1,ntot1 >> >> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >> >> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >> >> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >> >> enddo >> >> c >> >> endif >> >> c >> >> return >> >> end >> >> >> Any help to spot potential erros or to speed up these operation would be >> highly appreciated. >> >> Best regards, >> -- >> Jean-Christophe >> >> _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 9 07:25:57 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 9 Jun 2011 12:25:57 +0000 Subject: [Nek5000-users] Periodic bc for bent 2D channel Message-ID: Dear Stefan and Aleks; With this E-mail I just wanted to say thanks. The IFCYCLIC was the option that I actually were looking for. It works very well, and by "2D" I presume you meant the 2D transformation or planner transformation, since I think it works as well for the 3D cases that transformed in plane. Also as Stefan mentioned I was interested in transforming the mesh instead of vertexes. Though it was very interesting that I could change the position of vertexes in the 'userdat'. Many thanks; Azad ------------------------------------------------------------------------------------------------------------------- From: nek5000-users-request at lists.mcs.anl.gov Reply-to: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Subject: Nek5000-users Digest, Vol 28, Issue 6 Date: Tue, 07 Jun 2011 12:00:13 -0500 (06/07/2011 07:00:13 PM) 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. Periodic bc for bent 2D channel (nek5000-users at lists.mcs.anl.gov) 2. Re: Periodic bc for bent 2D channel (nek5000-users at lists.mcs.anl.gov) 3. Re: Periodic bc for bent 2D channel (nek5000-users at lists.mcs.anl.gov) 4. Re: Periodic bc for bent 2D channel (nek5000-users at lists.mcs.anl.gov) ---------------------------------------------------------------------- Message: 1 Date: Tue, 7 Jun 2011 16:14:27 +0000 From: nek5000-users at lists.mcs.anl.gov Subject: [Nek5000-users] Periodic bc for bent 2D channel To: "nek5000-users at lists.mcs.anl.gov" Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello; I have a question regarding the Periodic BC in Nek5000. I already setup a simulation, it is a 2D channel generated by genbox. Using userdat2 I would be able able to bend it to (0,pi/2) as Half Arch with flow direction from up-left to right-bottom; however when I tried to run it, it seems the periodic bc do not take care of the change in the direction of the flow at the boundary. Now since the left-side periodic domain is in the same position as before, but the right-side one face downward with a 90 deg rotation, I would like to define the Periodic bc as (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in the source code I did not find any relevant information regarding this adjustment or at least re-define the Periodic bc. I really appreciate if you could help me by this. Many thanks Azad -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 7 Jun 2011 18:23:38 +0200 From: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Periodic bc for bent 2D channel To: nek5000-users at lists.mcs.anl.gov Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi Azad I guess you're looking for a cyclic boundary condition. We implemented something like this for 2D geometries some time ago.Just set the logical flag IFCYCLIC to true in your rea-file and give it a whirl. -Stefan On 6/7/11, nek5000-users at lists.mcs.anl.gov wrote: > Hello; > > > I have a question regarding the Periodic BC in Nek5000. I already setup a > simulation, it is a 2D channel generated by genbox. Using userdat2 I would > be able able to bend it to (0,pi/2) as Half Arch with flow direction from > up-left to right-bottom; however when I tried to run it, it seems the > periodic bc do not take care of the change in the direction of the flow at > the boundary. Now since the left-side periodic domain is in the same > position as before, but the right-side one face downward with a 90 deg > rotation, I would like to define the Periodic bc as > (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in > the source code I did not find any relevant information regarding this > adjustment or at least re-define the Periodic bc. I really appreciate if you > could help me by this. > > > Many thanks > > Azad > ------------------------------ Message: 3 Date: Tue, 7 Jun 2011 11:35:21 -0500 (CDT) From: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Periodic bc for bent 2D channel To: nek5000-users at lists.mcs.anl.gov Message-ID: <842151599.12710.1307464521780.JavaMail.root at zimbra.anl.gov> Content-Type: text/plain; charset=utf-8 Hi Azad, I think that a correct way of implementing this (non-affine) transformation would be in userdat instead of userdat2 -- there you can just adjust element vertex coordinate arrays xc,yc,zc INPUT:69: COMMON /INPUT5/ XC(8,LELT),YC(8,LELT),ZC(8,LELT) which are a part of TOTAL The piece of the code should be something like subroutine usrdat include 'SIZE' include 'TOTAL' ntot = 8*nelt do i=1,ntot xc(i,1) = ... ... Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Tuesday, June 7, 2011 11:14:27 AM Subject: [Nek5000-users] Periodic bc for bent 2D channel Hello; I have a question regarding the Periodic BC in Nek5000. I already setup a simulation, it is a 2D channel generated by genbox. Using userdat2 I would be able able to bend it to (0,pi/2) as Half Arch with flow direction from up-left to right-bottom; however when I tried to run it, it seems the periodic bc do not take care of the change in the direction of the flow at the boundary. Now since the left-side periodic domain is in the same position as before, but the right-side one face downward with a 90 deg rotation, I would like to define the Periodic bc as (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in the source code I did not find any relevant information regarding this adjustment or at least re-define the Periodic bc. I really appreciate if you could help me by this. Many thanks Azad _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users ------------------------------ Message: 4 Date: Tue, 7 Jun 2011 18:46:42 +0200 From: nek5000-users at lists.mcs.anl.gov Subject: Re: [Nek5000-users] Periodic bc for bent 2D channel To: nek5000-users at lists.mcs.anl.gov Message-ID: Content-Type: text/plain; charset=ISO-8859-1 It depends ... If you modify the element vertices you should do it in usrdat(), as suggested by Aleks. If you want modify the SEM mesh (in our case the GLL points) you're ok with usrdat2(). -Stefan On 6/7/11, nek5000-users at lists.mcs.anl.gov wrote: > Hi Azad, > > > I think that a correct way of implementing this (non-affine) transformation > would be in userdat instead of userdat2 -- there you can just adjust element > vertex coordinate arrays xc,yc,zc > > INPUT:69: COMMON /INPUT5/ XC(8,LELT),YC(8,LELT),ZC(8,LELT) > > which are a part of TOTAL > > > The piece of the code should be something like > > subroutine usrdat > include 'SIZE' > include 'TOTAL' > > ntot = 8*nelt > > do i=1,ntot > > xc(i,1) = ... > > ... > > > Best, > Aleks > > > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Tuesday, June 7, 2011 11:14:27 AM > Subject: [Nek5000-users] Periodic bc for bent 2D channel > > > > > > Hello; > > > > > I have a question regarding the Periodic BC in Nek5000. I already setup a > simulation, it is a 2D channel generated by genbox. Using userdat2 I would > be able able to bend it to (0,pi/2) as Half Arch with flow direction from > up-left to right-bottom; however when I tried to run it, it seems the > periodic bc do not take care of the change in the direction of the flow at > the boundary. Now since the left-side periodic domain is in the same > position as before, but the right-side one face downward with a 90 deg > rotation, I would like to define the Periodic bc as > (u_left,v_left)=(-v_right,u_right). Unfortunately after searching a lot in > the source code I did not find any relevant information regarding this > adjustment or at least re-define the Periodic bc. I really appreciate if you > could help me by this. > > > > > Many thanks > > Azad > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > _______________________________________________ > 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 End of Nek5000-users Digest, Vol 28, Issue 6 ******************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 13 14:35:58 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 13 Jun 2011 15:35:58 -0400 Subject: [Nek5000-users] Error: Session.name! Message-ID: Hello, I am very impressed by nek5000. I am curious to run examples that have in website. I have built and compiled the makenek file but when I am trying to compile the nek5000 solver, I am getting an error as below: Error: cannot open Session .name! ierr=1 If anyone knows about this please let me know. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 13 14:40:51 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 13 Jun 2011 14:40:51 -0500 (CDT) Subject: [Nek5000-users] Error: Session.name! In-Reply-To: References: Message-ID: Hello, Try running with scripts nek or nekb (background) in nek5_svn/trunk/tools/scripts/ Best, Aleks On Mon, 13 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am very impressed by nek5000. I am curious to run examples that have in > website. > > I have built and compiled the makenek file but when I am trying to compile > the nek5000 solver, I am getting an error as below: > > Error: cannot open Session .name! ierr=1 > > If anyone knows about this please let me know. > > Thanks in advance. > From nek5000-users at lists.mcs.anl.gov Mon Jun 13 14:44:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 13 Jun 2011 21:44:06 +0200 Subject: [Nek5000-users] Error: Session.name! In-Reply-To: References: Message-ID: Hi, If you run Nek it will look for a session file (see here for more details: http://nek5000.mcs.anl.gov/index.php/Sessionfile). -Stefan On 6/13/11, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I am very impressed by nek5000. I am curious to run examples that have in > website. > > I have built and compiled the makenek file but when I am trying to compile > the nek5000 solver, I am getting an error as below: > > Error: cannot open Session .name! ierr=1 > > If anyone knows about this please let me know. > > Thanks in advance. > From nek5000-users at lists.mcs.anl.gov Mon Jun 13 17:29:50 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 13 Jun 2011 17:29:50 -0500 Subject: [Nek5000-users] hpts and pressure Message-ID: Hello Neks, I am trying to output pressure data at various points using the hpts routine. The values that are output for the first time step look ok, but all subsequent time steps seem to give garbage (i.e. the pressures given in hpts.out are way different that what is given by visualizing pressure in VisIt). I know previously that this was an issue for someone and it was thought that passive scalars may be messing the hpts output up, but in my case I don't output temperature or pressure. I looked at the hpts routine and noticed that it uses pm1 when it is stacking the field variables into the working array. Since I am using a Pn-Pn-2 formulation for my case, do I need to use the mappr subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 before calling hpts()? I'm assuming the issue arises because I am calling hpts more frequently than I am outputing field files, and thus perhaps pm1 isn't properly being updated (or perhaps it may have already been destroyed). Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Mon Jun 13 18:42:35 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 13 Jun 2011 18:42:35 -0500 (CDT) Subject: [Nek5000-users] hpts and pressure In-Reply-To: Message-ID: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Hi Josh, Yes, it seems to me that either htps() needs modification for Pn-Pn-2 pressure points or pr() should be mapped to pm1() before calling htps() as you suggested -- something along the lines for .not.ifsplit in prepot.f:219 if (ifsplit) then call copy(pm1,pr,ntot1) else do 1000 e=1,nelv call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) do 100 iz=1,nz2 call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) 100 continue call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) 1000 continue endif Best, Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Monday, June 13, 2011 5:29:50 PM Subject: [Nek5000-users] hpts and pressure Hello Neks, I am trying to output pressure data at various points using the hpts routine. The values that are output for the first time step look ok, but all subsequent time steps seem to give garbage (i.e. the pressures given in hpts.out are way different that what is given by visualizing pressure in VisIt). I know previously that this was an issue for someone and it was thought that passive scalars may be messing the hpts output up, but in my case I don't output temperature or pressure. I looked at the hpts routine and noticed that it uses pm1 when it is stacking the field variables into the working array. Since I am using a Pn-Pn-2 formulation for my case, do I need to use the mappr subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 before calling hpts()? I'm assuming the issue arises because I am calling hpts more frequently than I am outputing field files, and thus perhaps pm1 isn't properly being updated (or perhaps it may have already been destroyed). Thanks, -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke _______________________________________________ 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 Tue Jun 14 10:45:26 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Jun 2011 10:45:26 -0500 Subject: [Nek5000-users] hpts and pressure In-Reply-To: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> References: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Message-ID: Hello, It appears my hypothesis was correct. I post the following for reference to any users who run into the same issue in the future (and I apologize in advance if this question has already been answered before, I didn't see anything in my search, but that doesn't mean it wasn't there). 1) I included the following in the variable declarations of userchk() common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure real pa(lx1,ly2,lz2), pb(lx1,ly1,lz2) ! Working arrays for mappr 2) Then, before I call hpts, I call mappr if (mod(istep,10).eq.0) then ! Only call this every 10th step call mappr(pm1,pr,pa,pb) ! Map pressure first call hpts endif For my case, I didn't want to call hpts every time step to prevent hpts.out from becoming too large. I haven't run this for too long, but on a preliminary basis the results look good. It seems that the scrcg common block must be included in userchk for this to work, as pm1 isn't a part of any of the standard "include" files. Developers and other users, feel free to chime in if there is a more efficient or elegant solution to this problem. Thanks, Josh On Mon, Jun 13, 2011 at 6:42 PM, wrote: > Hi Josh, > > Yes, it seems to me that either htps() needs modification for Pn-Pn-2 pressure points or pr() should be mapped to pm1() before calling htps() as you suggested -- something along the lines for .not.ifsplit in prepot.f:219 > > ? ? ? ? if (ifsplit) then > ? ? ? ? ? ?call copy(pm1,pr,ntot1) > ? ? ? ? else > ? ? ? ? ? ?do 1000 e=1,nelv > ? ? ? ? ? ? ? call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) > ? ? ? ? ? ? ? do 100 iz=1,nz2 > ? ? ? ? ? ? ? ? ?call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) > ?100 ? ? ? ? ?continue > ? ? ? ? ? ? ? call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) > ?1000 ? ? ? continue > ? ? ? ? endif > > Best, > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "nek5000-users" > Sent: Monday, June 13, 2011 5:29:50 PM > Subject: [Nek5000-users] hpts and pressure > > Hello Neks, > > I am trying to output pressure data at various points using the hpts routine. > > The values that are output for the first time step look ok, but all > subsequent time steps seem to give garbage (i.e. the pressures given > in hpts.out are way different that what is given by visualizing > pressure in VisIt). ?I know previously that this was an issue for > someone and it was thought that passive scalars may be messing the > hpts output up, but in my case I don't output temperature or pressure. > > I looked at the hpts routine and noticed that it uses pm1 when it is > stacking the field variables into the working array. ?Since I am using > a Pn-Pn-2 formulation for my case, do I need to use the mappr > subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 > before calling hpts()? > > I'm assuming the issue arises because I am calling hpts more > frequently than I am outputing field files, and thus perhaps pm1 isn't > properly being updated (or perhaps it may have already been > destroyed). > > Thanks, > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 > -- Josh Camp "All that is necessary for the triumph of evil is that good men do nothing" -- Edmund Burke From nek5000-users at lists.mcs.anl.gov Tue Jun 14 11:18:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Jun 2011 18:18:06 +0200 Subject: [Nek5000-users] hpts and pressure In-Reply-To: References: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Message-ID: Hi You are right, the pressure is not mapped automatically. This issue was already discussed in https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-May/000584.html. At the moment there is only a trigger to map the pressure in case we are dumping a field file @Paul: I am not sure where we should trigger the pressure mapping but the way it's implement now is error prone. -Stefan On 6/14/11, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > It appears my hypothesis was correct. I post the following for > reference to any users who run into the same issue in the future (and > I apologize in advance if this question has already been answered > before, I didn't see anything in my search, but that doesn't mean it > wasn't there). > > 1) I included the following in the variable declarations of userchk() > > common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure > real pa(lx1,ly2,lz2), pb(lx1,ly1,lz2) ! Working arrays for mappr > > 2) Then, before I call hpts, I call mappr > > if (mod(istep,10).eq.0) then ! Only call this every 10th step > call mappr(pm1,pr,pa,pb) ! Map pressure first > call hpts > endif > > For my case, I didn't want to call hpts every time step to prevent > hpts.out from becoming too large. > > I haven't run this for too long, but on a preliminary basis the > results look good. It seems that the scrcg common block must be > included in userchk for this to work, as pm1 isn't a part of any of > the standard "include" files. > > Developers and other users, feel free to chime in if there is a more > efficient or elegant solution to this problem. > > Thanks, > > Josh > > On Mon, Jun 13, 2011 at 6:42 PM, wrote: >> Hi Josh, >> >> Yes, it seems to me that either htps() needs modification for Pn-Pn-2 >> pressure points or pr() should be mapped to pm1() before calling htps() as >> you suggested -- something along the lines for .not.ifsplit in >> prepot.f:219 >> >> if (ifsplit) then >> call copy(pm1,pr,ntot1) >> else >> do 1000 e=1,nelv >> call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) >> do 100 iz=1,nz2 >> call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) >> 100 continue >> call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) >> 1000 continue >> endif >> >> Best, >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: "nek5000-users" >> Sent: Monday, June 13, 2011 5:29:50 PM >> Subject: [Nek5000-users] hpts and pressure >> >> Hello Neks, >> >> I am trying to output pressure data at various points using the hpts >> routine. >> >> The values that are output for the first time step look ok, but all >> subsequent time steps seem to give garbage (i.e. the pressures given >> in hpts.out are way different that what is given by visualizing >> pressure in VisIt). I know previously that this was an issue for >> someone and it was thought that passive scalars may be messing the >> hpts output up, but in my case I don't output temperature or pressure. >> >> I looked at the hpts routine and noticed that it uses pm1 when it is >> stacking the field variables into the working array. Since I am using >> a Pn-Pn-2 formulation for my case, do I need to use the mappr >> subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 >> before calling hpts()? >> >> I'm assuming the issue arises because I am calling hpts more >> frequently than I am outputing field files, and thus perhaps pm1 isn't >> properly being updated (or perhaps it may have already been >> destroyed). >> >> Thanks, >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> 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 >> > > > > -- > Josh Camp > > "All that is necessary for the triumph of evil is that good men do > nothing" -- Edmund Burke > _______________________________________________ > 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 Tue Jun 14 13:27:21 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Jun 2011 13:27:21 -0500 (CDT) Subject: [Nek5000-users] hpts and pressure In-Reply-To: References: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Message-ID: Josh, Stefan, Correct... we should just add the map to the hpts routine. Maybe Katie can take care of this. Thanks for raising this issue! Paul On Tue, 14 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi > > You are right, the pressure is not mapped automatically. This issue > was already discussed in > https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-May/000584.html. > At the moment there is only a trigger to map the pressure in case we > are dumping a field file > > @Paul: I am not sure where we should trigger the pressure mapping but > the way it's implement now is error prone. > > -Stefan > > On 6/14/11, nek5000-users at lists.mcs.anl.gov > wrote: >> Hello, >> >> It appears my hypothesis was correct. I post the following for >> reference to any users who run into the same issue in the future (and >> I apologize in advance if this question has already been answered >> before, I didn't see anything in my search, but that doesn't mean it >> wasn't there). >> >> 1) I included the following in the variable declarations of userchk() >> >> common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure >> real pa(lx1,ly2,lz2), pb(lx1,ly1,lz2) ! Working arrays for mappr >> >> 2) Then, before I call hpts, I call mappr >> >> if (mod(istep,10).eq.0) then ! Only call this every 10th step >> call mappr(pm1,pr,pa,pb) ! Map pressure first >> call hpts >> endif >> >> For my case, I didn't want to call hpts every time step to prevent >> hpts.out from becoming too large. >> >> I haven't run this for too long, but on a preliminary basis the >> results look good. It seems that the scrcg common block must be >> included in userchk for this to work, as pm1 isn't a part of any of >> the standard "include" files. >> >> Developers and other users, feel free to chime in if there is a more >> efficient or elegant solution to this problem. >> >> Thanks, >> >> Josh >> >> On Mon, Jun 13, 2011 at 6:42 PM, wrote: >>> Hi Josh, >>> >>> Yes, it seems to me that either htps() needs modification for Pn-Pn-2 >>> pressure points or pr() should be mapped to pm1() before calling htps() as >>> you suggested -- something along the lines for .not.ifsplit in >>> prepot.f:219 >>> >>> if (ifsplit) then >>> call copy(pm1,pr,ntot1) >>> else >>> do 1000 e=1,nelv >>> call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) >>> do 100 iz=1,nz2 >>> call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) >>> 100 continue >>> call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) >>> 1000 continue >>> endif >>> >>> Best, >>> Aleks >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: "nek5000-users" >>> Sent: Monday, June 13, 2011 5:29:50 PM >>> Subject: [Nek5000-users] hpts and pressure >>> >>> Hello Neks, >>> >>> I am trying to output pressure data at various points using the hpts >>> routine. >>> >>> The values that are output for the first time step look ok, but all >>> subsequent time steps seem to give garbage (i.e. the pressures given >>> in hpts.out are way different that what is given by visualizing >>> pressure in VisIt). I know previously that this was an issue for >>> someone and it was thought that passive scalars may be messing the >>> hpts output up, but in my case I don't output temperature or pressure. >>> >>> I looked at the hpts routine and noticed that it uses pm1 when it is >>> stacking the field variables into the working array. Since I am using >>> a Pn-Pn-2 formulation for my case, do I need to use the mappr >>> subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 >>> before calling hpts()? >>> >>> I'm assuming the issue arises because I am calling hpts more >>> frequently than I am outputing field files, and thus perhaps pm1 isn't >>> properly being updated (or perhaps it may have already been >>> destroyed). >>> >>> Thanks, >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Josh Camp >> >> "All that is necessary for the triumph of evil is that good men do >> nothing" -- Edmund Burke >> _______________________________________________ >> 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 Tue Jun 14 13:45:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Jun 2011 20:45:19 +0200 Subject: [Nek5000-users] hpts and pressure In-Reply-To: References: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Message-ID: Why not after the pressure solve every time step? I don't think it will add much. -Stefan On 6/14/11, nek5000-users at lists.mcs.anl.gov wrote: > > Josh, Stefan, > > Correct... we should just add the map to the hpts > routine. Maybe Katie can take care of this. > > Thanks for raising this issue! > > Paul > > > On Tue, 14 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi >> >> You are right, the pressure is not mapped automatically. This issue >> was already discussed in >> https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-May/000584.html. >> At the moment there is only a trigger to map the pressure in case we >> are dumping a field file >> >> @Paul: I am not sure where we should trigger the pressure mapping but >> the way it's implement now is error prone. >> >> -Stefan >> >> On 6/14/11, nek5000-users at lists.mcs.anl.gov >> wrote: >>> Hello, >>> >>> It appears my hypothesis was correct. I post the following for >>> reference to any users who run into the same issue in the future (and >>> I apologize in advance if this question has already been answered >>> before, I didn't see anything in my search, but that doesn't mean it >>> wasn't there). >>> >>> 1) I included the following in the variable declarations of userchk() >>> >>> common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure >>> real pa(lx1,ly2,lz2), pb(lx1,ly1,lz2) ! Working arrays for mappr >>> >>> 2) Then, before I call hpts, I call mappr >>> >>> if (mod(istep,10).eq.0) then ! Only call this every 10th step >>> call mappr(pm1,pr,pa,pb) ! Map pressure first >>> call hpts >>> endif >>> >>> For my case, I didn't want to call hpts every time step to prevent >>> hpts.out from becoming too large. >>> >>> I haven't run this for too long, but on a preliminary basis the >>> results look good. It seems that the scrcg common block must be >>> included in userchk for this to work, as pm1 isn't a part of any of >>> the standard "include" files. >>> >>> Developers and other users, feel free to chime in if there is a more >>> efficient or elegant solution to this problem. >>> >>> Thanks, >>> >>> Josh >>> >>> On Mon, Jun 13, 2011 at 6:42 PM, >>> wrote: >>>> Hi Josh, >>>> >>>> Yes, it seems to me that either htps() needs modification for Pn-Pn-2 >>>> pressure points or pr() should be mapped to pm1() before calling htps() >>>> as >>>> you suggested -- something along the lines for .not.ifsplit in >>>> prepot.f:219 >>>> >>>> if (ifsplit) then >>>> call copy(pm1,pr,ntot1) >>>> else >>>> do 1000 e=1,nelv >>>> call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) >>>> do 100 iz=1,nz2 >>>> call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) >>>> 100 continue >>>> call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) >>>> 1000 continue >>>> endif >>>> >>>> Best, >>>> Aleks >>>> >>>> >>>> ----- Original Message ----- >>>> From: nek5000-users at lists.mcs.anl.gov >>>> To: "nek5000-users" >>>> Sent: Monday, June 13, 2011 5:29:50 PM >>>> Subject: [Nek5000-users] hpts and pressure >>>> >>>> Hello Neks, >>>> >>>> I am trying to output pressure data at various points using the hpts >>>> routine. >>>> >>>> The values that are output for the first time step look ok, but all >>>> subsequent time steps seem to give garbage (i.e. the pressures given >>>> in hpts.out are way different that what is given by visualizing >>>> pressure in VisIt). I know previously that this was an issue for >>>> someone and it was thought that passive scalars may be messing the >>>> hpts output up, but in my case I don't output temperature or pressure. >>>> >>>> I looked at the hpts routine and noticed that it uses pm1 when it is >>>> stacking the field variables into the working array. Since I am using >>>> a Pn-Pn-2 formulation for my case, do I need to use the mappr >>>> subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 >>>> before calling hpts()? >>>> >>>> I'm assuming the issue arises because I am calling hpts more >>>> frequently than I am outputing field files, and thus perhaps pm1 isn't >>>> properly being updated (or perhaps it may have already been >>>> destroyed). >>>> >>>> Thanks, >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Josh Camp >>> >>> "All that is necessary for the triumph of evil is that good men do >>> nothing" -- Edmund Burke >>> _______________________________________________ >>> 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 > From nek5000-users at lists.mcs.anl.gov Tue Jun 14 14:34:31 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 14 Jun 2011 14:34:31 -0500 (CDT) Subject: [Nek5000-users] hpts and pressure In-Reply-To: References: <711953936.5272.1308008555327.JavaMail.root@zimbra.anl.gov> Message-ID: Yes - that would be a good place! On Tue, 14 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Why not after the pressure solve every time step? I don't think it > will add much. > -Stefan > > On 6/14/11, nek5000-users at lists.mcs.anl.gov > wrote: >> >> Josh, Stefan, >> >> Correct... we should just add the map to the hpts >> routine. Maybe Katie can take care of this. >> >> Thanks for raising this issue! >> >> Paul >> >> >> On Tue, 14 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi >>> >>> You are right, the pressure is not mapped automatically. This issue >>> was already discussed in >>> https://lists.mcs.anl.gov/mailman/htdig/nek5000-users/2010-May/000584.html. >>> At the moment there is only a trigger to map the pressure in case we >>> are dumping a field file >>> >>> @Paul: I am not sure where we should trigger the pressure mapping but >>> the way it's implement now is error prone. >>> >>> -Stefan >>> >>> On 6/14/11, nek5000-users at lists.mcs.anl.gov >>> wrote: >>>> Hello, >>>> >>>> It appears my hypothesis was correct. I post the following for >>>> reference to any users who run into the same issue in the future (and >>>> I apologize in advance if this question has already been answered >>>> before, I didn't see anything in my search, but that doesn't mean it >>>> wasn't there). >>>> >>>> 1) I included the following in the variable declarations of userchk() >>>> >>>> common /scrcg/ pm1(lx1,ly1,lz1,lelv) ! Mapped pressure >>>> real pa(lx1,ly2,lz2), pb(lx1,ly1,lz2) ! Working arrays for mappr >>>> >>>> 2) Then, before I call hpts, I call mappr >>>> >>>> if (mod(istep,10).eq.0) then ! Only call this every 10th step >>>> call mappr(pm1,pr,pa,pb) ! Map pressure first >>>> call hpts >>>> endif >>>> >>>> For my case, I didn't want to call hpts every time step to prevent >>>> hpts.out from becoming too large. >>>> >>>> I haven't run this for too long, but on a preliminary basis the >>>> results look good. It seems that the scrcg common block must be >>>> included in userchk for this to work, as pm1 isn't a part of any of >>>> the standard "include" files. >>>> >>>> Developers and other users, feel free to chime in if there is a more >>>> efficient or elegant solution to this problem. >>>> >>>> Thanks, >>>> >>>> Josh >>>> >>>> On Mon, Jun 13, 2011 at 6:42 PM, >>>> wrote: >>>>> Hi Josh, >>>>> >>>>> Yes, it seems to me that either htps() needs modification for Pn-Pn-2 >>>>> pressure points or pr() should be mapped to pm1() before calling htps() >>>>> as >>>>> you suggested -- something along the lines for .not.ifsplit in >>>>> prepot.f:219 >>>>> >>>>> if (ifsplit) then >>>>> call copy(pm1,pr,ntot1) >>>>> else >>>>> do 1000 e=1,nelv >>>>> call mxm (ixm21,nx1,pr(1,1,1,e),nx2,pa(1,1,1),nyz2) >>>>> do 100 iz=1,nz2 >>>>> call mxm (pa(1,1,iz),nx1,iytm21,ny2,pb(1,1,iz),ny1) >>>>> 100 continue >>>>> call mxm (pb(1,1,1),nxy1,iztm21,nz2,pm1(1,1,1,e),nz1) >>>>> 1000 continue >>>>> endif >>>>> >>>>> Best, >>>>> Aleks >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: nek5000-users at lists.mcs.anl.gov >>>>> To: "nek5000-users" >>>>> Sent: Monday, June 13, 2011 5:29:50 PM >>>>> Subject: [Nek5000-users] hpts and pressure >>>>> >>>>> Hello Neks, >>>>> >>>>> I am trying to output pressure data at various points using the hpts >>>>> routine. >>>>> >>>>> The values that are output for the first time step look ok, but all >>>>> subsequent time steps seem to give garbage (i.e. the pressures given >>>>> in hpts.out are way different that what is given by visualizing >>>>> pressure in VisIt). I know previously that this was an issue for >>>>> someone and it was thought that passive scalars may be messing the >>>>> hpts output up, but in my case I don't output temperature or pressure. >>>>> >>>>> I looked at the hpts routine and noticed that it uses pm1 when it is >>>>> stacking the field variables into the working array. Since I am using >>>>> a Pn-Pn-2 formulation for my case, do I need to use the mappr >>>>> subroutine in my usrchk to map the pressure from mesh 2 to mesh 1 >>>>> before calling hpts()? >>>>> >>>>> I'm assuming the issue arises because I am calling hpts more >>>>> frequently than I am outputing field files, and thus perhaps pm1 isn't >>>>> properly being updated (or perhaps it may have already been >>>>> destroyed). >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Josh Camp >>>>> >>>>> "All that is necessary for the triumph of evil is that good men do >>>>> nothing" -- Edmund Burke >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Josh Camp >>>> >>>> "All that is necessary for the triumph of evil is that good men do >>>> nothing" -- Edmund Burke >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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 Thu Jun 16 07:12:29 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Jun 2011 14:12:29 +0200 Subject: [Nek5000-users] Number of elements for 3D simulations Message-ID: <4DF9F32D.1010205@mech.kth.se> Hello, I wanted to ask if it would be possible to allow to run nekton with less than 3 elements in the z-direction. I run a lot of simulations for a spanwise homogeneous swept wing geometry. The baseflow can be obtained solving a 2D problem where the heat equation is solved as the spanwise momentum equation. However, I also want to study the stability of this flow and thus solve the linearised Navier-Stokes eq. for some modal disturbances, i.e. u(x,y,z) = u'(x,y)*exp(i*beta*z). If I would be able to resolve this mode with less than 3 elements in the spanwise direction it would save me a lot of computational time. Best regards, David From nek5000-users at lists.mcs.anl.gov Thu Jun 16 07:25:06 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Jun 2011 07:25:06 -0500 (CDT) Subject: [Nek5000-users] Number of elements for 3D simulations In-Reply-To: <4DF9F32D.1010205@mech.kth.se> References: <4DF9F32D.1010205@mech.kth.se> Message-ID: Hi David, You're refering to periodic, correct? Is your spanwise direction the "z" direction in the element? (really, what we call "t"...) We might be able to correct the issue for this particular case, assuming you don't have periodicity in the other directions. Paul On Thu, 16 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I wanted to ask if it would be possible to allow to run nekton with less > than 3 elements in the z-direction. I run a lot of simulations for a > spanwise homogeneous swept wing geometry. The baseflow can be obtained > solving a 2D problem where the heat equation is solved as the spanwise > momentum equation. However, I also want to study the stability of this > flow and thus solve the linearised Navier-Stokes eq. for some modal > disturbances, i.e. u(x,y,z) = u'(x,y)*exp(i*beta*z). If I would be able > to resolve this mode with less than 3 elements in the spanwise direction > it would save me a lot of computational time. > > Best regards, > > David > _______________________________________________ > 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 Thu Jun 16 07:43:23 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 16 Jun 2011 14:43:23 +0200 Subject: [Nek5000-users] Number of elements for 3D simulations In-Reply-To: References: <4DF9F32D.1010205@mech.kth.se> Message-ID: <4DF9FA6B.3080909@mech.kth.se> Hi Paul, yes, only my spanwise direction ("t") is periodic. David On 06/16/2011 02:25 PM, nek5000-users at lists.mcs.anl.gov wrote: > > Hi David, > > You're refering to periodic, correct? > > Is your spanwise direction the "z" direction in the element? (really, > what we call "t"...) > > We might be able to correct the issue for this particular case, > assuming you don't have periodicity in the other directions. > > Paul > > > On Thu, 16 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Hello, >> >> I wanted to ask if it would be possible to allow to run nekton with less >> than 3 elements in the z-direction. I run a lot of simulations for a >> spanwise homogeneous swept wing geometry. The baseflow can be obtained >> solving a 2D problem where the heat equation is solved as the spanwise >> momentum equation. However, I also want to study the stability of this >> flow and thus solve the linearised Navier-Stokes eq. for some modal >> disturbances, i.e. u(x,y,z) = u'(x,y)*exp(i*beta*z). If I would be able >> to resolve this mode with less than 3 elements in the spanwise direction >> it would save me a lot of computational time. >> >> Best regards, >> >> David >> _______________________________________________ >> 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 Jun 17 20:45:19 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 17 Jun 2011 20:45:19 -0500 (CDT) Subject: [Nek5000-users] Number of elements for 3D simulations In-Reply-To: <4DF9F32D.1010205@mech.kth.se> References: <4DF9F32D.1010205@mech.kth.se> Message-ID: Hi David, We've just updated the repo - I have one additional update to make, but in all likelihood the code now has the functionality you request. I've tested it on one case so far (aside from our std. buildbot suite). The code now supports the following bc: 'p ' for periodicity with the face, on the same element, that is opposite to the face having the 'p ' BC specification. Both of the opposing faces on th element must have 'p '. As I type this, I realize that this BC designation is not a viable long-term solution as it is error-prone. Hopefully within the next couple weeks we can fix the requisite codes so that one simply specifies 'P ' for this condition, just as would be done for the other periodicity condition. In any case, this should get you started. Cheers, Paul On Thu, 16 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hello, > > I wanted to ask if it would be possible to allow to run nekton with less > than 3 elements in the z-direction. I run a lot of simulations for a > spanwise homogeneous swept wing geometry. The baseflow can be obtained > solving a 2D problem where the heat equation is solved as the spanwise > momentum equation. However, I also want to study the stability of this > flow and thus solve the linearised Navier-Stokes eq. for some modal > disturbances, i.e. u(x,y,z) = u'(x,y)*exp(i*beta*z). If I would be able > to resolve this mode with less than 3 elements in the spanwise direction > it would save me a lot of computational time. > > Best regards, > > David > _______________________________________________ > 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 Jun 20 16:40:39 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 20 Jun 2011 17:40:39 -0400 Subject: [Nek5000-users] Multiple scalars Message-ID: Hi Neks, I`m trying to get nek running with a second scalar in addition to temperature, and my resulting .fld files are not correct, including the temperature field. Does anyone have experience with this? I have reason to believe that my issue is only with the output of the .fld files, and probably specifically with this part of the .rea file: 1 PASSIVE SCALARS T PS 1 I have run the shear4 example from repo, and I can visualize the correct temperature/ps1/ps2/ps3 fields in VisIt. Furthermore, when I change the line in my .rea file to 0 PASSIVE SCALARS I get a correct temperature in the .fld file, but of course no ps1 field. I would be greatful to hear from anyone who has dealt with multiple scalars. Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 20 17:08:28 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 20 Jun 2011 17:08:28 -0500 (CDT) Subject: [Nek5000-users] Multiple scalars In-Reply-To: References: Message-ID: Hi David, In the .rea file, be certain to set 1 NPSCAL T IFHEAT T T T T ... IFNAV etc and to have a set of BCs for FLUID TEMP PASSIVE SCALAR 1 I've just done this and it seems to work ok. www.mcs.anl.gov/~fischer/ps1.rea.gz Paul On Mon, 20 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > I`m trying to get nek running with a second scalar in addition to > temperature, and my resulting .fld files are not correct, including the > temperature field. Does anyone have experience with this? I have reason to > believe that my issue is only with the output of the .fld files, and > probably specifically with this part of the .rea file: > > 1 PASSIVE SCALARS > T PS 1 > > I have run the shear4 example from repo, and I can visualize the correct > temperature/ps1/ps2/ps3 fields in VisIt. Furthermore, when I change the > line in my .rea file to > > 0 PASSIVE SCALARS > > I get a correct temperature in the .fld file, but of course no ps1 field. > > I would be greatful to hear from anyone who has dealt with multiple scalars. > > Best, > > David > From nek5000-users at lists.mcs.anl.gov Mon Jun 20 18:49:24 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 20 Jun 2011 19:49:24 -0400 Subject: [Nek5000-users] Multiple scalars In-Reply-To: References: Message-ID: Hi Paul, Thanks, your example file helped me find my mistake. I was outputting an initial .fld file that contained only the temperature scalar, due to a vestigial outpost call in the .usr file. Then, although the next .fld file contained the geometry, T, and PS1, VisIt was confused. I have fixed this, but it leads me to wonder: does outpost only work for a single scalar? Also, what is the meaning of the IFNAV & IFADVC boolean array in the .rea file? Best, David On Mon, Jun 20, 2011 at 6:08 PM, wrote: > > Hi David, > > In the .rea file, be certain to set > > 1 NPSCAL > > T IFHEAT > > T T T T ... IFNAV etc > > and to have a set of BCs for > > FLUID > TEMP > PASSIVE SCALAR 1 > > I've just done this and it seems to work ok. > > www.mcs.anl.gov/~fischer/ps1.**rea.gz > > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 20 19:32:00 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 20 Jun 2011 19:32:00 -0500 (CDT) Subject: [Nek5000-users] Multiple scalars In-Reply-To: References: Message-ID: Hi David, The output in .fld/.f files work for multiple passive scalars -- 9 for .fld & 99 for .f A way to setup, say for 3 passive output fields is to specify .rea: 3 PASSIVE SCALARS T PS 1 T PS 2 T PS 3 The boolean areas IFNAV & IFADVC set Nek5000 for solving w/ non-linear/advecting terms for Navier-Stokes and advection-diffusion equations for temperature/passive scalars -- otherwise there just Stokes/unsteady solves. Best, Aleks On Mon, 20 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks, your example file helped me find my mistake. I was outputting an > initial .fld file that contained only the temperature scalar, due to a > vestigial outpost call in the .usr file. Then, although the next .fld file > contained the geometry, T, and PS1, VisIt was confused. > > I have fixed this, but it leads me to wonder: does outpost only work for a > single scalar? > > Also, what is the meaning of the IFNAV & IFADVC boolean array in the .rea > file? > > Best, > > David > > > On Mon, Jun 20, 2011 at 6:08 PM, wrote: > >> >> Hi David, >> >> In the .rea file, be certain to set >> >> 1 NPSCAL >> >> T IFHEAT >> >> T T T T ... IFNAV etc >> >> and to have a set of BCs for >> >> FLUID >> TEMP >> PASSIVE SCALAR 1 >> >> I've just done this and it seems to work ok. >> >> www.mcs.anl.gov/~fischer/ps1.**rea.gz >> >> >> Paul >> >> > From nek5000-users at lists.mcs.anl.gov Mon Jun 20 19:34:38 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 20 Jun 2011 19:34:38 -0500 (CDT) Subject: [Nek5000-users] Multiple scalars In-Reply-To: References: Message-ID: Hi David, Use outpost2 for passive scalars... To find the usage model, cd to the nek5000 source directory and: grep -i outpost2 *.f Paul On Mon, 20 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Thanks, your example file helped me find my mistake. I was outputting an > initial .fld file that contained only the temperature scalar, due to a > vestigial outpost call in the .usr file. Then, although the next .fld file > contained the geometry, T, and PS1, VisIt was confused. > > I have fixed this, but it leads me to wonder: does outpost only work for a > single scalar? > > Also, what is the meaning of the IFNAV & IFADVC boolean array in the .rea > file? > > Best, > > David > > > On Mon, Jun 20, 2011 at 6:08 PM, wrote: > >> >> Hi David, >> >> In the .rea file, be certain to set >> >> 1 NPSCAL >> >> T IFHEAT >> >> T T T T ... IFNAV etc >> >> and to have a set of BCs for >> >> FLUID >> TEMP >> PASSIVE SCALAR 1 >> >> I've just done this and it seems to work ok. >> >> www.mcs.anl.gov/~fischer/ps1.**rea.gz >> >> >> Paul >> >> > From nek5000-users at lists.mcs.anl.gov Tue Jun 21 10:45:36 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 21 Jun 2011 17:45:36 +0200 Subject: [Nek5000-users] Adjoint perturbation In-Reply-To: References: Message-ID: Hi Nek's, I have seen the adjoint perturbation mode has been added to the current. Where/how do I have to specify ifadj = .true. if I want to use it? Is there some parameters in the .rea file like for direct perturbation mode? Sincerely, On 9 June 2011 11:50, Jean-Christophe Loiseau wrote: > Hi Neks, > > I was just wondering if the adjoint linear solver has already been released > in the current repo or not? > > Regards, > > > On 6 May 2011 15:49, wrote: > >> >> >> Dear Jean-Christophe, >> >> My apologies for the delay in getting back to you - we've been >> saturated with proposal writing on our end. >> >> Your approach looks reasonable -- though I would avoid at all >> costs the f90 type declarations and stick with the std f77-based >> approach to be consistent with the code. >> >> I'll look into your proposed approach. I should point out also >> that we've recently had an adjoint solver developed by some colleagues >> that is ready to go into the svn repo. I've just >> been delayed in getting it in because of travel and proposals. >> My hope is that this will be in the repo in about 10-15 days. >> >> Regarding the proper choice of gradm1 vs wgradm1, the question >> ultimately comes down to the degree of differentiability of the >> input --- functions in nek are only C0 and hence one-time differentiable. >> This applies also to the test functions. Thus, the std. practice >> is to move a derivative from the solution to the test functions (i.e., >> to use the weak derivative) whenever the solution is to be differentiated >> twice. >> >> Regards, >> >> Paul >> >> >> >> >> >> On Thu, 5 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >> Hi Nek's, >>> >>> >>> I am interested into the linear adjoint perturbation. The equations read: >>> >>> -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) >>> >>> div(u) = 0 >>> >>> Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - >>> transpose(Grad(U)) >>> u + 1/Re Laplacian(u) - grad(p) >>> Only small modifications to the perturbation mode are necessary, mainly >>> to >>> evaluate the tranpose gradient terms. Here is what I've done to evaluate >>> these: >>> >>> subroutine conv_adj(conv_x,conv_y,conv_z,u_x,u_y,u_z) ! used to be >>> conv1n >>> >>> >>> include 'SIZE' >>> >>> include 'DXYZ' >>> >>> include 'INPUT' >>> >>> include 'GEOM' >>> >>> include 'SOLN' >>> >>> include 'TSTEP' >>> >>> >>> parameter (lt=lx1*ly1*lz1*lelt) >>> >>> real u_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> real u_y (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> real u_z (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> >>> real u_xx (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> real u_xy (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> real u_xz (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> >>> real u_yx (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>> >>> real u_yy (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>> >>> real u_yz (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>> >>> >>> real u_zx (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>> >>> real u_zy (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>> >>> real u_zz (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>> >>> >>> real conv_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>> >>> real conv_y (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>> >>> real conv_z (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>> >>> >>> *call gradm1(u_xx,u_xy,u_xz,u_x)* >>> >>> * call gradm1(u_yx,u_yy,u_yz,u_y)* >>> >>> * call gradm1(u_zx,u_zy,u_zz,u_z)* >>> >>> * >>> * >>> >>> * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* >>> >>> * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* >>> >>> * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* >>> >>> >>> return >>> >>> end >>> >>> However, I'm not sure I've done it properly or not (arrays declaration >>> for >>> instance). Especially, I had no idea wheter I have to use the gradm1 >>> subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've >>> slightly change the advap subroutine the following way: >>> >>> subroutine advabp >>> >>> C >>> >>> C Eulerian scheme, add convection term to forcing function >>> >>> C at current time step. >>> >>> C >>> >>> include 'SIZE' >>> >>> include 'INPUT' >>> >>> include 'SOLN' >>> >>> include 'MASS' >>> >>> include 'TSTEP' >>> >>> C >>> >>> COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) >>> >>> $ , TA2 (LX1*LY1*LZ1*LELV) >>> >>> $ , TA3 (LX1*LY1*LZ1*LELV) >>> >>> $ , TB1 (LX1*LY1*LZ1*LELV) >>> >>> $ , TB2 (LX1*LY1*LZ1*LELV) >>> >>> $ , TB3 (LX1*LY1*LZ1*LELV) >>> >>> C >>> >>> ntot1 = nx1*ny1*nz1*nelv >>> >>> ntot2 = nx2*ny2*nz2*nelv >>> >>> c >>> >>> if (if3d) then >>> >>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>> velocity >>> >>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- du >>> >>> * call conv_adj(ta1,ta2,ta3,tb1,tb2,tb3)* >>> >>> * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* >>> >>> *c* >>> >>> * do i=1,ntot1* >>> >>> * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield)* >>> >>> * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* >>> >>> * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* >>> >>> * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* >>> >>> * enddo* >>> >>> c >>> >>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>> >>> call convop (ta2,vyp(1,jp)) >>> >>> call convop (ta3,vzp(1,jp)) >>> >>> c >>> >>> do i=1,ntot1 >>> >>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>> >>> *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* >>> >>> * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* >>> >>> * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* >>> >>> enddo >>> >>> c >>> >>> else ! 2D >>> >>> c >>> >>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>> velocity >>> >>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- dU >>> >>> call convop (ta1,tb1) ! du.grad U >>> >>> call convop (ta2,tb2) >>> >>> call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity >>> >>> c >>> >>> do i=1,ntot1 >>> >>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>> >>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>> >>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>> >>> enddo >>> >>> c >>> >>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>> >>> call convop (ta2,vyp(1,jp)) >>> >>> c >>> >>> do i=1,ntot1 >>> >>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>> >>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>> >>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>> >>> enddo >>> >>> c >>> >>> endif >>> >>> c >>> >>> return >>> >>> end >>> >>> >>> Any help to spot potential erros or to speed up these operation would be >>> highly appreciated. >>> >>> Best regards, >>> -- >>> Jean-Christophe >>> >>> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > > > > -- > Jean-Christophe > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 21 13:47:59 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 21 Jun 2011 13:47:59 -0500 (CDT) Subject: [Nek5000-users] Adjoint perturbation In-Reply-To: References: Message-ID: Hi Jean-Christophe, It looks like the only place in the code where ifadj shows up is in perturb.f:107 if (ifnav.and.(.not.ifchar).and.( ifadj))call advabp_adjoint so you can set ifadj=.true. somewhere in userchk or usrdat -- just make that you also add include 'ADJOINT' there which is not part of 'TOTAL' Best, Aleks On Tue, 21 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I have seen the adjoint perturbation mode has been added to the current. > Where/how do I have to specify ifadj = .true. if I want to use it? Is there > some parameters in the .rea file like for direct perturbation mode? > > Sincerely, > > On 9 June 2011 11:50, Jean-Christophe Loiseau wrote: > >> Hi Neks, >> >> I was just wondering if the adjoint linear solver has already been released >> in the current repo or not? >> >> Regards, >> >> >> On 6 May 2011 15:49, wrote: >> >>> >>> >>> Dear Jean-Christophe, >>> >>> My apologies for the delay in getting back to you - we've been >>> saturated with proposal writing on our end. >>> >>> Your approach looks reasonable -- though I would avoid at all >>> costs the f90 type declarations and stick with the std f77-based >>> approach to be consistent with the code. >>> >>> I'll look into your proposed approach. I should point out also >>> that we've recently had an adjoint solver developed by some colleagues >>> that is ready to go into the svn repo. I've just >>> been delayed in getting it in because of travel and proposals. >>> My hope is that this will be in the repo in about 10-15 days. >>> >>> Regarding the proper choice of gradm1 vs wgradm1, the question >>> ultimately comes down to the degree of differentiability of the >>> input --- functions in nek are only C0 and hence one-time differentiable. >>> This applies also to the test functions. Thus, the std. practice >>> is to move a derivative from the solution to the test functions (i.e., >>> to use the weak derivative) whenever the solution is to be differentiated >>> twice. >>> >>> Regards, >>> >>> Paul >>> >>> >>> >>> >>> >>> On Thu, 5 May 2011, nek5000-users at lists.mcs.anl.gov wrote: >>> >>> Hi Nek's, >>>> >>>> >>>> I am interested into the linear adjoint perturbation. The equations read: >>>> >>>> -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - grad(p) >>>> >>>> div(u) = 0 >>>> >>>> Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - >>>> transpose(Grad(U)) >>>> u + 1/Re Laplacian(u) - grad(p) >>>> Only small modifications to the perturbation mode are necessary, mainly >>>> to >>>> evaluate the tranpose gradient terms. Here is what I've done to evaluate >>>> these: >>>> >>>> subroutine conv_adj(conv_x,conv_y,conv_z,u_x,u_y,u_z) ! used to be >>>> conv1n >>>> >>>> >>>> include 'SIZE' >>>> >>>> include 'DXYZ' >>>> >>>> include 'INPUT' >>>> >>>> include 'GEOM' >>>> >>>> include 'SOLN' >>>> >>>> include 'TSTEP' >>>> >>>> >>>> parameter (lt=lx1*ly1*lz1*lelt) >>>> >>>> real u_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> real u_y (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> real u_z (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> >>>> real u_xx (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> real u_xy (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> real u_xz (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> >>>> real u_yx (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>>> >>>> real u_yy (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>>> >>>> real u_yz (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>>> >>>> >>>> real u_zx (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>>> >>>> real u_zy (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>>> >>>> real u_zz (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>>> >>>> >>>> real conv_x (size(vx,1),size(vx,2),size(vx,3),size(vx,4)) >>>> >>>> real conv_y (size(vy,1),size(vy,2),size(vy,3),size(vy,4)) >>>> >>>> real conv_z (size(vz,1),size(vz,2),size(vz,3),size(vz,4)) >>>> >>>> >>>> *call gradm1(u_xx,u_xy,u_xz,u_x)* >>>> >>>> * call gradm1(u_yx,u_yy,u_yz,u_y)* >>>> >>>> * call gradm1(u_zx,u_zy,u_zz,u_z)* >>>> >>>> * >>>> * >>>> >>>> * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* >>>> >>>> * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* >>>> >>>> * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* >>>> >>>> >>>> return >>>> >>>> end >>>> >>>> However, I'm not sure I've done it properly or not (arrays declaration >>>> for >>>> instance). Especially, I had no idea wheter I have to use the gradm1 >>>> subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've >>>> slightly change the advap subroutine the following way: >>>> >>>> subroutine advabp >>>> >>>> C >>>> >>>> C Eulerian scheme, add convection term to forcing function >>>> >>>> C at current time step. >>>> >>>> C >>>> >>>> include 'SIZE' >>>> >>>> include 'INPUT' >>>> >>>> include 'SOLN' >>>> >>>> include 'MASS' >>>> >>>> include 'TSTEP' >>>> >>>> C >>>> >>>> COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) >>>> >>>> $ , TA2 (LX1*LY1*LZ1*LELV) >>>> >>>> $ , TA3 (LX1*LY1*LZ1*LELV) >>>> >>>> $ , TB1 (LX1*LY1*LZ1*LELV) >>>> >>>> $ , TB2 (LX1*LY1*LZ1*LELV) >>>> >>>> $ , TB3 (LX1*LY1*LZ1*LELV) >>>> >>>> C >>>> >>>> ntot1 = nx1*ny1*nz1*nelv >>>> >>>> ntot2 = nx2*ny2*nz2*nelv >>>> >>>> c >>>> >>>> if (if3d) then >>>> >>>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>>> velocity >>>> >>>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- du >>>> >>>> * call conv_adj(ta1,ta2,ta3,tb1,tb2,tb3)* >>>> >>>> * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* >>>> >>>> *c* >>>> >>>> * do i=1,ntot1* >>>> >>>> * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield)* >>>> >>>> * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* >>>> >>>> * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* >>>> >>>> * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* >>>> >>>> * enddo* >>>> >>>> c >>>> >>>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>>> >>>> call convop (ta2,vyp(1,jp)) >>>> >>>> call convop (ta3,vzp(1,jp)) >>>> >>>> c >>>> >>>> do i=1,ntot1 >>>> >>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>>> >>>> *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* >>>> >>>> * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* >>>> >>>> * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* >>>> >>>> enddo >>>> >>>> c >>>> >>>> else ! 2D >>>> >>>> c >>>> >>>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>>> velocity >>>> >>>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),vzp(1,jp)) ! U <-- dU >>>> >>>> call convop (ta1,tb1) ! du.grad U >>>> >>>> call convop (ta2,tb2) >>>> >>>> call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity >>>> >>>> c >>>> >>>> do i=1,ntot1 >>>> >>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>>> >>>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>>> >>>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>>> >>>> enddo >>>> >>>> c >>>> >>>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>>> >>>> call convop (ta2,vyp(1,jp)) >>>> >>>> c >>>> >>>> do i=1,ntot1 >>>> >>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,ifield) >>>> >>>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>>> >>>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>>> >>>> enddo >>>> >>>> c >>>> >>>> endif >>>> >>>> c >>>> >>>> return >>>> >>>> end >>>> >>>> >>>> Any help to spot potential erros or to speed up these operation would be >>>> highly appreciated. >>>> >>>> Best regards, >>>> -- >>>> Jean-Christophe >>>> >>>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> >> >> >> -- >> Jean-Christophe >> > > > > -- > Jean-Christophe > From nek5000-users at lists.mcs.anl.gov Tue Jun 21 17:41:21 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 22 Jun 2011 00:41:21 +0200 Subject: [Nek5000-users] Adjoint perturbation In-Reply-To: References: Message-ID: Ah alright, I forgot to include 'ADJOINT'. Fair enough then, I'll try again tomorrow morning. Thans a lots. On 21 June 2011 20:47, wrote: > Hi Jean-Christophe, > > > It looks like the only place in the code where ifadj shows up is in > perturb.f:107 > > if (ifnav.and.(.not.ifchar).and.( ifadj))call advabp_adjoint > > so you can set ifadj=.true. somewhere in userchk or usrdat -- just make > that you also add > > include 'ADJOINT' > > there which is not part of 'TOTAL' > > Best, > Aleks > > > > > On Tue, 21 Jun 2011, nek5000-users at lists.mcs.anl.**govwrote: > > Hi Nek's, >> >> I have seen the adjoint perturbation mode has been added to the current. >> Where/how do I have to specify ifadj = .true. if I want to use it? Is >> there >> some parameters in the .rea file like for direct perturbation mode? >> >> Sincerely, >> >> On 9 June 2011 11:50, Jean-Christophe Loiseau >> wrote: >> >> Hi Neks, >>> >>> I was just wondering if the adjoint linear solver has already been >>> released >>> in the current repo or not? >>> >>> Regards, >>> >>> >>> On 6 May 2011 15:49, > >>> wrote: >>> >>> >>>> >>>> Dear Jean-Christophe, >>>> >>>> My apologies for the delay in getting back to you - we've been >>>> saturated with proposal writing on our end. >>>> >>>> Your approach looks reasonable -- though I would avoid at all >>>> costs the f90 type declarations and stick with the std f77-based >>>> approach to be consistent with the code. >>>> >>>> I'll look into your proposed approach. I should point out also >>>> that we've recently had an adjoint solver developed by some colleagues >>>> that is ready to go into the svn repo. I've just >>>> been delayed in getting it in because of travel and proposals. >>>> My hope is that this will be in the repo in about 10-15 days. >>>> >>>> Regarding the proper choice of gradm1 vs wgradm1, the question >>>> ultimately comes down to the degree of differentiability of the >>>> input --- functions in nek are only C0 and hence one-time >>>> differentiable. >>>> This applies also to the test functions. Thus, the std. practice >>>> is to move a derivative from the solution to the test functions (i.e., >>>> to use the weak derivative) whenever the solution is to be >>>> differentiated >>>> twice. >>>> >>>> Regards, >>>> >>>> Paul >>>> >>>> >>>> >>>> >>>> >>>> On Thu, 5 May 2011, nek5000-users at lists.mcs.anl.**govwrote: >>>> >>>> Hi Nek's, >>>> >>>>> >>>>> >>>>> I am interested into the linear adjoint perturbation. The equations >>>>> read: >>>>> >>>>> -du/dt = (U.Grad) u - transpose(Grad(U)) u + 1/Re Laplacian(u) - >>>>> grad(p) >>>>> >>>>> div(u) = 0 >>>>> >>>>> Assuming t' = T-t, one can rewrite: du/dt' = (U.Grad) u - >>>>> transpose(Grad(U)) >>>>> u + 1/Re Laplacian(u) - grad(p) >>>>> Only small modifications to the perturbation mode are necessary, mainly >>>>> to >>>>> evaluate the tranpose gradient terms. Here is what I've done to >>>>> evaluate >>>>> these: >>>>> >>>>> subroutine conv_adj(conv_x,conv_y,conv_z,**u_x,u_y,u_z) ! used to >>>>> be >>>>> conv1n >>>>> >>>>> >>>>> include 'SIZE' >>>>> >>>>> include 'DXYZ' >>>>> >>>>> include 'INPUT' >>>>> >>>>> include 'GEOM' >>>>> >>>>> include 'SOLN' >>>>> >>>>> include 'TSTEP' >>>>> >>>>> >>>>> parameter (lt=lx1*ly1*lz1*lelt) >>>>> >>>>> real u_x (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> real u_y (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> real u_z (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> >>>>> real u_xx (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> real u_xy (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> real u_xz (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> >>>>> real u_yx (size(vy,1),size(vy,2),size(**vy,3),size(vy,4)) >>>>> >>>>> real u_yy (size(vy,1),size(vy,2),size(**vy,3),size(vy,4)) >>>>> >>>>> real u_yz (size(vy,1),size(vy,2),size(**vy,3),size(vy,4)) >>>>> >>>>> >>>>> real u_zx (size(vz,1),size(vz,2),size(**vz,3),size(vz,4)) >>>>> >>>>> real u_zy (size(vz,1),size(vz,2),size(**vz,3),size(vz,4)) >>>>> >>>>> real u_zz (size(vz,1),size(vz,2),size(**vz,3),size(vz,4)) >>>>> >>>>> >>>>> real conv_x (size(vx,1),size(vx,2),size(**vx,3),size(vx,4)) >>>>> >>>>> real conv_y (size(vy,1),size(vy,2),size(**vy,3),size(vy,4)) >>>>> >>>>> real conv_z (size(vz,1),size(vz,2),size(**vz,3),size(vz,4)) >>>>> >>>>> >>>>> *call gradm1(u_xx,u_xy,u_xz,u_x)* >>>>> >>>>> * call gradm1(u_yx,u_yy,u_yz,u_y)* >>>>> >>>>> * call gradm1(u_zx,u_zy,u_zz,u_z)* >>>>> >>>>> * >>>>> * >>>>> >>>>> * conv_x = vx*u_xx + vy*u_yx + vz*u_zx* >>>>> >>>>> * conv_y = vx*u_xy + vy*u_yy + vz*u_zy* >>>>> >>>>> * conv_z = vx*u_xz + vy*u_yz + vz*u_zz* >>>>> >>>>> >>>>> return >>>>> >>>>> end >>>>> >>>>> However, I'm not sure I've done it properly or not (arrays declaration >>>>> for >>>>> instance). Especially, I had no idea wheter I have to use the gradm1 >>>>> subroutine or its weak counterpart wgradm1. Finally in perturb.f, I've >>>>> slightly change the advap subroutine the following way: >>>>> >>>>> subroutine advabp >>>>> >>>>> C >>>>> >>>>> C Eulerian scheme, add convection term to forcing function >>>>> >>>>> C at current time step. >>>>> >>>>> C >>>>> >>>>> include 'SIZE' >>>>> >>>>> include 'INPUT' >>>>> >>>>> include 'SOLN' >>>>> >>>>> include 'MASS' >>>>> >>>>> include 'TSTEP' >>>>> >>>>> C >>>>> >>>>> COMMON /SCRNS/ TA1 (LX1*LY1*LZ1*LELV) >>>>> >>>>> $ , TA2 (LX1*LY1*LZ1*LELV) >>>>> >>>>> $ , TA3 (LX1*LY1*LZ1*LELV) >>>>> >>>>> $ , TB1 (LX1*LY1*LZ1*LELV) >>>>> >>>>> $ , TB2 (LX1*LY1*LZ1*LELV) >>>>> >>>>> $ , TB3 (LX1*LY1*LZ1*LELV) >>>>> >>>>> C >>>>> >>>>> ntot1 = nx1*ny1*nz1*nelv >>>>> >>>>> ntot2 = nx2*ny2*nz2*nelv >>>>> >>>>> c >>>>> >>>>> if (if3d) then >>>>> >>>>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>>>> velocity >>>>> >>>>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),**vzp(1,jp)) ! U <-- >>>>> du >>>>> >>>>> * call conv_adj(ta1,ta2,ta3,tb1,tb2,**tb3)* >>>>> >>>>> * call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity* >>>>> >>>>> *c* >>>>> >>>>> * do i=1,ntot1* >>>>> >>>>> * tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,**ifield)* >>>>> >>>>> * bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i)* >>>>> >>>>> * bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i)* >>>>> >>>>> * bfzp(i,jp) = bfzp(i,jp)-tmp*ta3(i)* >>>>> >>>>> * enddo* >>>>> >>>>> c >>>>> >>>>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>>>> >>>>> call convop (ta2,vyp(1,jp)) >>>>> >>>>> call convop (ta3,vzp(1,jp)) >>>>> >>>>> c >>>>> >>>>> do i=1,ntot1 >>>>> >>>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,**ifield) >>>>> >>>>> *bfxp(i,jp) = bfxp(i,jp) + tmp*ta1(i)* >>>>> >>>>> * bfyp(i,jp) = bfyp(i,jp) + tmp*ta2(i)* >>>>> >>>>> * bfzp(i,jp) = bfzp(i,jp) + tmp*ta3(i)* >>>>> >>>>> enddo >>>>> >>>>> c >>>>> >>>>> else ! 2D >>>>> >>>>> c >>>>> >>>>> call opcopy (tb1,tb2,tb3,vx,vy,vz) ! Save >>>>> velocity >>>>> >>>>> call opcopy (vx,vy,vz,vxp(1,jp),vyp(1,jp),**vzp(1,jp)) ! U <-- >>>>> dU >>>>> >>>>> call convop (ta1,tb1) ! du.grad U >>>>> >>>>> call convop (ta2,tb2) >>>>> >>>>> call opcopy (vx,vy,vz,tb1,tb2,tb3) ! Restore velocity >>>>> >>>>> c >>>>> >>>>> do i=1,ntot1 >>>>> >>>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,**ifield) >>>>> >>>>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>>>> >>>>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>>>> >>>>> enddo >>>>> >>>>> c >>>>> >>>>> call convop (ta1,vxp(1,jp)) ! U.grad dU >>>>> >>>>> call convop (ta2,vyp(1,jp)) >>>>> >>>>> c >>>>> >>>>> do i=1,ntot1 >>>>> >>>>> tmp = bm1(i,1,1,1)*vtrans(i,1,1,1,**ifield) >>>>> >>>>> bfxp(i,jp) = bfxp(i,jp)-tmp*ta1(i) >>>>> >>>>> bfyp(i,jp) = bfyp(i,jp)-tmp*ta2(i) >>>>> >>>>> enddo >>>>> >>>>> c >>>>> >>>>> endif >>>>> >>>>> c >>>>> >>>>> return >>>>> >>>>> end >>>>> >>>>> >>>>> Any help to spot potential erros or to speed up these operation would >>>>> be >>>>> highly appreciated. >>>>> >>>>> Best regards, >>>>> -- >>>>> Jean-Christophe >>>>> >>>>> ______________________________**_________________ >>>>> >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.**gov >>>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >>>> >>>> >>> >>> >>> -- >>> Jean-Christophe >>> >>> >> >> >> -- >> Jean-Christophe >> >> ______________________________**_________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.**gov > https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users > -- Jean-Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jun 26 08:10:35 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 26 Jun 2011 15:10:35 +0200 Subject: [Nek5000-users] CYCLIC BC for bend pipe Message-ID: <1309093835.28280.14.camel@damavand.mech.kth.se> Dear Neks; I had a question regarding cyclic bc. It works properly for 2D and 3D curved channel, (arch-like curvature is generated in stream-wise direction using userdat2 with period bc at the both ends). However, when I try it for the curved pipe, seems not working at all. I appreciate it if you could help me by that. Many thanks; Azad From nek5000-users at lists.mcs.anl.gov Sun Jun 26 08:20:17 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 26 Jun 2011 08:20:17 -0500 (CDT) Subject: [Nek5000-users] CYCLIC BC for bend pipe In-Reply-To: <1309093835.28280.14.camel@damavand.mech.kth.se> References: <1309093835.28280.14.camel@damavand.mech.kth.se> Message-ID: Hi Azad, It's important that the "cyclic" axis be the z-axis. You may need to rotate your geometry into this orientation. In that case, your inlet/out planes would, say, be x-z and y-z planes. Paul On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks; > > I had a question regarding cyclic bc. It works properly for 2D and 3D > curved channel, (arch-like curvature is generated in stream-wise > direction using userdat2 with period bc at the both ends). However, when > I try it for the curved pipe, seems not working at all. I appreciate it > if you could help me by that. > > Many thanks; > Azad > > > _______________________________________________ > 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 Sun Jun 26 09:09:10 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 26 Jun 2011 09:09:10 -0500 (CDT) Subject: [Nek5000-users] CYCLIC BC for bend pipe In-Reply-To: References: <1309093835.28280.14.camel@damavand.mech.kth.se> Message-ID: PS - be sure that the rotation preserves the right-handed coordinates of the original system. On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Azad, > > It's important that the "cyclic" axis be the z-axis. > > You may need to rotate your geometry into this orientation. > > In that case, your inlet/out planes would, say, be x-z > and y-z planes. > > Paul > > > On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Neks; >> >> I had a question regarding cyclic bc. It works properly for 2D and 3D >> curved channel, (arch-like curvature is generated in stream-wise >> direction using userdat2 with period bc at the both ends). However, when >> I try it for the curved pipe, seems not working at all. I appreciate it >> if you could help me by that. >> >> Many thanks; >> Azad >> >> >> _______________________________________________ >> 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 Sun Jun 26 10:50:12 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 26 Jun 2011 17:50:12 +0200 Subject: [Nek5000-users] Re : CYCLIC BC for bend pipe Message-ID: <1309103412.28280.23.camel@damavand.mech.kth.se> Hi Paul; Since I am using Prenek to generate the base mesh for the pipe in X-Y plane, and then extrude it in the Z direction using the n2to3 tool, is there any easy way to change the orientation of such a mesh based on your suggestion? Or maybe I need to start generating the grid from the very beginning in X-Z plane? Best regards Azad PS - be sure that the rotation preserves the right-handed coordinates of the original system. On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Azad, > > It's important that the "cyclic" axis be the z-axis. > > You may need to rotate your geometry into this orientation. > > In that case, your inlet/out planes would, say, be x-z > and y-z planes. > > Paul > > > On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Neks; >> >> I had a question regarding cyclic bc. It works properly for 2D and 3D >> curved channel, (arch-like curvature is generated in stream-wise >> direction using userdat2 with period bc at the both ends). However, when >> I try it for the curved pipe, seems not working at all. I appreciate it >> if you could help me by that. >> >> Many thanks; >> Azad >> >> From nek5000-users at lists.mcs.anl.gov Sun Jun 26 13:10:25 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 26 Jun 2011 13:10:25 -0500 (CDT) Subject: [Nek5000-users] Re : CYCLIC BC for bend pipe In-Reply-To: <1309103412.28280.23.camel@damavand.mech.kth.se> References: <1309103412.28280.23.camel@damavand.mech.kth.se> Message-ID: Hi Azad, Yes - you can do this in usrdat2. Below is an example that would put a 90 degree semicircular arc into the x-y plane, which is what you would need. (Note, I just coded this without testing it..., so you'll need to verify and obviously modify to get your correct geometry.) Cheers, Paul c----------------------------------------------------------------------- subroutine usrdat2 include 'SIZE' include 'TOTAL' n = nx1*ny1*nz1*nelv c First, rotate x into axial position do i=1,n x_original = xm1(i,1,1,1) y_original = ym1(i,1,1,1) z_original = zm1(i,1,1,1) xm1(i,1,1,1) = z_original ym1(i,1,1,1) = y_original zm1(i,1,1,1) = -x_original enddo c Second, bend pipe into 90 degree bend (say) xmin = glmin(xm1,n) xmax = glmax(xm1,n) ymin = glmin(ym1,n) ymax = glmax(ym1,n) rad0 = .5*(ymax-ymin) ! Radius of initial pipe rad1 = 0.5 ! Radius of new pipe (say) radm = 1.5 ! Major radius of torus do i=1,n x = xm1(i,1,1,1) y = ym1(i,1,1,1) theta = 0.5*pi*(x-xmin)/(xmax-xmin) rad = radm + rad1*(y-ymin)/(ymax-ymin) ym1(i,1,1,1) = rad*cos(theta) ! This should be the xm1(i,1,1,1) = rad*sin(theta) ! correct orientation. enddo return end c----------------------------------------------------------------------- On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Paul; > > Since I am using Prenek to generate the base mesh for the pipe in X-Y > plane, and then extrude it in the Z direction using the n2to3 tool, is > there any easy way to change the orientation of such a mesh based on > your suggestion? Or maybe I need to start generating the grid from the > very beginning in X-Z plane? > > Best regards > Azad > > > PS - be sure that the rotation preserves the right-handed > coordinates of the original system. > > > On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Azad, >> >> It's important that the "cyclic" axis be the z-axis. >> >> You may need to rotate your geometry into this orientation. >> >> In that case, your inlet/out planes would, say, be x-z >> and y-z planes. >> >> Paul >> >> >> On Sun, 26 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Neks; >>> >>> I had a question regarding cyclic bc. It works properly for 2D and 3D >>> curved channel, (arch-like curvature is generated in stream-wise >>> direction using userdat2 with period bc at the both ends). However, when >>> I try it for the curved pipe, seems not working at all. I appreciate it >>> if you could help me by that. >>> >>> Many thanks; >>> Azad >>> >>> > > _______________________________________________ > 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 Jun 29 11:23:44 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 29 Jun 2011 18:23:44 +0200 Subject: [Nek5000-users] Re : CYCLIC BC for bend pipe In-Reply-To: References: Message-ID: <1309364624.28280.31.camel@damavand.mech.kth.se> On Mon, 2011-06-27 at 12:00 -0500, nek5000-users-request at lists.mcs.anl.gov wrote: > Re : CYCLIC BC for bend pipe Dear Paul; This is exactly what I wanted. I tested the example and it works very well. Many thanks for the useful information. Best regards; Azad From nek5000-users at lists.mcs.anl.gov Wed Jun 29 13:55:02 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 29 Jun 2011 14:55:02 -0400 Subject: [Nek5000-users] Lagrangian Particle Tracking Message-ID: <20110629145502.83221yp9jf0gt69y@webmail.vt.edu> Hi, I have couple of questions regarding the subroutine given for Lagrangian particle tracking at the following wiki page and I wonder if there are any hints. http://nek5000.mcs.anl.gov/index.php/Data_processing_example - Where should this subroutine be inserted? - What are the variables "rtl" and "mr" representing? - How to set the initial positions of the particles? - Should the constant parameters "npart" and "dt_p" be inserted in SIZE file? Thanks in advance, Regards, Alireza Karimi From nek5000-users at lists.mcs.anl.gov Wed Jun 29 14:42:44 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 29 Jun 2011 14:42:44 -0500 (CDT) Subject: [Nek5000-users] Lagrangian Particle Tracking In-Reply-To: <20110629145502.83221yp9jf0gt69y@webmail.vt.edu> References: <20110629145502.83221yp9jf0gt69y@webmail.vt.edu> Message-ID: Hi Alireza, Let me check what is a current status of development for a complete set of Lagrangian particle tracking routines. My understanding that the subroutine particle_advect is written for the old interpolation w/ parameter mr -- we need to update it. This subroutine has to be used in the timestep loop called from usrchk after one interpolates (w/ intpts) velocity field (to vvel) at coordinates of the most recent particle location rtl -- hmm, I do not see how this array vvel with interpolated velocity data is then passed to the subroutine particle_advect... Let me look further and get back to you later. Aleks On Wed, 29 Jun 2011, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I have couple of questions regarding the subroutine given for Lagrangian > particle tracking at the following wiki page and I wonder if there are any > hints. > > http://nek5000.mcs.anl.gov/index.php/Data_processing_example > > - Where should this subroutine be inserted? > - What are the variables "rtl" and "mr" representing? > - How to set the initial positions of the particles? > - Should the constant parameters "npart" and "dt_p" be inserted in SIZE file? > > > Thanks in advance, > > > Regards, > Alireza Karimi > > _______________________________________________ > 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 Jun 29 16:21:38 2011 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 29 Jun 2011 16:21:38 -0500 Subject: [Nek5000-users] Lagrangian Particle Tracking In-Reply-To: References: <20110629145502.83221yp9jf0gt69y@webmail.vt.edu> Message-ID: Hi Alireza, I've attached an example that uses the particle tracking to create timelines that track the flow past a hemisphere. It is the same as this case: http://www.mcs.anl.gov/~fischer/cfd/cfd.html. Also, there is a video that shows the particles (from the exact setup that I'm sending you) here: http://www.mcs.anl.gov/~fischer/mov.mp4. The particle routines are all called from userchk. They are: particle_init - initiates particles, can be as complex or simple as you need particle_advect_std - advects particles by interpolating velocity values at the current location and using history velocity values for AB3 particle_out - outputs particle data...sometimes using poorly coded MPI ;) The main arrays are: pts - keeps particle data vel - keeps velocity history for AB3 and for output if you're interested npart - the local number of particles partpt - array of global particle numbers, for tracking The only parameter that you need to adjust in SIZE is lpart for the maximum number of particles. If it's too small, Nek should tell you. Justin On Wed, Jun 29, 2011 at 2:42 PM, wrote: > Hi Alireza, > > Let me check what is a current status of development for a complete set of > Lagrangian particle tracking routines. > > My understanding that the subroutine particle_advect is written for the old > interpolation w/ parameter mr -- we need to update it. This subroutine has > to be used in the timestep loop called from usrchk after one interpolates > (w/ intpts) velocity field (to vvel) at coordinates of the most recent > particle location rtl -- hmm, I do not see how this array vvel with > interpolated velocity data is then passed to the subroutine > particle_advect... > > Let me look further and get back to you later. > Aleks > > > > > On Wed, 29 Jun 2011, nek5000-users at lists.mcs.anl.**govwrote: > > Hi, >> >> I have couple of questions regarding the subroutine given for Lagrangian >> particle tracking at the following wiki page and I wonder if there are any >> hints. >> >> http://nek5000.mcs.anl.gov/**index.php/Data_processing_**example >> >> - Where should this subroutine be inserted? >> - What are the variables "rtl" and "mr" representing? >> - How to set the initial positions of the particles? >> - Should the constant parameters "npart" and "dt_p" be inserted in SIZE >> file? >> >> >> Thanks in advance, >> >> >> Regards, >> Alireza Karimi >> >> ______________________________**_________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: hemi.tgz Type: application/x-gzip Size: 145687 bytes Desc: not available URL: