cape.plt.Plt() bugs. StrandID and Zone Name handling discrepancies.

[akuraan]

Discovered a few bugs when using cape.plt.Plt() 's Read() and ReadDat() functions.

1. Zone Name parsing does not handle Multi-Core zone name outputs:

   • i.e. A Multi-Core FUN3D output produces zone names with the following formatting:
     • ["Boundary"_0, "Boundary"_1, "Boundary"_2, ...] where each zone is attributed to some core
     • The resulting parsed zone names from cape are as follows: ["Boundary", "Boundary", "Boundary", ... ]
   • Duplicate zone names cause significant disparities downstream when trying to define new class instances
   • Suspect this is a result of how the zone names are parsed in plt.Plt.Read() Line 260
     • zone = capeio.read_lb4_s(f).strip('"')

2. StrandID are defined differently between reading from .dat files and .plt.

   • When reading from .plts (Plt.Read()) the StrandIDs are parsed in lines 266-268
     • i, = np.fromfile(f, count=1, dtype='i4')
   • When writing .dats (Plt.WriteDat() ), StrandIDs are auto generated in lines 775-780
     • Hence, when using Plt.ReadDat(), the StrandIDs from the .dat do not match those from the .plt
   • This results in discrepancy between plt classes read in from .dat and .plt files as the StrandIDs differ.

3. Another, minor bug when reading zone names in Plt.ReadDat() lines 632-640

   • Current implementation assumes there is always only one "=" within the string; however, this breaks when zones are named with = signs (i.e. boundary 0 (X=0))
   • Suggested Fix: change k, v = s.split("=") to k, v = s.split("=", maxsplit = 1)
   • This ensures only two outputs from the split method, and it ensures the full zone name is parsed out.

[nasa-ddalle]

Implemented recommended fix for part 3. Part 1 looks to be addressed as well. Those some weird zone names!

Looking into part 2. Tecplot itself has some "auto-assign" kind of flag for StrandIDs, so I don't want to end up with unreadable files in either format.

[nasa-ddalle]

Indeed, you can't write strandid=-1 in a .dat file (b/c tec360 will refuse to open it). So now if you read a .plt file and have a StrandID of -1, Plt.WriteDat() will skip it. Similarly, Plt.ReadDat() will use a default value of -1 instead of creating a counter like you mentioned in part 2. This should address the remaining portion of your issue. However, there does not appear to be a way to differentiate StrandID values of 0 and -1 in the .dat files. That's out of my control, though.

[akuraan]

Thank you again for the promptness.

After some deeper digging, have discovered that Multi-Core FUN3D outputs are even more awkward. The 'base' zone names are stored as strings while the appended indices are stored in binary.

Your fix for Issue 1 is surely more robust, but unfortunately does not factor this in. I don't think know if the added value is worth considering this any further, but I leave this up to you.

Thanks for the clarification wrt Issue 3.

[nasa-ddalle]

That sounds pretty weird.... The zone names are already written in a weird format. Calling them "strings" is generous b/c Tecplot expects 4 bytes per character. In other words, there are a lot of zeros in there. I'm curious if these _1, _2 suffixes are coming from a different part of the file? Or is FUN3D just writing them in a weird way? It sound apparent from your knowledge that tec360 can open these files though, so maybe there's something I can do.

Obviously I've never paid attention to these multi-core files before.

[akuraan]

I have not experimented with tec360, but have been able to open these files in paraview.

[nasa-ddalle]

Which FUN3D namelist flags are you using to write such files? It sounds like you are getting the boundary in multiple cores, which surprises me. For the cutting planes I think I have always been getting a behavior like this but was happy to pretend it was all in one zone.

[akuraan]

The boundary names were parsed from cutting planes, so exactly what you've described.

[nasa-ddalle]

I think this issue should probably be closed unless you have some more specific problems. It now is pretty reliable on writing and rereading a FUN3D cut plane file going back and forth between .dat and .plt w/o changes, and I think the odd zone names you were seeing were specifically a Paraview property. Those indices on repeated zone names do not actually appear anywhere in the files on disk.