[Nek5000-users] Specifying boundary condition from external text file

Mon Jul 28 17:05:34 CDT 2014

Hi Tom,

The problem in parallel is that
e=gllel(eg)
is giving you the local element count for a global element.  Thus, this
value is relative to the processor.
(I.E. on a 4 element domain with 4 processors running, the global numbers
will be 1,2,3,4 whereas the local are 1,1,1,1 because each element is the
first element on that processor.)

In order to know what element goes to what data point, you will need to use
the global number which is probably eg, depending on your setup.

Of course, this is all dependant on the fact that your elements are in a
nice box that is numbered as you described.

There could be a more elegant solution to address the inlet elements, but
you would still need to calculate which data point goes to which nodal
point since in parallel, you will not necessarily be accessing the array
sequentially.

hth,
Katherine

On Sun, Jul 27, 2014 at 1:01 AM, <nek5000-users at lists.mcs.anl.gov> wrote:

> Hello again,
>
> I want to provide more information, and more detail of my exact case to
> hopefully make it easier to get assistance.
>
> Using the 2D blasius example as a base, I have created a mesh file
> "box.box" that allow me to modify the domain.
> After renaming the necessary files (program is now called 'box') this
> works fine with the an unmodified blasius.usr (now 'box.usr') code.
>
> The next step I took was to change the boundary conditions in userbc() [
> and useric()] in box.usr.
> As I understand, the nodes on the inlet plane are called sequentially from
> bottom to top, by element number ('e') and then by node number ('iy').
> The elements are not numbered sequentially from bottom to top, but rather
> left-to-right, then back to the start, then up, then left-to-right again.
> Therefore for a domain of 410 elements in the streamwise (x) direction,
> the element numbers along the inlet are, from bottom to top: 1, 411, 821,
> etc.
> There are 12 elements in the wall normal (y) direction.
>
> I have an array ('ArrangedInlet') in the subroutine containing the
> horizontal velocity component, ux, value for each of the nodes along the
> inlet according to their y coordinate  The original data lives in the file
> called 'InletArranged.out'. This is output by a process in MATLAB so there
> is freedom in what is included and how it is arranged and formatted.
> The data points are currently entered manually. This is initially to test,
> but it is intended that this is read automatically from the external file.
> However in order to assign the correct velocity value to the correct
> position along the inlet, I arranged the data in the array such that the
> rows counted iy from 1 to 8 (lx1) and each is addressing a node: Row
> 1=Node 1; Row 2 = Node 2, etc. where the nodes go bottom-to-top (y=0 to
> y=10),
> The columns contained the data for each element along the inlet - ordered
> from bottom to top. At the moment each row .
>
> Using the same domain as described above (NELX, NELY)=(410, 12):
>  column 1 contains data at each node ('iy') for element 1,
> column 2 contains data at each node ('iy') for element 411,
> column 3 contains data at each node ('iy') for element 821,
> and so on.
>
> I got around this by using the following transformation:
> COL=((e-1)/NELX)+1
> where:
> COL is the column number of the array (1 to 12);
> e  = gllel(eg) is the element number;
> NELX = 410 is the number of elements in the streamwise (x) direction.
>
> This is then read by the program by:
> ux = ArrangedInlet(iy,COL)
>
> And it works! ... but only for a serial case. Also, it currently only
> works for the single set of data.
>
> As soon as I run the case in parallel the addressing changes and this
> method does not work.
> The element addressing no longer appears to have a discernible pattern.
>
> *So my questions are primarily:*
> *1) How can I get the values onto the inlet and make it work in parallel? *
> and
> *2) Is there a more elegant/efficient method of doing this? IE. a way of
> calling the inlet nodes only?*
>
> I have attached my case "box_2D_Inlet.tar.gz".
> I have tested it and it does work, however currently it bombs out after 9
> iterations, but I'm really only testing the inlet parameters.
>
> Looking forward to any assistance.
>
> Thanks,
>
> Tom.
>
>
>
> On 17 July 2014 10:37, Thomas Yankos <s3286374 at student.rmit.edu.au> wrote:
>
>> Hi All,
>>
>> I'm using NEK5000 for a university project. I've found it to be
>> blissfully fast and relatively easy to use.
>>
>> The problem I'm doing is a blasius boundary layer case with perturbations
>> (simulating Tollmien–Schlichting waves), initially in 2D as per the blasius
>> example, then eventually moving to 3D.
>> I've so far been successful in running the blasius example case, and
>> modifying the mesh, polynomial order and other input parameters.
>>
>> Now however, I want to change the way the boundary conditions are defined.
>> I have input files that are unique for each time step specifying velocity
>> and pressures along a line (the inlet) in text format. It would be possible
>> to re-format these as .csv or another file if necessary.
>>
>> *How can I get NEK to read these files as boundary conditions on the
>> inlet for each time step?*
>>
>> I understand it will be a specification in the user userbc subroutine in
>> blasius.usr however I'm not sure how to actually implement this.
>> Doing it in 2D will be a precursor to a 3D simulation with the file
>> specifying the inlet *plane *in a text file, rather than just a *line*.
>>
>> Looking forward to a response.
>>
>> Warm Regards,
>> Tom.
>>
>
>
> _______________________________________________
> 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/20140728/6bf18f8c/attachment.html>