[Nek5000-users] Reading binary data

[nek5000-users at lists.mcs.anl.gov]

Sorry -- I'm still not getting it.

The first file had mesh coordinates and field information in it; here is what the header shows:

#std 4  8  8  8        512        512  0.2000000000000E+02      1000      0      1 XUPS02 

The size of this file is  9476232, but I can't figure out what is contributing to that size.  For the next field file, the header shows:

#std 4  8  8  8        512        512  0.1200000000000E+03      6000      0      1 UPS02 

The size of this file is 6318216, which is exactly predicted by the expression below -- all is well.

What is the makeup of the 3158016 bytes difference between these files?  The mesh coordinates alone are only

512 * 8^3 * 4 * 3 (ndim) = 3145728 bytes

Where and what are the remaining 12288 bytes?

Thanks.

  

On Aug 11, 2010, at 4:09 PM, <nek5000-users at lists.mcs.anl.gov> wrote:

> No, if a field file only contains the geometry (mesh coordinates) nfields is equal to ndim (2 or 3).
> Stefan
> 
> 
> On Aug 12, 2010, at 12:01 AM, <nek5000-users at lists.mcs.anl.gov> wrote:
> 
>> Stefan,
>> 
>> Thanks.  I figured that, but the binary file size doesn't seem to be adding up.    For example,  a field file that doesn't have geometry data is the size described by the initial thread, i.e.
>> 
>> 132 bytes + 4 bytes + nel* 4 bytes + nfields*nxyz*nel* wdsizo  +  nfields*2*nel * 4 bytes
>> 
>> My naive assumption was that a field file with xyz data would then have the additional space requirement of
>> 
>> nx*ny*nz*nel*wdsizo
>> 
>> but the file's bigger than that.  What info am I missing?  
>> 
>> --Mike
>> 
>> On Aug 11, 2010, at 3:50 PM, <nek5000-users at lists.mcs.anl.gov> wrote:
>> 
>>> Hi Mike,
>>> 
>>> vector fields (e.g. mesh coordinates) are stored in the following way:
>>> 
>>> LOOP over all elements
>>> 	LOOP i = {x,y,z}
>>> 		 i for all GLL points (internal element points)
>>> 	ENDLOOP
>>> ENDLOOP
>>> 
>>> 2D example with (E=2,N=2):
>>> x1_1 x2_1 x3_1 y1_1 y2_1 y3_1 x1_1 x2_2 x3_2 y1_2 y2_2 y3_2
>>> 
>>> where x2_1 means the x-coordinate of the 2nd GLL point of element 1.
>>> 
>>> hth,
>>> Stefan 
>>> 
>>> On Aug 11, 2010, at 11:34 PM, <nek5000-users at lists.mcs.anl.gov> wrote:
>>> 
>>>> 
>>>> Hello All.  I found this helpful message from Stefan regarding the structure of a binary field file.   Could someone please tell me what the structure is when the geometry info is also contained?
>>>> 
>>>> Thanks!
>>>> --Mike
>>>> 
>>>> nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov 
>>>>> Thu May 6 07:18:03 CDT 2010
>>>>> 	• Previous message: [Nek5000-users] Reading binary data
>>>>> 	• Next message: [Nek5000-users] History points
>>>>> 	• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>>>> Hi Fred,
>>>>> 
>>>>> header: 132 bytes
>>>>> endian test tag: 4 bytes
>>>>> element mapping: nel* 4 bytes
>>>>> data: nfields*nxyz*nel* wdsizo (where wdsizo is 4 or 8 bytes)
>>>>> metadata (min/max values): nfields*2*nel * 4 bytes
>>>>> 
>>>>> Stefan
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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