[Nek5000-users] Reading binary data
nek5000-users at lists.mcs.anl.gov
nek5000-users at lists.mcs.anl.gov
Wed Aug 11 17:21:54 CDT 2010
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
More information about the Nek5000-users
mailing list