eX-Mech
Reading of `.fld` files
Hello,
It seems like pymech is based on reading of extension type .f01 and I have been unable to read my output files which have an extension type .fld01. Is this support already implemented? I tried reading one of my files and got an error as follows. I am using Nek5000 v19. Please let me know if you need any additional information.
In [1]: import pymech as pm
In [2]: pm.readnek('rb.fld01')
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
Cell In[2], line 1
----> 1 pm.readnek('rb.fld01')
File ~/.local/lib/python3.8/site-packages/pymech/neksuite/field.py:206, in readnek(fname, dtype, skip_vars)
199 return -1
200 #
201 # ---------------------------------------------------------------------------
202 # READ HEADER
203 # ---------------------------------------------------------------------------
204 #
205 # read header
--> 206 h = read_header(infile)
207 #
208 # identify endian encoding
209 etagb = infile.read(4)
File ~/.local/lib/python3.8/site-packages/pymech/neksuite/field.py:174, in read_header(path_or_file_obj)
171 raise IOError("Header of the file was too short.")
173 # Relying on attrs converter to type-cast. Mypy will complain
--> 174 return Header(header[1], header[2:5], *header[5:12])
File <attrs generated init pymech.neksuite.field.Header>:4, in __init__(self, wdsz, orders, nb_elems, nb_elems_file, time, istep, fid, nb_files, variables, realtype, nb_pts_elem, nb_dims, nb_vars)
2 _setattr = _cached_setattr_get(self)
3 _setattr('wdsz', __attr_converter_wdsz(wdsz))
----> 4 _setattr('orders', __attr_converter_orders(orders))
5 _setattr('nb_elems', __attr_converter_nb_elems(nb_elems))
6 _setattr('nb_elems_file', __attr_converter_nb_elems_file(nb_elems_file))
File ~/.local/lib/python3.8/site-packages/pymech/neksuite/field.py:26, in _as_tuple_of_ints(seq)
25 def _as_tuple_of_ints(seq):
---> 26 return tuple(int(s) for s in seq)
File ~/.local/lib/python3.8/site-packages/pymech/neksuite/field.py:26, in <genexpr>(.0)
25 def _as_tuple_of_ints(seq):
---> 26 return tuple(int(s) for s in seq)
ValueError: invalid literal for int() with base 10: b'1.0059306E-03'
As indicated by the error message, something is wrong with the header line in your file. It may be a different kind of file. See here for the specification of field files:
https://nek5000.github.io/NekDoc/problem_setup/case_files.html#restart-output-files-f
Hi, that's precisely what I was asking about. The files generated in my Nek5000 simulations are of the format .fld#### instead of .f#####. As far as I'm aware, Nek5000 can generate both kinds of output/checkpoint files - I'm not sure which parameter controls that. My question was if there's only support for files with extension .f#####. In addition, if someone can point out to me what the difference is between the two, that would also be great since there's very little documentation from Nek5000 folks on this. Thank you and grateful for this useful package!
Hi, that's precisely what I was asking about. The files generated in my Nek5000 simulations are of the format
.fld####instead of.f#####. As far as I'm aware, Nek5000 can generate both kinds of output/checkpoint files - I'm not sure which parameter controls that. My question was if there's only support for files with extension.f#####.
Your best guess is to figure out by doing a grep grep -i '.*fld.*' to find how these files were generated. In vanilla Nek5000 output files ARE checkpoint files, however there are other implementations like KTH-Toolbox, where a more complete multi-time step checkpoint is implemented. Are you using those?
In addition, if someone can point out to me what the difference is between the two, that would also be great since there's very little documentation from Nek5000 folks on this. Thank you and grateful for this useful package!
I don't think I can do much here without seeing the code. If you figure out how those files are written, you should be able to easily construct a reader based on readnek function.
If it is a file format built-in to Nek5000 and something which is missing from pymech, I will be more than happy to accept a PR reading that.
@AnkitBarik did you make any progress with the file you had difficulty reading?
@ashwinvis I just realized that if I hardcode params(66) = 4 inside subroutine usrdat2 which was what I was using, then Nek5000 produces .fld%02d files, while if I delete that line, it produces files with extension .f#####. I haven't looked into how to build a reader for them, but at least I found a workaround for producing the .f##### extension files. Both types can be read by the Visit reader with no issues.
@AnkitBarik That is a great lead! See https://nek5000.github.io/NekDoc/appendix.html for the explanation:
The parameter list is handled internally and is populated based on options prescribed in the .par file. In general, it is not recommend for users to override these parameters as their usage may be subject to change. However they can be set or referenced in the .usr file via the param() array. This list was explicitly set with the legacy .rea format.
P066 output format (0: ASCII, 4: legacy binary, 6: binary)
Since you seem to be activating a legacy format, it will be hard to find out the file structure from Nek5000 source code. Perhaps looking into Visit database bridge can be more useful. However reading the file is failing when the header is being read. So it could be that you have the following file:
https://github.com/OpenChemistry/VisItBridge/blob/df098f4148a96d62c388861c1d476039e02224ae/databases/readers/Nek5000/avtNek5000FileFormat.C#L82-L102
To confirm the kind of file, you can do something like this:
$ head -n1 Sources/foss/pymech/tests/data/nek/cbox0_issue_56.fld | strings
#std 8 10 10 1 1024 1024 0.5600001123842E+03 2101394 0 1 XUPT 0.0000000E+00 F
Once the kind of file is determined, I encourage you to look at VisitBridge and create a Python function equivalent to readnek for this specific format. PRs welcome.