I have an object-level batch asset processing-type HDA with a TOP network inside that contains several sop-level HDA processors

I promoted all the necessary parameters from the HDAs themselves onto the top object-level asset so the user has control over everything, but I need to link the pdg HDA processors to those parameters as well

there doesnt seem to be any parameter references created when you hit ‘update HDA parameters’ on the hda processor, even when pointing to a template sop node. So far i've only been able to manually copy/paste relative reference each parameter manually, and the assets contain multiparms so that no longer works

On a normal HDA for instance you could use the ‘Import Settings’ toggle on a folder pointing to the template HDA, refresh the imports, and your good, but since the HDA processor is dynamically generating spare parameters for everything (and not all of them come across correct, things like buttons, hide/disable when etc don't link up perfectly), whats the preferred workflow here?

If its through the Filter HDA parameters window, I cant find any documentation on it, I tried checking enable expression but it just creates an empty python expression. Is the idea that you then fill in the expressions yourself, or how is that mean to work?

Finally, I remember reading somewhere you can control parameters using work item attributes, would you create an attribute that has the same name and type as the HDA parameter and it will pick it up automatically? or do you need to fill in all the HDA parameters manually with `@my_attrib` for it to work? Which again would be problematic due to the dynamic multiparms etc

Any help is appreciated!

Hello!

HDA Processor is not actually cooking the instances of the HDAs that are within your HIP file. When an HDA Processor job cooks, it runs Hython in a new process. The HDA Processor job will instantiate the HDA within that Hython session, set the parameters, cook the HDA, and then report the outputs. Therefore, if you want to expose the HDA Parameters on the interface of your top-level OBJ HDA, I would directly promote the HDA Parameters from the HDA Processor onto the top level HDA interface.

I will file a bug for the hide/disable not working. This is happening because the HDA Parameters are prefixed to avoid name clashes and the hide/disable expressions are not updated to account for this.

Buttons on your HDA's interface should be working correctly. They will appear as Toggle parameters within the “HDA Parameters” folder. When the toggle is enabled, it means that HDA Processor will “press” the button when it cooks.

You are correct – the “Enable Expressions” toggle in the “Filter HDA Parameters” window is just a quick way to enable Python expressions on parameters.

You could drive everything on the HDA Processor using attributes like you are describing. I would recommend disabling all the parameters with the “Filter HDA Parameters” window if you do this. The HDA Processor knows which attributes on the work item are HDA Parameters via 4 string attributes: hdparms_buttons, hdaparms_floats, hdaparms_ints, and hdaparms_strings. These attributes contain lists of names of the HDA Parameters. For example, if you wanted to set a float attribute on your HDA Processor called “velocity”, you would have to add a “velocity” attribute with its values, and add “velocity” to the hdaparms_floats string attribute.

I hope this helps. Let me know if you have any more questions. I can also provide some example files if you need any further clarification!

Hey Brandon, thank you for the info! That's exactly what I was looking for, and thank you for filing the RFE as well.

Examples are always welcome if you have them

Did someone manage to make It work? (the attributes override HDA parameters)

1. I disabled all the HDA´s parameters (they don´t appear in the HDA Parameters tab anymore).
2. I create a “type” int attrib with values 0 to 3.
3. I create a string attrib “hdaparams_ints” and set it to “type” - tried single string attrib and string array attrib.

Never works, It only cooks with the HDA´s default values.

It looks like something changed recently that caused this workflow to no longer work (HDA Processor was clearing the hdaparms_* attributes). I've updated the node so it will no longer clear those attributes if you have disabled all of the HDA's parameters. This fix is available in tomorrow's build!

BrandonA
It looks like something changed recently that caused this workflow to no longer work (HDA Processor was clearing the hdaparms_* attributes). I've updated the node so it will no longer clear those attributes if you have disabled all of the HDA's parameters. This fix is available in tomorrow's build!

Thanks Brandon! That was driving me nuts! I thought that I was doing something wrong!

Brandon, one more question: could we use the @hda attrib to set the hda path automatically or should we use an attribute in the hda path parameter, on the HDA Processor node?

Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it require the first method (recognizing the @hda attribute automatically)?

BrandonA
Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it require the first method (recognizing the @hda attribute automatically)?

No, I don´t have. I thing using the attribute in the parameter would be the same. Was just a question… just to know if the fix would change that behavior too.

But I´m using the hda path attribute in the parameter to process a different hda on each task. I just needed the fix to control each hda parameter with attributes.

Thanks Brandon!

BrandonA
Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it requires the first method (recognizing the @hda attribute automatically)?

Brandon, as I said, I don´t need to recognize the hda path automatically, because referencing the path attribute in the parameter works fine. But other problems arise: since I´m using one hda processor to process several hdas, some of them don´t have inputs and other have, and the node errors out for the hdas that don´t have inputs.

One possible solution would be overriding the hda processor´s parameters with attributes with the same name, but that doesn´t seem to work now.
This kind of workflow would be far more procedural than using several hda processors to account for those problems.

thanks.

Hi there! Do you have the Input File Source set to “Upstream Output Files”? This option can be used to provide a variable number of inputs.

BrandonA
Hi there! Do you have the Input File Source set to “Upstream Output Files”? This option can be used to provide a variable number of inputs.

Yes, I have. I´m using the “upstream outputs” as my geo source for the hdas. As you can see in the attached image, I have two brunches, the left one is for the hdas that have inputs and the right one is for the hdas that don´t have inputs. If merged, I´ve got errors.
But I can´t override “Create Input Files” with attributes, and that is a problem.

(1) It makes sense for you that parameter overrides (with attributes) only works if the hda processor is set to dynamic?
(2) Is the “hda service pool” working fine? In the same setup I´ve got errors with the pool, but without it works fine.
(3) The parameters created on the hda processor´s “HDA Parameters” tab don´t append the prefix to the “disable when” expression. Would it be better to have blanc expression and we have access to the parameters than (current) don´t have access at all

As a side note, the previous version of the node (without the need of “hdaparms_int” and so on) was far easier (don´t know if better) to work with. In the current state, we have to use python (AFAIK) to create the array attributes to make the overrides.

You should be able to set “Create File Inputs” to an expression. E.g. if you have an attribute called “requires_inputs” you, should be able to set the “Create File inputs” parameter to “@requires_inputs” and HDA Processor will handle the rest.

1) This is possibly because the Python Script is adding attributes during the Cook step (guessing from the screenshot). Try setting the “Evaluate Script During” parameter to “Generate” on the Python Script node if it is not already set to that.

2) The HDA Processor service should be working. Can you send the errors as well as a screenshot of your service configuration in the PDG Service menu dialog?

3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change.

Built-in nodes for making it easier to work with attribute arrays is currently on our list of planned features.

BrandonA
3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change

Any update on this? I have some hdas that already extensively use hidden and disabled parameter expressions for usability reasons.
I was going to use the hda processor on them but decided to avoid it and use another PDG workflow.

FFD

BrandonA
3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change

Any update on this? I have some hdas that already extensively use hidden and disabled parameter expressions for usability reasons.
I was going to use the hda processor on them but decided to avoid it and use another PDG workflow.

Yes, this has been fixed and recent H18 daily builds will have the fix.

BrandonA

FFD

BrandonA
3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change

Any update on this? I have some hdas that already extensively use hidden and disabled parameter expressions for usability reasons.
I was going to use the hda processor on them but decided to avoid it and use another PDG workflow.

Yes, this has been fixed and recent H18 daily builds will have the fix.

Yes, I´ve seen in the journals. Thanks Brandon!