Limitations of rendering from simplnx and potential simplnx contributions.

[jess-garnett]

I had some questions about the limitations of simplnx:

• Is it possible to configure the Render Properties tree from simplnx? i.e. Read Image and then set the ImageGeom to render as having Outline View and 2D Image Slice/View. Specifically so when the resulting .dream3d is opened all of the render properties are already configured.
  • Also for applying things like the Thresholder Filter.
  • Would all of this fall into d3dstate integration into the python api?
• Is it possible to see any representation of the current data structure/visualization from simplnx? i.e. Generate image of top view for current data structure. Based on NXWorkshop/blob/develop/PythonTutorial/tutorial_0.ipynb and not finding anything in the simplnx docs I am assuming the answer is no.

I also had 2 other potential contributions that I wasn't sure where they could/should go:

Pixi install

I installed simplnx using pixi removing the dependency on conda/mamba and making the install compatible with uv/pyproject.toml project configurations. I'm not sure which tutorials/install info pages this would be best added to but I think it would be nice as an extra install option. The commands in an existing project are:

pixi project channel add bluequartzsoftware
pixi add dream3dnx

Or to create a new project:

pixi init --channel bluequartzsoftware
pixi add dream3dnx

Filter Result Logging

I was going through the Python Tutorials and I the thought that the check_pipeline_result function seemed more suited for past .py usage and less so for interactive .ipynb usage so I put together this log_pipeline_result function which acts as a drop-in substitute based on logging rather than printing. I thought it could be included in a tutorial or otherwise available in the examples but wasn't sure exactly where to put it.

import logging
# logging.getLogger().setLevel(logging.INFO) # Optional - set logger level to show info logs
def log_filter_result(result:nx.IFilter.ExecuteResult,filter:nx.IFilter|None=None,):
    """
    This function will log any warnings or errors from the `result`.
    It logs warnings and errors at their respective log levels.
    It logs a succesful result with no warnings or errors at the `info` level.
    If uncommented it throws a `RuntimeError` if any errors are present.
    Either modify this function or handle the error in a `try:` `except:` statement.
    """
    if filter is None:
        filter_name="Filter"
    else:
        filter_name=filter.name()
    
    # logging.info(msg=f" {filter_name} : {result}") # Optional - info log the full result
    for warning in result.warnings:
        logging.warning(msg=f" {filter_name} : {warning.code} {warning.code}")
    for error in result.errors:
        logging.error(msg=f" {filter_name} : {error}")
    # if result.errors: # Optional - raise a RuntimeError if any errors are present
    #     raise RuntimeError(result)
    if not result.warnings and not result.errors:
        logging.info(msg=f" {filter_name} : No Warnings or Errors")

[imikejackson]

The logging example is nice. We will see where best to place this into the examples.

For pixie, we are not familiar with pixie and who all is using that package manager. Our primary clients are all running conda-forge or anaconda based on their enterprise needs.
There are some very subtle issues when building the conda versions of DREAM3DNX with respect to specific library versions of dependent librarys. We have spent considerable time testing our conda environments to ensure that they are compatible with a wide range of data analysis conda libraries. Validating another package manager may not be on our time table for a bit. The concept is interesting though.

[jess-garnett]

That makes a lot of sense. Pixi does use conda-forge as its primary source(with uv for PyPi-based packages) so it would hopefully have minimal breakage of library dependencies.