Folder already exists

[vikashg]

Hi,
I am getting this error

It is originating from my segmentation operator which I wrote following livertumor_seg_operator

I am not able to figure why ?
@MMelQin Thoughts. Let me know if you need more code to answer this.

Thanks
Vikash

[MMelQin]

Hi, I am getting this error It is originating from my segmentation operator which I wrote following livertumor_seg_operator

I am not able to figure why ? @MMelQin Thoughts. Let me know if you need more code to answer this.

Thanks Vikash

Hi @vikashg, the code shows that it is using the v0.5 of App SDK. The specific section of the code is similar to the one in the Liver Tumor app, The exception says the output folder, save_images_folder, already exists, but from the code snippet, I cannot tell how that could be the case. An operator instance is identified by a GUID, and this GUID is used as the folder name for the on disk storage of the operator instance.

I will try to reproduce the issue with the liver example, from the code in the main branch, or from the Docker image

[vikashg]

Thanks Ming.
I just cloned the repo and switched to your branch mqin/sdk_migration. Here is the gist
https://gist.github.com/vikashg/53733780de8d2a7afa90c5aadb506792
I will look at it again today. See what's going on

[MMelQin]

If using the mqin/sdk_migration branch, then the operator and app will need to be using the WIP new App SDK.

In any case, a bit about this specific output, @md.output("saved_images_folder", DataPath, IOType.DISK), and see if it is needed in the app you are building

• With the ClaraViz integration operator directly consuming the in_memory image objects from the inference operator etc, there is no need for this particular output. Before that, I had to use directly user ClaraViz's API, which expects both the volume image files of the density and segmentation, along with a metadata. So, the save_image_folder was needed to save the image files within the inference operator, and this data path is then passed to the Publishing operator to package them into the data input for ClaraViz.
• In the new WIP App SDK, using DISK as an operator's named output is NOT supported at all (dur to Holoscan yet to support this use case). So, the output folder has to be set in an operator's constructor, or the path values can be passed to an operator in its named input as str type. Similar, the convey the info to the downstream operators, the path value can be emitted in a named output as str type. There are examples in the branch for SDK_migration.

Thanks.

[mpsampat]

@vikashg , @MMelQin we had this same error with 0.5.1 about ~2 months ago.
I will try and reproduce it and post back here.

[MMelQin]

The error was actually thrown by the IO context itself, not from the OS/FS. It is limitation, as designed, that during the operator output setup, the IO context will disallow the output be DISK type if the operator being created is an interior operator; only leaf operator in a DAG can have DISK output.

When files/folders need to be created by an interior operator, for saving intermediate results to disk, AND need to pass the path(s) to the downstream operator, the folder/file paths need to be created under the Application output folder, so that all operators can locate the parent folder via the app context. The paths then need to be wrapped in an object, which is then used to set the operator output of the IM_MEMORY type. The downstream operator/consumer then needs to the corresponding input of the in_memory object type, as well as the logic to parse it.

In MD App SDK, there is completely no support for DISK in input, output, or app execution context. I had to come up with the recipe/design to pass the folder on the initializers and still need to resort to the in memory object in the operator output to pass the paths to consuming operators.