case_files.rst: where does `test_value` live, and is `chrefcuts` documented?

[slitvinov]

The field-file (.f#####) header table in source/problem_setup/case_files.rst puts test_value at offset 112 (width 4), but the line below the table says "data starts at offset 136 bytes" — 136 is what you get if a 132-byte ASCII header is followed immediately by a 4-byte float. The two don't agree, so I checked which one matches the files.

Bytes around offsets 112 and 132 in a field file produced by Nek5000/short_tests/double_shear from a fresh clone, with two minimal changes:

$ diff Nek5000/short_tests/double_shear/double_shear.par double_shear.par
22a23,25
> 
> [GENERAL]
> writeInterval = 100

$ diff Nek5000/core/SIZE.template SIZE
12c12
<       parameter (ldim=3)               ! domain dimension (2 or 3)
---
>       parameter (ldim=2)               ! domain dimension (2 or 3)

Bytes 109 onward of double_shear0.f00001 produced by this case:

109  0x46  F        <- if_press_mesh (l1)
110  0x20  ' '      <- 1x space
111  0x30  '0'  \
112  0x30  '0'   \
113  0x30  '0'    > chrefcuts (a4) -- "0000" = no h-refine
114  0x30  '0'   /
115..131       21 bytes of space padding (0x20)
132  0xfa
133  0x61   <- test_pattern (4 bytes, little-endian fp32)
134  0xd1
135  0x40   <- 0xfa61d140 = 6.5432100... = 6.54321

Python reader:

import struct, sys
with open(sys.argv[1], "rb") as f:
    blob = f.read(140)
print("bytes 110..131 (hex):", blob[110:132].hex())
print("float at offset 112: ", struct.unpack("<f", blob[112:116])[0])
print("float at offset 132: ", struct.unpack("<f", blob[132:136])[0])

$ python3 read_demo.py double_shear0.f00001
bytes 110..131 (hex): 20303030302020202020202020202020202020202020
float at offset 112:  1.4923e-19
float at offset 132:  6.5432100296020508

Same numbers from a header synthesized in Fortran with the format string from Nek5000/core/prepost.f:2103-2105 (mfo_write_hdr):

program nek_hdr_demo
  implicit none
  character(132) :: hdr
  real(4)        :: test_pattern, at112, at132
  character(1)   :: b112(4), b132(4)
  integer        :: u

  hdr = repeat(' ', 132)
  write(hdr, 1) 4, 8, 8, 8, 1, 1, 0.0d0, 0, 0, 1, &
                'X','U','P',' ',' ',' ',' ',' ',' ',' ', 0.0e0, .false., '0000'
1 format('#std',1x,i1,1x,i2,1x,i2,1x,i2,1x,i10,1x,i10,1x,e20.13, &
         1x,i9,1x,i6,1x,i6,1x,10a1,1pe15.7,1x,l1,1x,a4)

  test_pattern = 6.54321e0
  open(newunit=u, file='demo.f00000', access='stream', &
       form='unformatted', status='replace')
  write(u) hdr
  write(u) test_pattern
  close(u)

  open(newunit=u, file='demo.f00000', access='stream', &
       form='unformatted', status='old')
  read(u, pos=113) b112
  read(u, pos=133) b132
  close(u)
  at112 = transfer(b112, at112)
  at132 = transfer(b132, at132)
  write(*,'(a,f10.5)') 'float at offset 112: ', at112
  write(*,'(a,f10.5)') 'float at offset 132: ', at132
end program

$ gfortran -o demo nek_hdr_demo.f90 && ./demo
float at offset 112:    0.00000
float at offset 132:    6.54321

This matches mfo_write_hdr at prepost.f:2107-2110 — two separate byte_write calls, first the 132-byte header then the 4-byte test pattern — iHeaderSize=132 in core/RESTART:19, and the reader in core/ic.f (mfi_prepare) mirrors the same two-call pattern.

The table also doesn't mention chrefcuts: bytes 111..114 hold a 4-character h-refinement schedule, written by the 1x,a4 at the end of mfo_write_hdr's format and decoded by hrefcuts_c2i on the read side. Without h-refinement it reads "0000".

Happy to send a PR moving test_value to offset 132 and adding a row for chrefcuts at offset 111, width 4.

[yslan]

chrefcuts is a new feature that is backward compatible to older version.
I made a PR for that part of the doc (also fix the table) here: #153