search

nasa / cape

Computational Aerosciences Productivity & Execution
Other
21 stars 9 forks source link

Reporting a bug within cape.plt.Plt() #21

Closed akuraan closed 1 year ago

akuraan commented 1 year ago

There appears to be an issue within cape.plt.Plt() when using read/write ".dat" files from CART3D ".plt" files.

As an example, I've selected a test case using a tutorial ".plt" file from CART3D. A python script reproducing this error is attached, along with the sample ".plt" file.

The pseudo code is as follows: Starting with a ".plt" -> convert to a Plt class using plt_cls = Plt(fname) -> generate a .dat from the class plt_cls.WriteDat(dat) The issue arises when trying to generate a new Plt class instance from the newly generated .dat file i.e., plt_dat = Plt(dat=dat)

Given the use of only Plt() utilities, expected to be able to go back and forth between ".plt" and ".dat". This issue seems isolated to CART3D files. cape_plt_bug.zip

nasa-ddalle commented 1 year ago

Thanks for attaching the sample file! Didn't quite realize you could do that in a GitHub issue. I'm not surprised to see an issue on the Cart3D side, which we haven't been exercising as much lately.

This looks like a quick fix, which is just caused by some confusion on my part about different ways you can describe a "triangle" in these Tecplot files. Apparently sometimes you repeat the last node index (like a degenerate quad) and sometimes you just put three nodes.

nasa-ddalle commented 1 year ago

Alright, so https://github.com/nasa/cape/commit/9b4a2aef185666b109fd4007106e9ea636c837f7 resolves this issue in that the attached script runs well. There were some other issues, most importantly that Tecplot would not actually open the .dat file generated by the script, which were related to some changes to the ASCII headers. The default .dat files written by cape.plt will look quite a bit different now, which I don't think will cause any issues. You can recover the previous format using

plt_instance.WriteDat(..., feblock=True)

This option basically transposes the data, writing out all the x coordinates, then all the y coordinates, etc. through all the "variables". The default has now switched to datapacking=point (instead of datapacking=block, which in turn is the newer syntax for what used to be f=feblock), which writes out all the variables for a given point on each row of the .dat file. This is generally more human-readable, but I made it the default b/c it's also much faster for I/O with the current code.