Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

combine gives error if file name is to long #20

Open
DavidAnderegg opened this issue Oct 29, 2020 · 2 comments
Open

combine gives error if file name is to long #20

DavidAnderegg opened this issue Oct 29, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@DavidAnderegg
Copy link

Description

cgns_utils combine fails if the file name is to long. It only happens, when the name is longer than 31 chars. So I assume it has something to do with a length cap on a datatype.

Steps to reproduce issue

  1. rename a CGNS File to a_reaaaaaaaaaaly_long_name1.cgns
  2. rename a second CGNS File to a_reaaaaaaaaaaly_long_name2.cgns
  3. run cgns_utils combine a_reaaaaaaaaaaly_long_name1.cgns a_reaaaaaaaaaaly_long_name2.cgns test.cgns

Current behavior

This error gets thrown: Duplicate child name found: a_reaaaaaaaaaaly_long_name1.0000

Expected behavior

It should work regardless of the file name length.

@eirikurj
Copy link
Contributor

You are correct. However, this is more a limitation of the CGNS library itself, where strings are limited to 32 characters, rather than an issue with cgns_utils.
The primary issue stems from the fact that zones in the combined file use the filenames from each of the input files as the zone basename.
So at the moment you are limited to how long the filenames can be. We could catch these very long names and throw an error.
In order to support very long input filenames this behavior needs to change.
A possible solution is not to use the filename but rather use some generic naming scheme for the zones in the combined file that is independent of the input filenames, e.g., file1.00001 and file2.00001 corresponding to the first zone for files file1.cgns, file2.cgns, respectively.
While this is fine in many cases, some may prefer the explicit connection to the input files.

@DavidAnderegg
Copy link
Author

Thank you for the explanation. But at least an error message would be nice. It took me quite some time to figure out, that the file name is the problem.

I would suggest going a middle way. Use the filename. If it is to long, cap it and append a number.

@ewu63 ewu63 added the bug Something isn't working label Apr 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants