Closed mpenn closed 4 months ago
Hi @mpenn!
Thanks for submitting this issue - our team has been notified and we'll get back to you as soon as we can! In the mean time, feel free to add any relevant information to this issue.
UPDATE: This issue happens in the call to MessageMetaInterfaceProxy::get_data_frame which first creates a TableInfo
object from the underlying cuDF DataFrame and then creates a new cuDF DataFrame using CudfHelper::table_from_table_info
. In CudfHelper::table_from_table_info
, the column metadata which holds the struct key names are not retained after calling cudf.DataFrame._from_data
with information from our TableInfo
. We can manually create the column metadata and use cuDF's cudf._lib.io.utils.update_struct_field_names
function to add the metadata back to DataFrame. However, we run into an issue if the dataframe is sliced, specifically when a column's _offset
is not 0. We get the following exception:
File cudf_helpers.pyx:226, in morpheus._lib.cudf_helpers.update_struct_field_names()
File cudf_helpers.pyx:250, in morpheus._lib.cudf_helpers.update_column_struct_field_names()
File ~/miniconda3/envs/morpheus/lib/python3.10/site-packages/cudf/core/column/struct.py:111, in StructColumn._rename_fields(self, names)
105 def _rename_fields(self, names):
106 """
107 Return a StructColumn with the same field values as this StructColumn,
108 but with the field names equal to `names`.
109 """
110 dtype = cudf.core.dtypes.StructDtype(
--> 111 {name: col.dtype for name, col in zip(names, self.children)}
112 )
113 return StructColumn(
114 data=None,
115 size=self.size,
(...)
120 children=self.base_children,
121 )
File column.pyx:290, in cudf._lib.column.Column.children.__get__()
RuntimeError: CUDF failure at: /opt/conda/conda-bld/work/cpp/src/copying/slice.cu:44: Slice range out of bounds.
The update_struct_field_names
function in cuDF is only used in their JSON and Parquet readers immediately after reading a file into a DataFrame so apparently it was not intended to be used on sliced DataFrames.
This issue is also seen with C++ MultiMessage.get_meta
and MultiMessage.copy_ranges
because they also use TableInfo
for slicing and cudf_helpers
to create the new DataFrame.
One workaround for this is to bypass the TableInfo
and cudf_helpers
layer and slice the underlying cuDF DataFrame directly. This has been implemented for C++ MultiMessage.get_meta
in this issue's corresponding PR (#1538) and seems to be working.
The C++ MessageMeta.get_data_frame
in the PR currently uses cuDF's update_struct_field_names
so will throw the above exception if SlicedMessageMeta
is used with struct or list columns. We should also be able to slice the cuDF DataFrame directly as we did with MultiMessage.get_meta
if that approach is acceptable.
Version
24.03
Which installation method(s) does this occur on?
Docker, Conda, Source
Describe the bug.
When storing
cudf.core.dtypes.StructDtype
columns in amorpheus._lib.messages.MessageMeta
from Python, the key names are not preserved. Instead, they appear to be converted into incrementing integers that have been cast to strings. This behavior can also be observed when trying to store the same kind ofcudf.core.dtypes.StructDtype
columns in aControlMessage
payload.Here is an example of the desired output that works when using a Python
MessageMeta
(i.e.CppConfig.set_should_use_cpp(False)
). In this example, column "c0" is acudf.core.dtypes.StructDtype
column containing properly named keys.Here is the offending output when using the C++
morpheus._lib.messages.MessageMeta
alternative (i.e.CppConfig.set_should_use_cpp(True)
). In this example column "c0" is acudf.core.dtypes.StructDtype
column containing improperly named keys.Minimum reproducible example
Relevant log output
Click here to see error details
Full env printout
Click here to see environment details
Other/Misc.
In the minimum reproducible example, turn
use_cpp
toTrue
andFalse
to explore the behavior.Code of Conduct