From nek5000-users at lists.mcs.anl.gov Mon Oct 1 02:14:49 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 1 Oct 2012 09:14:49 +0200 Subject: [Nek5000-users] gradm1 or dudxyz Message-ID: Hi, in terms of calculating a gradient: is there a difference between routines gradm1 and dudxyz except that the latter is supplying additional information about the mapping? Thanks, Joerg. From nek5000-users at lists.mcs.anl.gov Mon Oct 1 06:09:20 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 1 Oct 2012 06:09:20 -0500 (CDT) Subject: [Nek5000-users] gradm1 or dudxyz In-Reply-To: Message-ID: Hi Joerg, Yes - gradm1() is much more efficient that dudxyz(), which is antiquated. dudxyz() returns only one component of the gradient at a time and there is work that is duplicated for each call. The work for gradm1() is equivalent to a single call to dudxyz() and you get all 3 components in a single call to gradm1(). The results are the same. Paul ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, October 1, 2012 2:14:49 AM Subject: [Nek5000-users] gradm1 or dudxyz Hi, in terms of calculating a gradient: is there a difference between routines gradm1 and dudxyz except that the latter is supplying additional information about the mapping? Thanks, Joerg. _______________________________________________ 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 Sat Oct 6 12:41:17 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 18:41:17 +0100 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline Message-ID: Dear Neks, I have started to use the 2D axisymmetric version of Nek5000 with swirl (like the example vortex2), to get some base flows in axisymmetric geometries. To test the code I modified the vortex2 example to simple Grabowski vortex flow. This means setting the inlet profile: U_x=1 U_r=0 U_theta=0.8944r(2-r^2) The result looked good at the first sight, but a closer inspection revealed that the swirl velocity (U_theta) is nonzero at the centerline (up to U_theta=0.1). Also other axisymmetric flow cases with swirl gave nonzero swirl velocities. I wonder if it would be possible for someone to look into why this happens? I have attached the .usr, .rea and .box files below. Also, it would be useful if you could guide me into the precise place in the code where the centerline condition for swirl is set. Does OMASK have something to do with this? Or is it TMASK? Outi -------------- next part -------------- A non-text attachment was scrubbed... Name: grab.box Type: application/octet-stream Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: grab.rea Type: application/octet-stream Size: 6039 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: grab.usr Type: application/octet-stream Size: 3075 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Sat Oct 6 17:28:43 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 17:28:43 -0500 (CDT) Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Outi, Do you have the "A " bc on your elements that touch the centerline? Are you using the same mesh as vortex2? Or a new one generated with genbox. In principal, the A bc should set U_theta=0 on the axis. Paul On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Neks, > > I have started to use the 2D axisymmetric version of Nek5000 with swirl (like > the example vortex2), to get some base flows in axisymmetric geometries. > To test the code I modified the vortex2 example to simple Grabowski vortex > flow. > This means setting the inlet profile: > U_x=1 > U_r=0 > U_theta=0.8944r(2-r^2) > > The result looked good at the first sight, but a closer inspection revealed > that the swirl velocity (U_theta) is nonzero at the centerline (up to > U_theta=0.1). Also other axisymmetric flow cases with swirl gave nonzero > swirl velocities. > > I wonder if it would be possible for someone to look into why this happens? I > have attached the .usr, .rea and .box files below. > > Also, it would be useful if you could guide me into the precise place in the > code where the centerline condition for swirl is set. Does OMASK have > something to do with this? Or is it TMASK? > > Outi > From nek5000-users at lists.mcs.anl.gov Sat Oct 6 17:34:13 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 23:34:13 +0100 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Paul, I use the "A " BC. And the new mesh generated by genbox. Outi 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: > > Dear Outi, > > Do you have the "A " bc on your elements that touch the centerline? > > Are you using the same mesh as vortex2? Or a new one generated with > genbox. > > In principal, the A bc should set U_theta=0 on the axis. > > Paul > > > On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Neks, >> >> I have started to use the 2D axisymmetric version of Nek5000 with >> swirl (like the example vortex2), to get some base flows in >> axisymmetric geometries. >> To test the code I modified the vortex2 example to simple Grabowski >> vortex flow. >> This means setting the inlet profile: >> U_x=1 >> U_r=0 >> U_theta=0.8944r(2-r^2) >> >> The result looked good at the first sight, but a closer inspection >> revealed that the swirl velocity (U_theta) is nonzero at the >> centerline (up to U_theta=0.1). Also other axisymmetric flow cases >> with swirl gave nonzero swirl velocities. >> >> I wonder if it would be possible for someone to look into why this >> happens? I have attached the .usr, .rea and .box files below. >> >> Also, it would be useful if you could guide me into the precise >> place in the code where the centerline condition for swirl is set. >> Does OMASK have something to do with this? Or is it TMASK? >> >> Outi >> > _______________________________________________ > 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 Sat Oct 6 17:42:51 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 17:42:51 -0500 (CDT) Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Outi, If you are prescribing your u_theta (i.e., as temperature), then from your formula below it should be zero on the axis. One thing that might be of value (for small problems) is to add to userbc the statements below if (ifield.eq.2) write(6,1) x,y,temp 1 format(1p3e13.5,' uxyz') if (istep.eq.2) stop You can then grep uxyz logfile and look at what is going on. You should see that, for y=0, you match your desired profile. Paul On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > I use the "A " BC. > And the new mesh generated by genbox. > > Outi > > > 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: > >> >> Dear Outi, >> >> Do you have the "A " bc on your elements that touch the centerline? >> >> Are you using the same mesh as vortex2? Or a new one generated with >> genbox. >> >> In principal, the A bc should set U_theta=0 on the axis. >> >> Paul >> >> >> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Neks, >>> >>> I have started to use the 2D axisymmetric version of Nek5000 with swirl >>> (like the example vortex2), to get some base flows in axisymmetric >>> geometries. >>> To test the code I modified the vortex2 example to simple Grabowski vortex >>> flow. >>> This means setting the inlet profile: >>> U_x=1 >>> U_r=0 >>> U_theta=0.8944r(2-r^2) >>> >>> The result looked good at the first sight, but a closer inspection >>> revealed that the swirl velocity (U_theta) is nonzero at the centerline >>> (up to U_theta=0.1). Also other axisymmetric flow cases with swirl gave >>> nonzero swirl velocities. >>> >>> I wonder if it would be possible for someone to look into why this >>> happens? I have attached the .usr, .rea and .box files below. >>> >>> Also, it would be useful if you could guide me into the precise place in >>> the code where the centerline condition for swirl is set. Does OMASK have >>> something to do with this? Or is it TMASK? >>> >>> Outi >>> >> _______________________________________________ >> 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 Sat Oct 6 17:48:45 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 23:48:45 +0100 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Paul, Thank you for the suggestion, but the prescribed profile is just an inlet profile, and I do get a correct profile at the inlet. The nonzero swirl velocity at the centerline appears downstream. Outi 6 Oct 2012 kl. 23:42 skrev nek5000-users at lists.mcs.anl.gov: > > Dear Outi, > > If you are prescribing your u_theta (i.e., as temperature), > then from your formula below it should be zero on the axis. > > One thing that might be of value (for small problems) is > to add to userbc the statements below > > if (ifield.eq.2) write(6,1) x,y,temp > 1 format(1p3e13.5,' uxyz') > if (istep.eq.2) stop > > You can then grep uxyz logfile and look at what is going on. > You should see that, for y=0, you match your desired profile. > > Paul > > > > On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul, >> >> I use the "A " BC. >> And the new mesh generated by genbox. >> >> Outi >> >> >> 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: >> >>> Dear Outi, >>> Do you have the "A " bc on your elements that touch the centerline? >>> Are you using the same mesh as vortex2? Or a new one generated with >>> genbox. >>> In principal, the A bc should set U_theta=0 on the axis. >>> Paul >>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>> Dear Neks, >>>> I have started to use the 2D axisymmetric version of Nek5000 with >>>> swirl (like the example vortex2), to get some base flows in >>>> axisymmetric geometries. >>>> To test the code I modified the vortex2 example to simple >>>> Grabowski vortex flow. >>>> This means setting the inlet profile: >>>> U_x=1 >>>> U_r=0 >>>> U_theta=0.8944r(2-r^2) >>>> The result looked good at the first sight, but a closer >>>> inspection revealed that the swirl velocity (U_theta) is nonzero >>>> at the centerline (up to U_theta=0.1). Also other axisymmetric >>>> flow cases with swirl gave nonzero swirl velocities. >>>> I wonder if it would be possible for someone to look into why >>>> this happens? I have attached the .usr, .rea and .box files below. >>>> Also, it would be useful if you could guide me into the precise >>>> place in the code where the centerline condition for swirl is >>>> set. Does OMASK have something to do with this? Or is it TMASK? >>>> Outi >>> _______________________________________________ >>> 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 Sat Oct 6 17:56:53 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 6 Oct 2012 17:56:53 -0500 (CDT) Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Thanks... would you mind sending a gzip'd tarfile with SIZE box file rea file usr file to me offline? Best regards, Paul On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Dear Paul, > > Thank you for the suggestion, but the prescribed profile is just an inlet > profile, and I do get a correct profile at the inlet. > The nonzero swirl velocity at the centerline appears downstream. > > Outi > > 6 Oct 2012 kl. 23:42 skrev nek5000-users at lists.mcs.anl.gov: > >> >> Dear Outi, >> >> If you are prescribing your u_theta (i.e., as temperature), >> then from your formula below it should be zero on the axis. >> >> One thing that might be of value (for small problems) is >> to add to userbc the statements below >> >> if (ifield.eq.2) write(6,1) x,y,temp >> 1 format(1p3e13.5,' uxyz') >> if (istep.eq.2) stop >> >> You can then grep uxyz logfile and look at what is going on. >> You should see that, for y=0, you match your desired profile. >> >> Paul >> >> >> >> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Paul, >>> >>> I use the "A " BC. >>> And the new mesh generated by genbox. >>> >>> Outi >>> >>> >>> 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: >>> >>>> Dear Outi, >>>> Do you have the "A " bc on your elements that touch the centerline? >>>> Are you using the same mesh as vortex2? Or a new one generated with >>>> genbox. >>>> In principal, the A bc should set U_theta=0 on the axis. >>>> Paul >>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>> Dear Neks, >>>>> I have started to use the 2D axisymmetric version of Nek5000 with swirl >>>>> (like the example vortex2), to get some base flows in axisymmetric >>>>> geometries. >>>>> To test the code I modified the vortex2 example to simple Grabowski >>>>> vortex flow. >>>>> This means setting the inlet profile: >>>>> U_x=1 >>>>> U_r=0 >>>>> U_theta=0.8944r(2-r^2) >>>>> The result looked good at the first sight, but a closer inspection >>>>> revealed that the swirl velocity (U_theta) is nonzero at the centerline >>>>> (up to U_theta=0.1). Also other axisymmetric flow cases with swirl gave >>>>> nonzero swirl velocities. >>>>> I wonder if it would be possible for someone to look into why this >>>>> happens? I have attached the .usr, .rea and .box files below. >>>>> Also, it would be useful if you could guide me into the precise place in >>>>> the code where the centerline condition for swirl is set. Does OMASK >>>>> have something to do with this? Or is it TMASK? >>>>> Outi >>>> _______________________________________________ >>>> 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 Sat Oct 6 18:11:29 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 7 Oct 2012 00:11:29 +0100 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: I have just done that. Thank you very much. Outi 6 Oct 2012 kl. 23:56 skrev nek5000-users at lists.mcs.anl.gov: > > Thanks... would you mind sending a gzip'd tarfile with > > SIZE > box file > rea file > usr file > > to me offline? > > Best regards, > > Paul > > > On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Dear Paul, >> >> Thank you for the suggestion, but the prescribed profile is just an >> inlet profile, and I do get a correct profile at the inlet. >> The nonzero swirl velocity at the centerline appears downstream. >> >> Outi >> >> 6 Oct 2012 kl. 23:42 skrev nek5000-users at lists.mcs.anl.gov: >> >>> Dear Outi, >>> If you are prescribing your u_theta (i.e., as temperature), >>> then from your formula below it should be zero on the axis. >>> One thing that might be of value (for small problems) is >>> to add to userbc the statements below >>> >>> if (ifield.eq.2) write(6,1) x,y,temp >>> 1 format(1p3e13.5,' uxyz') >>> if (istep.eq.2) stop >>> You can then grep uxyz logfile and look at what is going on. >>> You should see that, for y=0, you match your desired profile. >>> Paul >>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>> Dear Paul, >>>> I use the "A " BC. >>>> And the new mesh generated by genbox. >>>> Outi >>>> 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: >>>>> Dear Outi, >>>>> Do you have the "A " bc on your elements that touch the >>>>> centerline? >>>>> Are you using the same mesh as vortex2? Or a new one generated >>>>> with >>>>> genbox. >>>>> In principal, the A bc should set U_theta=0 on the axis. >>>>> Paul >>>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>>> Dear Neks, >>>>>> I have started to use the 2D axisymmetric version of Nek5000 >>>>>> with swirl (like the example vortex2), to get some base flows >>>>>> in axisymmetric geometries. >>>>>> To test the code I modified the vortex2 example to simple >>>>>> Grabowski vortex flow. >>>>>> This means setting the inlet profile: >>>>>> U_x=1 >>>>>> U_r=0 >>>>>> U_theta=0.8944r(2-r^2) >>>>>> The result looked good at the first sight, but a closer >>>>>> inspection revealed that the swirl velocity (U_theta) is >>>>>> nonzero at the centerline (up to U_theta=0.1). Also other >>>>>> axisymmetric flow cases with swirl gave nonzero swirl velocities. >>>>>> I wonder if it would be possible for someone to look into why >>>>>> this happens? I have attached the .usr, .rea and .box files >>>>>> below. >>>>>> Also, it would be useful if you could guide me into the precise >>>>>> place in the code where the centerline condition for swirl is >>>>>> set. Does OMASK have something to do with this? Or is it TMASK? >>>>>> Outi >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > 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 Oct 8 04:21:26 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 08 Oct 2012 11:21:26 +0200 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Neks, It turns out that an update for the latest version (r862) solved my problem. I am sorry for wasting your time. However, I was running r831 (5 months old) and could not see any posts about this lately. Maybe this issue also was fixed at the same time as the spherical shell in September? The main difference between r831 and r862 seems to be in bdry.f, line 2060: IF (CB.EQ.'T ' .OR. CB.EQ.'t ' .OR. $ (CB.EQ.'A ' .AND. IFAZIV) .OR. $ CB.EQ.'MCI' .OR. CB.EQ.'MLI' .OR. $ CB.EQ.'KD ' .OR. CB.EQ.'kd ' .OR. $ CB.EQ.'ED ' .OR. CB.EQ.'ed ' .OR. $ CB.EQ.'KW ' .OR. CB.EQ.'KWS' .OR. CB.EQ.'EWS') $ CALL FACEV (TMASK(1,1,1,1,IPSCAL), $ IEL,IFACE,0.0,NX1,NY1,NZ1) In version r831, the part (CB.EQ.'A ' .AND. IFAZIV) was missing, as I already suspected. In any case, this shows the importance of updating regularly, and I am sorry for the interruption. Outi Quoting nek5000-users at lists.mcs.anl.gov: > I have just done that. > Thank you very much. > > Outi > > 6 Oct 2012 kl. 23:56 skrev nek5000-users at lists.mcs.anl.gov: > >> >> Thanks... would you mind sending a gzip'd tarfile with >> >> SIZE >> box file >> rea file >> usr file >> >> to me offline? >> >> Best regards, >> >> Paul >> >> >> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Paul, >>> >>> Thank you for the suggestion, but the prescribed profile is just >>> an inlet profile, and I do get a correct profile at the inlet. >>> The nonzero swirl velocity at the centerline appears downstream. >>> >>> Outi >>> >>> 6 Oct 2012 kl. 23:42 skrev nek5000-users at lists.mcs.anl.gov: >>> >>>> Dear Outi, >>>> If you are prescribing your u_theta (i.e., as temperature), >>>> then from your formula below it should be zero on the axis. >>>> One thing that might be of value (for small problems) is >>>> to add to userbc the statements below >>>> >>>> if (ifield.eq.2) write(6,1) x,y,temp >>>> 1 format(1p3e13.5,' uxyz') >>>> if (istep.eq.2) stop >>>> You can then grep uxyz logfile and look at what is going on. >>>> You should see that, for y=0, you match your desired profile. >>>> Paul >>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>> Dear Paul, >>>>> I use the "A " BC. >>>>> And the new mesh generated by genbox. >>>>> Outi >>>>> 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: >>>>>> Dear Outi, >>>>>> Do you have the "A " bc on your elements that touch the centerline? >>>>>> Are you using the same mesh as vortex2? Or a new one generated with >>>>>> genbox. >>>>>> In principal, the A bc should set U_theta=0 on the axis. >>>>>> Paul >>>>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>>>> Dear Neks, >>>>>>> I have started to use the 2D axisymmetric version of Nek5000 >>>>>>> with swirl (like the example vortex2), to get some base flows >>>>>>> in axisymmetric geometries. >>>>>>> To test the code I modified the vortex2 example to simple >>>>>>> Grabowski vortex flow. >>>>>>> This means setting the inlet profile: >>>>>>> U_x=1 >>>>>>> U_r=0 >>>>>>> U_theta=0.8944r(2-r^2) >>>>>>> The result looked good at the first sight, but a closer >>>>>>> inspection revealed that the swirl velocity (U_theta) is >>>>>>> nonzero at the centerline (up to U_theta=0.1). Also other >>>>>>> axisymmetric flow cases with swirl gave nonzero swirl >>>>>>> velocities. >>>>>>> I wonder if it would be possible for someone to look into why >>>>>>> this happens? I have attached the .usr, .rea and .box files >>>>>>> below. >>>>>>> Also, it would be useful if you could guide me into the >>>>>>> precise place in the code where the centerline condition for >>>>>>> swirl is set. Does OMASK have something to do with this? Or is >>>>>>> it TMASK? >>>>>>> Outi >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> 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 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From nek5000-users at lists.mcs.anl.gov Mon Oct 8 13:48:55 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 8 Oct 2012 19:48:55 +0100 Subject: [Nek5000-users] Nonzero swirl velocity at the centerline In-Reply-To: References: Message-ID: Dear Neks, (And thanks to Paul for looking into this). It turns out that an update for the latest version (r862) solved my problem. I am sorry for wasting your time. However, I was running r831 (5 months old) and could not see any posts about this lately. Maybe this issue also was fixed at the same time as the spherical shell in September? The main difference between r831 and r862 seems to be in bdry.f, line 2060: IF (CB.EQ.'T ' .OR. CB.EQ.'t ' .OR. $ (CB.EQ.'A ' .AND. IFAZIV) .OR. $ CB.EQ.'MCI' .OR. CB.EQ.'MLI' .OR. $ CB.EQ.'KD ' .OR. CB.EQ.'kd ' .OR. $ CB.EQ.'ED ' .OR. CB.EQ.'ed ' .OR. $ CB.EQ.'KW ' .OR. CB.EQ.'KWS' .OR. CB.EQ.'EWS') $ CALL FACEV (TMASK(1,1,1,1,IPSCAL), $ IEL,IFACE,0.0,NX1,NY1,NZ1) In version r831, the part (CB.EQ.'A ' .AND. IFAZIV) was missing, as I already suspected. In any case, this shows the importance of updating regularly, and I am sorry for the interruption. Outi 7 Oct 2012 kl. 00:11 skrev nek5000-users at lists.mcs.anl.gov: > I have just done that. > Thank you very much. > > Outi > > 6 Oct 2012 kl. 23:56 skrev nek5000-users at lists.mcs.anl.gov: > >> >> Thanks... would you mind sending a gzip'd tarfile with >> >> SIZE >> box file >> rea file >> usr file >> >> to me offline? >> >> Best regards, >> >> Paul >> >> >> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Dear Paul, >>> >>> Thank you for the suggestion, but the prescribed profile is just >>> an inlet profile, and I do get a correct profile at the inlet. >>> The nonzero swirl velocity at the centerline appears downstream. >>> >>> Outi >>> >>> 6 Oct 2012 kl. 23:42 skrev nek5000-users at lists.mcs.anl.gov: >>> >>>> Dear Outi, >>>> If you are prescribing your u_theta (i.e., as temperature), >>>> then from your formula below it should be zero on the axis. >>>> One thing that might be of value (for small problems) is >>>> to add to userbc the statements below >>>> >>>> if (ifield.eq.2) write(6,1) x,y,temp >>>> 1 format(1p3e13.5,' uxyz') >>>> if (istep.eq.2) stop >>>> You can then grep uxyz logfile and look at what is going on. >>>> You should see that, for y=0, you match your desired profile. >>>> Paul >>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>> Dear Paul, >>>>> I use the "A " BC. >>>>> And the new mesh generated by genbox. >>>>> Outi >>>>> 6 Oct 2012 kl. 23:28 skrev nek5000-users at lists.mcs.anl.gov: >>>>>> Dear Outi, >>>>>> Do you have the "A " bc on your elements that touch the >>>>>> centerline? >>>>>> Are you using the same mesh as vortex2? Or a new one generated >>>>>> with >>>>>> genbox. >>>>>> In principal, the A bc should set U_theta=0 on the axis. >>>>>> Paul >>>>>> On Sat, 6 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>>>>>> Dear Neks, >>>>>>> I have started to use the 2D axisymmetric version of Nek5000 >>>>>>> with swirl (like the example vortex2), to get some base flows >>>>>>> in axisymmetric geometries. >>>>>>> To test the code I modified the vortex2 example to simple >>>>>>> Grabowski vortex flow. >>>>>>> This means setting the inlet profile: >>>>>>> U_x=1 >>>>>>> U_r=0 >>>>>>> U_theta=0.8944r(2-r^2) >>>>>>> The result looked good at the first sight, but a closer >>>>>>> inspection revealed that the swirl velocity (U_theta) is >>>>>>> nonzero at the centerline (up to U_theta=0.1). Also other >>>>>>> axisymmetric flow cases with swirl gave nonzero swirl >>>>>>> velocities. >>>>>>> I wonder if it would be possible for someone to look into why >>>>>>> this happens? I have attached the .usr, .rea and .box files >>>>>>> below. >>>>>>> Also, it would be useful if you could guide me into the >>>>>>> precise place in the code where the centerline condition for >>>>>>> swirl is set. Does OMASK have something to do with this? Or is >>>>>>> it TMASK? >>>>>>> Outi >>>>>> _______________________________________________ >>>>>> 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 >> _______________________________________________ >> 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 Mon Oct 8 20:34:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 8 Oct 2012 21:34:57 -0400 Subject: [Nek5000-users] Stream function Message-ID: Hi neks, I am running nek in 2D, and for visualization purposes I would like to output a stream function as a field in the fld files. So I am wondering, is there already a routine written to compute the stream function from the velocity fields? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Oct 8 20:42:58 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 8 Oct 2012 20:42:58 -0500 (CDT) Subject: [Nek5000-users] Stream function In-Reply-To: References: Message-ID: Hi David, There is a streamfunction option in postnek, but none in nek proper. The postnek one is very easy to use -- SET QUANTITY STREAMFUNCTION SET PLOT FORMAT SCALAR CONTOUR LINES SET ATTRIBUTE SET RESOLUTION COLOR FILL 30 CONTOUR LINES 40 (say) PLOT Paul On Mon, 8 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi neks, > > I am running nek in 2D, and for visualization purposes I would like to > output a stream function as a field in the fld files. So I am wondering, is > there already a routine written to compute the stream function from the > velocity fields? > > Thanks, > > David > From nek5000-users at lists.mcs.anl.gov Mon Oct 8 22:23:24 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 8 Oct 2012 23:23:24 -0400 Subject: [Nek5000-users] Stream function In-Reply-To: References: Message-ID: Hi Paul, Great, thanks for the info. I have not used postnek yet, but I will give it a shot. One issue: the menu I see after choosing SET PLOT FORMAT is: ( 1) UP MENU ( 2) X-Y PLOT ( 3) SURFACE PLOT ( 4) VALUES ( 5) VOLUME ( 6) MULTIPLOT ( 7) DRAW MESH NODES ( 8) LABEL MESH NODES ( 9) DRAW MESH I do not see the SCALAR > CONTOUR LINES option. Am I missing something? Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Oct 8 22:48:19 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 8 Oct 2012 22:48:19 -0500 (CDT) Subject: [Nek5000-users] Stream function In-Reply-To: References: Message-ID: sorry -- was a bit imprecise SURFACE PLOT ... then go from there... you can also get nice .ps output in black and white of the contour lines if you want (SET ATTRIBUTE SET HARD COPY SET HARD COPY ... ) CLEAR PLOT Paul On Mon, 8 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > Great, thanks for the info. I have not used postnek yet, but I will give > it a shot. One issue: the menu I see after choosing SET PLOT FORMAT is: > > ( 1) UP MENU > ( 2) X-Y PLOT > ( 3) SURFACE PLOT > ( 4) VALUES > ( 5) VOLUME > ( 6) MULTIPLOT > ( 7) DRAW MESH NODES > ( 8) LABEL MESH NODES > ( 9) DRAW MESH > > I do not see the SCALAR > CONTOUR LINES option. Am I missing something? > > Best, > > David > From nek5000-users at lists.mcs.anl.gov Thu Oct 11 07:10:58 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 11 Oct 2012 14:10:58 +0200 Subject: [Nek5000-users] does load_fld() work with .f00* files ?? (default binary files) In-Reply-To: <4F5DE54B.1070402@onera.fr> References: <4F5DC03E.8060405@onera.fr> <4F5DE54B.1070402@onera.fr> Message-ID: Hi Nek's, I have some troubles with the load_fld subroutine. It seems to load the files I want, however it sets everything (vx, vy, vz) to zero... Here is what I have in my usrchk routine: n = nx1*ny1*nz1*nelt ifto = .true. if(nid.EQ.0) then open(unit=199,file='file.list',form='formatted',status='old') read(199,'(A80)') (filename(i),i=1,ncli+1) close(199) endif call bcast(filename,(ncli+1)*80) do i = 1,ncli+1 call load_fld(filename(i)) if(nid.EQ.0) write(*,*) 'File', filename(i), 'loaded.' call lambda2(t(1,1,1,1,1)) call outpost(vx,vy,vz,pr,t,'PRT') enddo And here is what I get in my logfile for the first file for instance: nsteps=0 -> skip time loop running solver in post processing mode call userchk set initial conditions nekuic (1) for ifld 1 call nekuic for vel xyz min 0.0000 0.0000 0.0000 uvwpt min 0.99960E-20 0.99960E-20 0.99960E-20 0.0000 0.99960E-20 PS min 0.0000 0.0000 0.99000E+22 xyz max 1.0000 1.0000 1.0000 uvwpt max 0.80000E-19 0.80000E-19 0.80000E-19 0.0000 0.80000E-19 PS max 0.0000 0.0000 -0.99000E+22 done :: set initial conditions File prtcav0.f00001 loaded. Have I been doing something wrong using the load_fld routine? Regards, On 12 March 2012 13:00, wrote: > nek5000-users at lists.mcs.anl.**gov a > ?crit : > > Hi everyone, i am trying to post process some data but it seems load_fld >> doesn't load the velocity field correctly. >> My binary files are default .f00* files (param(66)=param(67)=0) >> I want to recalculate the vortex size (aa in my code) in a 2D case. >> So here is what i want my userchk() to do >> Open one by one .f00* files, >> Calculate the vorticity field from velocity field >> Restrain the domain to avoid Boundary conditions >> Calculate the circulation >> Calculate The vorticity barycenter coordinates >> Calculate The vorticity Size (aa) >> Output to "Rayon_Circulation_domaine_**entier" file the quantity sqrt(aa) >> Does load_fld() work only with .fld files ?? Because with this i got only >> negative values for the vorticity size and the circulation value is not good >> B.regards >> Can >> >> >> >> My post-precessing part in my userchk() is like >> >> ! read file-list >> if (nid.eq.0) then >> open(unit=199,file='file.list'**,form='formatted',status='old' >> **) >> read(199,*) nfiles >> read(199,'(A80)') (filename(j),j=1,nfiles) >> close(199) >> endif >> call bcast(nfiles,isize) >> call bcast(filename,nfiles*80) do j = 1,nfiles >> call load_fld(filename(j)) >> call comp_vort3(vort,work1,work2,**vx,vy,vz) >> do i=1, ntot >> if((abs(xm1(i,1,1,1))<14.9) .and. (abs(ym1(i,1,1,1))<14.9)) >> & then x_new(i)=xm1(i,1,1,1) >> y_new(i)=ym1(i,1,1,1) >> rId(i)=1.0 >> >> else >> >> x_new(i)=0.0 >> y_new(i)=0.0 >> rId(i)=0.0 >> >> endif >> >> enddo >> circ=glsc3(rId,bm1,vort(1,1),**ntot) >> x_c=glsc3(x_new,bm1,vort(1,1),**ntot)/circ >> ! Calculation of vorticity barrycenter >> y_c=glsc3(y_new,bm1,vort(1,1),**ntot)/circ >> >> do i=1, ntot >> if((abs(xm1(i,1,1,1))<14.9) .and. (abs(ym1(i,1,1,1))<14.9)) >> & then rr(i)=(xm1(i,1,1,1)-x_c(1))**2 + (ym1(i,1,1,1) >> & -y_c(1))**2 >> else >> rr(i)=0.0 >> endif >> enddo >> >> aa=glsc3(rr,bm1,vort(1,1),**ntot)/circ >> ! Calculation of vorticity size >> print*,'aa=',aa >> if (nid.eq.0) then >> open(UNIT=1,FILE='Rayon_**Circulation_domaine_entier',**STATUS='unknown') >> !Output to 'Rayon_Circulation_domaine_**entier' file >> write(1,'(1p20E15.7)') time,sqrt(aa),circ >> endif >> enddo >> !we are done >> call exitt >> c ==============================**==============================** >> ==============================**======================= >> >> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> > Well sorry for this, load_fld() works great with .f00* files > Le problem was related to my grid in the domain which was not tight enough > for x>10 > Thx anyways > > ______________________________**_________________ > 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 Oct 11 07:29:19 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 11 Oct 2012 14:29:19 +0200 Subject: [Nek5000-users] does load_fld() work with .f00* files ?? (default binary files) In-Reply-To: References: <4F5DC03E.8060405@onera.fr> <4F5DE54B.1070402@onera.fr> Message-ID: PS: - ncli is an integer I have defined as parameter earlier in usrchck. - it actually seems like useric subroutine is called at some point zeroing out all my vx,vy,vz. I have tried specifying ux = 1234 in useric and then re-run the code and I get uvwpt min 1234 ... - when I want to load just one single file using the restart option in blah.rea, it works just fine. On 11 October 2012 14:10, wrote: > Hi Nek's, > > I have some troubles with the load_fld subroutine. It seems to load the > files I want, however it sets everything (vx, vy, vz) to zero... > Here is what I have in my usrchk routine: > > n = nx1*ny1*nz1*nelt > ifto = .true. > > if(nid.EQ.0) then > > open(unit=199,file='file.list',form='formatted',status='old') > read(199,'(A80)') (filename(i),i=1,ncli+1) > close(199) > endif > > call bcast(filename,(ncli+1)*80) > > do i = 1,ncli+1 > call load_fld(filename(i)) > if(nid.EQ.0) write(*,*) 'File', filename(i), 'loaded.' > call lambda2(t(1,1,1,1,1)) > call outpost(vx,vy,vz,pr,t,'PRT') > enddo > > And here is what I get in my logfile for the first file for instance: > > nsteps=0 -> skip time loop > running solver in post processing mode > > call userchk > set initial conditions > nekuic (1) for ifld 1 > call nekuic for vel > xyz min 0.0000 0.0000 0.0000 > uvwpt min 0.99960E-20 0.99960E-20 0.99960E-20 0.0000 > 0.99960E-20 > PS min 0.0000 0.0000 0.99000E+22 > xyz max 1.0000 1.0000 1.0000 > uvwpt max 0.80000E-19 0.80000E-19 0.80000E-19 0.0000 > 0.80000E-19 > PS max 0.0000 0.0000 -0.99000E+22 > done :: set initial conditions > > File prtcav0.f00001 loaded. > > Have I been doing something wrong using the load_fld routine? > > Regards, > > > On 12 March 2012 13:00, wrote: > >> nek5000-users at lists.mcs.anl.**gov a >> ?crit : >> >> Hi everyone, i am trying to post process some data but it seems load_fld >>> doesn't load the velocity field correctly. >>> My binary files are default .f00* files (param(66)=param(67)=0) >>> I want to recalculate the vortex size (aa in my code) in a 2D case. >>> So here is what i want my userchk() to do >>> Open one by one .f00* files, >>> Calculate the vorticity field from velocity field >>> Restrain the domain to avoid Boundary conditions >>> Calculate the circulation >>> Calculate The vorticity barycenter coordinates >>> Calculate The vorticity Size (aa) >>> Output to "Rayon_Circulation_domaine_**entier" file the quantity >>> sqrt(aa) >>> Does load_fld() work only with .fld files ?? Because with this i got >>> only negative values for the vorticity size and the circulation value is >>> not good >>> B.regards >>> Can >>> >>> >>> >>> My post-precessing part in my userchk() is like >>> >>> ! read file-list >>> if (nid.eq.0) then >>> open(unit=199,file='file.list'** >>> ,form='formatted',status='old'**) >>> read(199,*) nfiles >>> read(199,'(A80)') (filename(j),j=1,nfiles) >>> close(199) >>> endif >>> call bcast(nfiles,isize) >>> call bcast(filename,nfiles*80) do j = 1,nfiles >>> call load_fld(filename(j)) >>> call comp_vort3(vort,work1,work2,**vx,vy,vz) >>> do i=1, ntot >>> if((abs(xm1(i,1,1,1))<14.9) .and. (abs(ym1(i,1,1,1))<14.9)) >>> & then x_new(i)=xm1(i,1,1,1) >>> y_new(i)=ym1(i,1,1,1) >>> rId(i)=1.0 >>> >>> else >>> >>> x_new(i)=0.0 >>> y_new(i)=0.0 >>> rId(i)=0.0 >>> >>> endif >>> >>> enddo >>> circ=glsc3(rId,bm1,vort(1,1),**ntot) >>> x_c=glsc3(x_new,bm1,vort(1,1),**ntot)/circ >>> ! Calculation of vorticity barrycenter >>> y_c=glsc3(y_new,bm1,vort(1,1),**ntot)/circ >>> >>> do i=1, ntot >>> if((abs(xm1(i,1,1,1))<14.9) .and. (abs(ym1(i,1,1,1))<14.9)) >>> & then rr(i)=(xm1(i,1,1,1)-x_c(1))**2 + (ym1(i,1,1,1) >>> & -y_c(1))**2 >>> else >>> rr(i)=0.0 >>> endif >>> enddo >>> >>> aa=glsc3(rr,bm1,vort(1,1),**ntot)/circ >>> ! Calculation of vorticity size >>> print*,'aa=',aa >>> if (nid.eq.0) then >>> open(UNIT=1,FILE='Rayon_**Circulation_domaine_entier',**STATUS='unknown') >>> !Output to 'Rayon_Circulation_domaine_**entier' file >>> write(1,'(1p20E15.7)') time,sqrt(aa),circ >>> endif >>> enddo >>> !we are done >>> call exitt >>> c ==============================**==============================** >>> ==============================**======================= >>> >>> ______________________________**_________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.**gov >>> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >>> >> Well sorry for this, load_fld() works great with .f00* files >> Le problem was related to my grid in the domain which was not tight >> enough for x>10 >> Thx anyways >> >> ______________________________**_________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.**gov >> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users >> > > > > -- > 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 Mon Oct 15 05:51:35 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 15 Oct 2012 12:51:35 +0200 Subject: [Nek5000-users] Replace velocity fields in perturbation mode Message-ID: Hi Nek's, I am using Nek in perturbation mode. At a certain time step i need to replace the velocity field with a different one. In usrchk I replace (vxp,vyp,vzp) with my field (vxb,vyb,vzb). I also reset vxlagp,vylagp,vzlagp and the extrapolation terms exxp1,exyp1,exzp1 and exxp2,exyp2,exzp2. call opcopy(vxp,vyp,vzp,vxb,vyb,vzb) call opzero(exx1p,exy1p,exz1p) call opzero(exx2p,exy2p,exz2p) do i=1,lorder-1 call opzero(vxlagp(1,i,1),vylagp(1,i,1), vzlagp(1,i,1)) enddo It works well if I set Torder=1, but for Torder=2 it seems that there are data contamination from previous time steps, so I think I'm missing some variables which i need to modify. Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Oct 15 06:06:08 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 15 Oct 2012 06:06:08 -0500 (CDT) Subject: [Nek5000-users] Replace velocity fields in perturbation mode In-Reply-To: References: Message-ID: Hi Andrea, Looking at SOLN, I see the following variables that might also need attention: PRLAGP VGRADT1P, VGRADT2P though the latter two seem to be related only to thermal problems. My guess is that it's the pressure lag that you're missing, which would be consistent with the variance in the TORDER behavior that you're reporting. Paul On Mon, 15 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Nek's, > > I am using Nek in perturbation mode. At a certain time step i need to > replace the velocity field with a different one. > > In usrchk I replace (vxp,vyp,vzp) with my field (vxb,vyb,vzb). I also > reset vxlagp,vylagp,vzlagp and the extrapolation terms exxp1,exyp1,exzp1 > and exxp2,exyp2,exzp2. > > call opcopy(vxp,vyp,vzp,vxb,vyb,vzb) > call opzero(exx1p,exy1p,exz1p) > call opzero(exx2p,exy2p,exz2p) > do i=1,lorder-1 > call opzero(vxlagp(1,i,1),vylagp(1,i,1), vzlagp(1,i,1)) > enddo > > It works well if I set Torder=1, but for Torder=2 it seems that there are > data contamination from previous time steps, so I think I'm missing some > variables which i need to modify. > > Andrea > From nek5000-users at lists.mcs.anl.gov Mon Oct 15 14:30:08 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 15 Oct 2012 21:30:08 +0200 Subject: [Nek5000-users] Area integral calculation in Nek Message-ID: Hi, I work in cylindrical geometry and want to evaluate an integral of one of scalar fields over the circular cross section at fixed position z_0. I suppose that the best way would be to make use of the GLL quadrature formulas on the elements after picking the elements at desired height z_0. I have two short questions: 1/ Is it correct that xm1, ym1, zm1 are the coordinate arrays, i.e. fixing for example zm1(i,1,1,1)=0.5 would then give all elements that contain nodes in exactly this plane? 2/ Are the GLL weights at the primary and secondary nodes stored in a specific array or do I have to evaluate them for each element, e.g. by combination of 1d routines which are collected in speclib.f? Thanks in advance, Joerg. From nek5000-users at lists.mcs.anl.gov Mon Oct 15 15:15:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 15 Oct 2012 15:15:57 -0500 (CDT) Subject: [Nek5000-users] Area integral calculation in Nek In-Reply-To: References: Message-ID: Hi Joerg, If your geometry came from n2to3, then your data is organized into planar sections and you can compute / F(z) = | f(x,y,z) dx dy /A as follows: common /scruz/ fbar(lz1,lelz),wght(lz1,lelz),work(lz1,lelz) integer e,eg,ex,ey,ez,f nelz = [how many levels you have in z] nelxy = nelgv/nelz ! Number of elements in a plane call rzero(fbar,nz1*nelz) call rzero(wght,nz1*nelz) f = 5 ! Pick face 5 to evaluate surface Jacobian do e=1,nelv eg = lglel(e) call get_exyz(ex,ey,ez,eg,nelxyz,1,nelz) do k=1,nz1 do i=1,nx1*ny1 fbar(k,ez) = fbar(k,ez)+area(i,f,e)*f(i,1,k,e) wght(k,ez) = wght(k,ez)+area(i,f,e) enddo enddo enddo call gop(fbar,work,'+ ',nz1*nelv) call gop(wght,work,'+ ',nz1*nelv) do i=1,nz1*nelz fbar(i,1)=fbar(i,1)/wght(i,1) ! If you want the average enddo That should pretty much work as is... You need to specify nelz and lelz >= nelz. Paul On Mon, 15 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi, > > I work in cylindrical geometry and want to evaluate an integral of one of > scalar fields over the circular cross section at fixed position z_0. I > suppose that the best way would be to make use of the GLL quadrature formulas > on the elements after picking the elements at desired height z_0. I have two > short questions: > > 1/ Is it correct that xm1, ym1, zm1 are the coordinate arrays, i.e. fixing > for example zm1(i,1,1,1)=0.5 would then give all elements that contain nodes > in exactly this plane? > > 2/ Are the GLL weights at the primary and secondary nodes stored in a > specific array or do I have to evaluate them for each element, e.g. by > combination of 1d routines which are collected in speclib.f? > > Thanks in advance, Joerg. > > _______________________________________________ > 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 Oct 16 09:59:46 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 16 Oct 2012 08:59:46 -0600 Subject: [Nek5000-users] write/read "avg1" data for restart Message-ID: Hello Neks. I'm working with the turbulent channel flow problem. I want to write out the data uavg calculated by avg1, i.e., call avg1(uavg,vx ,alpha,beta,n,'uavg',ifverbose) from all compute cores to a single file that can be read in at restart. I plan to update data for alpha and beta so that the avg1 routine can be restarted as well -- that part is straight forward. Are there two routines that I can use to write and then read the uavg data? I know there are some related routines in avg_all(), but I'm looking for some stripped-down version where I only worry about this one field. Incidentally, my intention is to run averaging for a period and then start the gathering information on the fluctuating components (based on the avg calculated for a longer time) of the velocity field. Cheers, Mike From nek5000-users at lists.mcs.anl.gov Wed Oct 17 11:11:06 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 17 Oct 2012 10:11:06 -0600 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis Message-ID: Hi Katie, In regard to your int_tp routine, am I correct that it's not equipped to handle a mesh file that was originally generated with genbox, but then "stretched" in usrdat? Thanks, Mike Hi, I have added an interpolation tool to the repo, int_tp, in nek5_svn/trunk/tools/int_tp There is also a README in that directory with instructions on the details of using the tool. (Note - int_tp should be compiled as any standard nek tool in the trunk/tools/ directory with "maketools int_tp" or "maketools all") Let me know if you encounter complications. Thanks, Katie From nek5000-users at lists.mcs.anl.gov Wed Oct 17 13:22:00 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 17 Oct 2012 13:22:00 -0500 Subject: [Nek5000-users] Transfer data from an nelx*nely*nelz array of Nth-order to an n*n*n array for FFT analysis In-Reply-To: References: Message-ID: Hi Mike, Yes, int_tp needs a .box file that will describe the geometry of the data that is in the files to be interpolated. Basically, it will take the geometry of the old and create an interpolation operator to the new geometry and apply that to the rest of the fields to be interpolated on. So the .box file must reflect the data in the files in file.list You might be able to create a .box of the stretched elements if you write in the xyz distribution of the stretched elements in the .box file by outputting the endpoints of each element in usrdat. Best, Katie On Wed, Oct 17, 2012 at 11:11 AM, wrote: > Hi Katie, > > In regard to your int_tp routine, am I correct that it's not equipped to > handle a mesh file that was originally generated with genbox, but then > "stretched" in usrdat? > > Thanks, > Mike > > Hi, > > I have added an interpolation tool to the repo, int_tp, in > nek5_svn/trunk/tools/int_tp > > There is also a README in that directory with instructions on the details > of using the tool. > > (Note - int_tp should be compiled as any standard nek tool in the > trunk/tools/ directory with "maketools int_tp" or "maketools all") > > Let me know if you encounter complications. > > Thanks, > Katie > > > _______________________________________________ > 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 Thu Oct 18 12:49:57 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 18 Oct 2012 19:49:57 +0200 Subject: [Nek5000-users] Area integral calculation in Nek In-Reply-To: References: Message-ID: Hi Paul, I attach a version with two corrections. This one should work now correctly. Thanks once more. Joerg. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ subroutine vertical_mean_profile(ff) include 'SIZE' include 'TOTAL' integer nelz parameter(nelz=32) real ff(nx1,ny1,nz1,nelv) real fbar(1:nz1,1:nelz) real wght(1:nz1,1:nelz) real work(1:nz1,1:nelz) integer e,eg,ex,ey,ez,f nelxy = nelgv/nelz !-----Set both arrays to zero call rzero(fbar,nz1*nelz) call rzero(wght,nz1*nelz) !-----Pick face 5 to evaluate surface Jacobian f = 5 do e=1,nelv eg = lglel(e) call get_exyz(ex,ey,ez,eg,nelxy,1,nelz) do k=1,nz1 do i=1,nx1*ny1 fbar(k,ez) = fbar(k,ez)+area(i,1,f,e)*ff(i,1,k,e) wght(k,ez) = wght(k,ez)+area(i,1,f,e) enddo enddo enddo !-----Gather over all processes (-> mpi_allreduce) call gop(fbar,work,'+ ',nz1*nelz) call gop(wght,work,'+ ',nz1*nelz) !-----Area average do i=1,nz1*nelz fbar(i,1)=fbar(i,1)/wght(i,1) enddo !-----Output of the vertical profile of planar averages ! ! Example with 32 (=nelz) vertical elements and lx1=ly1=lz1=4: ! -> 2 internal vertical GLL points per element ! -> 97 vertical planes, here output of 96 ! !------------------------------------------------------------ if(nid.eq.0)then do k=1,nelz do i=1,nz1-1 write(10,*)fbar(i,k),wght(i,k) enddo enddo endif return end Am 15.10.2012 um 22:15 schrieb nek5000-users at lists.mcs.anl.gov: > > Hi Joerg, > > If your geometry came from n2to3, then your data > is organized into planar sections and you can compute > > / > F(z) = | f(x,y,z) dx dy > /A > > as follows: > > common /scruz/ fbar(lz1,lelz),wght(lz1,lelz),work(lz1,lelz) > integer e,eg,ex,ey,ez,f > > nelz = [how many levels you have in z] > nelxy = nelgv/nelz ! Number of elements in a plane > > call rzero(fbar,nz1*nelz) > call rzero(wght,nz1*nelz) > > f = 5 ! Pick face 5 to evaluate surface Jacobian > > do e=1,nelv > eg = lglel(e) > call get_exyz(ex,ey,ez,eg,nelxyz,1,nelz) > do k=1,nz1 > do i=1,nx1*ny1 > fbar(k,ez) = fbar(k,ez)+area(i,f,e)*f(i,1,k,e) > wght(k,ez) = wght(k,ez)+area(i,f,e) > enddo > enddo > enddo > call gop(fbar,work,'+ ',nz1*nelv) > call gop(wght,work,'+ ',nz1*nelv) > do i=1,nz1*nelz > fbar(i,1)=fbar(i,1)/wght(i,1) ! If you want the average > enddo > > That should pretty much work as is... You need to specify > nelz and lelz >= nelz. > > Paul > > > On Mon, 15 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi, >> >> I work in cylindrical geometry and want to evaluate an integral of one of >> scalar fields over the circular cross section at fixed position z_0. I >> suppose that the best way would be to make use of the GLL quadrature formulas >> on the elements after picking the elements at desired height z_0. I have two >> short questions: >> >> 1/ Is it correct that xm1, ym1, zm1 are the coordinate arrays, i.e. fixing >> for example zm1(i,1,1,1)=0.5 would then give all elements that contain nodes >> in exactly this plane? >> >> 2/ Are the GLL weights at the primary and secondary nodes stored in a >> specific array or do I have to evaluate them for each element, e.g. by >> combination of 1d routines which are collected in speclib.f? >> >> Thanks in advance, Joerg. >> >> _______________________________________________ >> 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 Oct 18 12:57:06 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 18 Oct 2012 12:57:06 -0500 (CDT) Subject: [Nek5000-users] Area integral calculation in Nek In-Reply-To: References: Message-ID: Thanks Joerg, Looks good. One thing to note that nz1 is variable and not a parameter, so there will be an issue with the fbar() declaration. I would suggest using lz1 and lelz for declaration of fbar(), etc., as these parameters are already established for that role. I think the issue you ran into before was that I failed to include ZPER in the include statement, which is how nelz becomes known to the routine. (It remains, however, up to the user to set nelz and lelz to the proper values.) Also, I often find it handy to define a "zbar()" which computes the mean of z and then prints this out along with fbar and wght. That makes it easy to plot (zbar,fbar), etc. Cheers, Paul On Thu, 18 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > Hi Paul, > > I attach a version with two corrections. This one should work now correctly. > Thanks once more. > > Joerg. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > subroutine vertical_mean_profile(ff) > include 'SIZE' > include 'TOTAL' > > integer nelz > parameter(nelz=32) > > real ff(nx1,ny1,nz1,nelv) > > real fbar(1:nz1,1:nelz) > real wght(1:nz1,1:nelz) > real work(1:nz1,1:nelz) > > integer e,eg,ex,ey,ez,f > > nelxy = nelgv/nelz > > !-----Set both arrays to zero > call rzero(fbar,nz1*nelz) > call rzero(wght,nz1*nelz) > > > !-----Pick face 5 to evaluate surface Jacobian > f = 5 > > do e=1,nelv > > eg = lglel(e) > call get_exyz(ex,ey,ez,eg,nelxy,1,nelz) > > do k=1,nz1 > do i=1,nx1*ny1 > fbar(k,ez) = fbar(k,ez)+area(i,1,f,e)*ff(i,1,k,e) > wght(k,ez) = wght(k,ez)+area(i,1,f,e) > enddo > enddo > > enddo > > !-----Gather over all processes (-> mpi_allreduce) > call gop(fbar,work,'+ ',nz1*nelz) > call gop(wght,work,'+ ',nz1*nelz) > > !-----Area average > do i=1,nz1*nelz > fbar(i,1)=fbar(i,1)/wght(i,1) > enddo > > !-----Output of the vertical profile of planar averages > ! > ! Example with 32 (=nelz) vertical elements and lx1=ly1=lz1=4: > ! -> 2 internal vertical GLL points per element > ! -> 97 vertical planes, here output of 96 > ! > !------------------------------------------------------------ > if(nid.eq.0)then > do k=1,nelz > do i=1,nz1-1 > write(10,*)fbar(i,k),wght(i,k) > enddo > enddo > endif > > return > end > > > > > Am 15.10.2012 um 22:15 schrieb nek5000-users at lists.mcs.anl.gov: > >> >> Hi Joerg, >> >> If your geometry came from n2to3, then your data >> is organized into planar sections and you can compute >> >> / >> F(z) = | f(x,y,z) dx dy >> /A >> >> as follows: >> >> common /scruz/ fbar(lz1,lelz),wght(lz1,lelz),work(lz1,lelz) >> integer e,eg,ex,ey,ez,f >> >> nelz = [how many levels you have in z] >> nelxy = nelgv/nelz ! Number of elements in a plane >> >> call rzero(fbar,nz1*nelz) >> call rzero(wght,nz1*nelz) >> >> f = 5 ! Pick face 5 to evaluate surface Jacobian >> >> do e=1,nelv >> eg = lglel(e) >> call get_exyz(ex,ey,ez,eg,nelxyz,1,nelz) >> do k=1,nz1 >> do i=1,nx1*ny1 >> fbar(k,ez) = fbar(k,ez)+area(i,f,e)*f(i,1,k,e) >> wght(k,ez) = wght(k,ez)+area(i,f,e) >> enddo >> enddo >> enddo >> call gop(fbar,work,'+ ',nz1*nelv) >> call gop(wght,work,'+ ',nz1*nelv) >> do i=1,nz1*nelz >> fbar(i,1)=fbar(i,1)/wght(i,1) ! If you want the average >> enddo >> >> That should pretty much work as is... You need to specify >> nelz and lelz >= nelz. >> >> Paul >> >> >> On Mon, 15 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >> >>> Hi, >>> >>> I work in cylindrical geometry and want to evaluate an integral of one of >>> scalar fields over the circular cross section at fixed position z_0. I >>> suppose that the best way would be to make use of the GLL quadrature formulas >>> on the elements after picking the elements at desired height z_0. I have two >>> short questions: >>> >>> 1/ Is it correct that xm1, ym1, zm1 are the coordinate arrays, i.e. fixing >>> for example zm1(i,1,1,1)=0.5 would then give all elements that contain nodes >>> in exactly this plane? >>> >>> 2/ Are the GLL weights at the primary and secondary nodes stored in a >>> specific array or do I have to evaluate them for each element, e.g. by >>> combination of 1d routines which are collected in speclib.f? >>> >>> Thanks in advance, Joerg. >>> >>> _______________________________________________ >>> 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 Oct 18 14:15:21 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 18 Oct 2012 21:15:21 +0200 Subject: [Nek5000-users] Area integral calculation in Nek In-Reply-To: References: Message-ID: Hi Paul, > Looks good. One thing to note that nz1 is variable and not a parameter, > so there will be an issue with the fbar() declaration. > I would suggest using lz1 and lelz for declaration of fbar(), > etc., as these parameters are already established for that role. change to lz1 is fine. I run in trouble whenever I use lelz. The attached version works. subroutine vertical_mean(ff) include 'SIZE' include 'TOTAL' ! include 'ZPER' integer nelz parameter(nelz=32) real ff(lx1,ly1,lz1,lelt) ! common /scruz/ fbar(lz1,lelz),wght(lz1,lelz),work(lz1,lelz) real fbar(lz1,nelz) real wght(lz1,nelz) real work(lz1,nelz) integer e,eg,ex,ey,ez,f ! lelz=32 ! nelz=32 nelxy = nelgv/nelz !-----Set both arrays to zero call rzero(fbar,lz1*nelz) call rzero(wght,lz1*nelz) !-----Pick face 5 to evaluate surface Jacobian f = 5 do e=1,nelv eg = lglel(e) call get_exyz(ex,ey,ez,eg,nelxy,1,nelz) do k=1,nz1 do i=1,nx1*ny1 fbar(k,ez) = fbar(k,ez)+area(i,1,f,e)*ff(i,1,k,e) wght(k,ez) = wght(k,ez)+area(i,1,f,e) enddo enddo enddo !-----Gather over all processes (-> mpi_allreduce) call gop(fbar,work,'+ ',lz1*nelz) call gop(wght,work,'+ ',lz1*nelz) !-----Area average do i=1,lz1*nelz fbar(i,1)=fbar(i,1)/wght(i,1) enddo !-----Output of the vertical profile of plane averages ! ! Example with 32 (=nelz) vertical elements and lx1=ly1=lz1=4: ! -> 2 internal vertical GLL points per element ! -> 97 vertical planes, here output of 96 ! !------------------------------------------------------------ if(nid.eq.0)then OPEN(10,file="uzt.dat",access="append") do k=1,nelz do i=1,lz1-1 write(10,*)fbar(i,k),wght(i,k) enddo enddo CLOSE(10) endif return end Thanks Joerg. > I think the issue you ran into before was that I failed to include > ZPER in the include statement, which is how nelz becomes known > to the routine. (It remains, however, up to the user to set > nelz and lelz to the proper values.) > > Also, I often find it handy to define a "zbar()" which computes > the mean of z and then prints this out along with fbar and wght. > That makes it easy to plot (zbar,fbar), etc. > > Cheers, > > Paul > > > On Thu, 18 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Paul, >> >> I attach a version with two corrections. This one should work now correctly. >> Thanks once more. >> >> Joerg. >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> subroutine vertical_mean_profile(ff) >> include 'SIZE' >> include 'TOTAL' >> >> integer nelz >> parameter(nelz=32) >> >> real ff(nx1,ny1,nz1,nelv) >> >> real fbar(1:nz1,1:nelz) >> real wght(1:nz1,1:nelz) >> real work(1:nz1,1:nelz) >> >> integer e,eg,ex,ey,ez,f >> >> nelxy = nelgv/nelz >> >> !-----Set both arrays to zero >> call rzero(fbar,nz1*nelz) >> call rzero(wght,nz1*nelz) >> >> >> !-----Pick face 5 to evaluate surface Jacobian >> f = 5 >> >> do e=1,nelv >> >> eg = lglel(e) >> call get_exyz(ex,ey,ez,eg,nelxy,1,nelz) >> >> do k=1,nz1 >> do i=1,nx1*ny1 >> fbar(k,ez) = fbar(k,ez)+area(i,1,f,e)*ff(i,1,k,e) >> wght(k,ez) = wght(k,ez)+area(i,1,f,e) >> enddo >> enddo >> >> enddo >> >> !-----Gather over all processes (-> mpi_allreduce) >> call gop(fbar,work,'+ ',nz1*nelz) >> call gop(wght,work,'+ ',nz1*nelz) >> >> !-----Area average >> do i=1,nz1*nelz >> fbar(i,1)=fbar(i,1)/wght(i,1) >> enddo >> >> !-----Output of the vertical profile of planar averages >> ! >> ! Example with 32 (=nelz) vertical elements and lx1=ly1=lz1=4: >> ! -> 2 internal vertical GLL points per element >> ! -> 97 vertical planes, here output of 96 >> ! >> !------------------------------------------------------------ >> if(nid.eq.0)then >> do k=1,nelz >> do i=1,nz1-1 >> write(10,*)fbar(i,k),wght(i,k) >> enddo >> enddo >> endif >> >> return >> end >> >> >> >> >> Am 15.10.2012 um 22:15 schrieb nek5000-users at lists.mcs.anl.gov: >> >>> >>> Hi Joerg, >>> >>> If your geometry came from n2to3, then your data >>> is organized into planar sections and you can compute >>> >>> / >>> F(z) = | f(x,y,z) dx dy >>> /A >>> >>> as follows: >>> >>> common /scruz/ fbar(lz1,lelz),wght(lz1,lelz),work(lz1,lelz) >>> integer e,eg,ex,ey,ez,f >>> >>> nelz = [how many levels you have in z] >>> nelxy = nelgv/nelz ! Number of elements in a plane >>> >>> call rzero(fbar,nz1*nelz) >>> call rzero(wght,nz1*nelz) >>> >>> f = 5 ! Pick face 5 to evaluate surface Jacobian >>> >>> do e=1,nelv >>> eg = lglel(e) >>> call get_exyz(ex,ey,ez,eg,nelxyz,1,nelz) >>> do k=1,nz1 >>> do i=1,nx1*ny1 >>> fbar(k,ez) = fbar(k,ez)+area(i,f,e)*f(i,1,k,e) >>> wght(k,ez) = wght(k,ez)+area(i,f,e) >>> enddo >>> enddo >>> enddo >>> call gop(fbar,work,'+ ',nz1*nelv) >>> call gop(wght,work,'+ ',nz1*nelv) >>> do i=1,nz1*nelz >>> fbar(i,1)=fbar(i,1)/wght(i,1) ! If you want the average >>> enddo >>> >>> That should pretty much work as is... You need to specify >>> nelz and lelz >= nelz. >>> >>> Paul >>> >>> >>> On Mon, 15 Oct 2012, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> Hi, >>>> >>>> I work in cylindrical geometry and want to evaluate an integral of one of >>>> scalar fields over the circular cross section at fixed position z_0. I >>>> suppose that the best way would be to make use of the GLL quadrature formulas >>>> on the elements after picking the elements at desired height z_0. I have two >>>> short questions: >>>> >>>> 1/ Is it correct that xm1, ym1, zm1 are the coordinate arrays, i.e. fixing >>>> for example zm1(i,1,1,1)=0.5 would then give all elements that contain nodes >>>> in exactly this plane? >>>> >>>> 2/ Are the GLL weights at the primary and secondary nodes stored in a >>>> specific array or do I have to evaluate them for each element, e.g. by >>>> combination of 1d routines which are collected in speclib.f? >>>> >>>> Thanks in advance, Joerg. >>>> >>>> _______________________________________________ >>>> 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 Wed Oct 24 05:55:33 2012 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 24 Oct 2012 12:55:33 +0200 Subject: [Nek5000-users] hpts for perturbation quantities Message-ID: Dear Neks, Would it be of any interest (to anyone else than me) to make an option for hpts to write out perturbation quantities vxp,vyp,vzp,prp,tp? (instead of vx,vy...) I realise this can be done by repeated "opcopy", but maybe there is a nicer solution? Best regards, Outi ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.