[Nek5000-users] New Recycling BC based on interpolation

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Fri Jul 23 11:26:00 CDT 2010 


Hi Aleks and Stephan, 



I have a question directly related to this.  I would like to use the hpts() routine for my conjugate case, however like Markus mentioned, there is no support for a conjugate case at the moment.  Were ya'll able to fix this? 



Thanks, 

Michael 




----- Original Message ----- 
From: nek5000-users at lists.mcs.anl.gov 
To: nek5000-users at lists.mcs.anl.gov 
Sent: Monday, July 19, 2010 8:38:05 AM GMT -06:00 US/Canada Central 
Subject: Re: [Nek5000-users] New Recycling BC based on interpolation 

Hi Aleks, 

what was your plan to fix it? 

In fact I think findpts_eval() should work as is but there is no-err handling if you try to interpolate on a point in the solid using an input field based on the v-mesh. 

Ok we don't need an err-handling at the moment. You'll get a ZERO value back although it is an invalid point for an input field based on the v-mesh. 

Why is that? 
At the moment, all field arrays have the same layout and size (lx1,ly1,lz1,lelt) independent of the mesh type (v or T). We simply set all values of a v-variable to ZERO for iel>nelv and we don't touch these segments later on. 

Stefan 

  


On Jul 19, 2010, at 3:25 PM, nek5000-users at lists.mcs.anl.gov wrote: 

> Hi Stefan, 
> 
> Yes, we have noticed you changed the interface -- and the latest version of Recycling Bcs w/ interpolation works for the latest repo version (548).   
> 
> Eventually we can get it working for CHT too. 
> 
> Best, 
> Aleks 
> 
> 
> 
> ----- Original Message ----- 
> From: nek5000-users at lists.mcs.anl.gov 
> To: nek5000-users at lists.mcs.anl.gov 
> Sent: Monday, July 19, 2010 7:05:21 AM GMT -06:00 US/Canada Central 
> Subject: Re: [Nek5000-users] New Recycling BC based on interpolation 
> 
> Hi Guys, 
> 
> I worked on the interpolation wrappers over the last months and I am not sure if the new recycling BC is compatible to the latest repo-version? 
> 
> Paul/Aleks: can you comment on that? 
> 
> 
> Now, in the case of CHT (nelgt>nelgv) findpts_eval() won't work! I guess the size of the input field has to match the dimensions of XM1,YM1,ZM1 specified in inpts_setup(). 
> 
> I will talk to James if we can come up with an easy fix for that. 
> 
> 
> Stefan   
> 
> 
> 
> -----Original Message----- 
> From: nek5000-users-bounces at lists.mcs.anl.gov on behalf of nek5000-users at lists.mcs.anl.gov 
> Sent: Sun 7/18/2010 13:53 
> To: nek5000-users at lists.mcs.anl.gov 
> Subject: Re: [Nek5000-users] New Recycling BC based on interpolation 
> 
> 
> 
> Hi Markus, 
> 
> this stuff is all brand new and you are in the leading edge 
> of the testing (since none of us are exercising it in our 
> own applications), so there will be a bit of development as 
> we go forward.  We can readily fix interp_v (but I advise 
> using it now in order to identify other issues). 
> 
> interpv is _much_ more expensive than gs_op. 
> 
> However, if one takes 1 part in a million and the other 1 
> part in 10,000 of the run time, then both are negligible. 
> So the question is really relative to the wall-clock time. 
> 
> Paul 
> 
> 
> 
> On Sun, 18 Jul 2010, nek5000-users at lists.mcs.anl.gov wrote: 
> 
>> Hi, 
>> 
>> no, I haven't done any speed comparison. So I take it there is no principal 
>> difference between intpts and gs_op in terms of computational cost? 
>> 
>> I was referring to line 172f of the new recycling BC code: 
>> " 
>>     if (nelgt.ne.nelgv) call exitti 
>>    $   ('ABORT: interp_v() nelgt.ne.nelgv not yet supported!$',nelgv) 
>> " 
>> and was wondering if that is due to something in intpts and if so, if the 
>> same constraint would apply to findpts. 
>> 
>> Markus 
>> 
>> 
>> nek5000-users at lists.mcs.anl.gov wrote: 
>>> 
>>> Hi Markus, 
>>> 
>>> I don't know why this wouldn't work for nelgt > nelgv. 
>>> 
>>> I would say we don't know the performance hit yet - I think 
>>> someone is looking into this question.  Performance will of course vary 
>>> significantly from problem to problem and platform 
>>> to platform.   I suspect that it should not be a major hit --- 
>>> have you observed otherwise? 
>>> 
>>> Paul 
>>> 
>>> 
>>> On Sat, 17 Jul 2010, nek5000-users at lists.mcs.anl.gov wrote: 
>>> 
>>>> Hi Aleks, 
>>>> 
>>>> thanks for the code, I looked over it and have two questions: 
>>>> -at some point, it is mentioned that this method does not work if 
>>>> nelgt>nelgv. Why is that? I am asking because this will be applied to a 
>>>> conjugate HT problem (although the recycling part is purely concerning 
>>>> flow+convection). Will this problem also occur when only findpts is used 
>>>> instead of intpts? 
>>>> -is there a performance difference between calling intpts as opposed to 
>>>> gs_op (as is done in the turbJet example) every time step for large scale 
>>>> production runs? The latter is what I used in my version. 
>>>> 
>>>> Thanks, 
>>>> Markus 
>>>> 
>>>> 
>>>> nek5000-users at lists.mcs.anl.gov wrote: 
>>>>> Hi Michael and Markus, 
>>>>> 
>>>>> Here is a test case for an unsteady pipe flow with Michael's 
>>>>> GambitPipe.rea file which sets inlet Recycling BCs based on interpolation 
>>>>> from a cross-section downstream that you specify by a multiple of the 
>>>>> inlet normal: 
>>>>> 
>>>>> http://www.mcs.anl.gov/~obabko/z4.tgz 
>>>>> 
>>>>> 
>>>>> Let me know if you have any questions. 
>>>>> Best, 
>>>>> Aleks 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message ----- 
>>>>> From: nek5000-users at lists.mcs.anl.gov 
>>>>> To: nek5000-users at lists.mcs.anl.gov 
>>>>> Sent: Thursday, July 8, 2010 5:06:48 PM GMT -06:00 US/Canada Central 
>>>>> Subject: Re: [Nek5000-users] New Recycling BC method? 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> No worries, just checkin in to see how it was going, thanks for the 
>>>>> update! Look forward to trying it out! 
>>>>> 
>>>>> - Michael _______________________________________________ 
>>>>> Nek5000-users mailing list 
>>>>> Nek5000-users 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 
> _______________________________________________ 
> 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: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20100723/58885daf/attachment.html>

More information about the Nek5000-users mailing list