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