It would be helpful if we have a way to create loops for adding a field in vtu_export operator

[vishnuramn]

Description of the feature

At the moment I am doing the below to add multiple fileds

vtu_operator = dpf.operators.serialization.vtu_export(directory=vtu_directory,mesh=my_mesh,base_name=vtu_file_name)
for count,result_field in enumerate(result_fields):
    vtu_operator.connect(count+3, result_fields[count])

its not very elegant at the moment. a more pythonic way could help

Steps for implementing the feature

No response

Useful links and references

https://dpf.docs.pyansys.com/version/0.12/operator_reference_load.html

[ayush-kumar-423]

The Pythonic way can't make use of loops here as the fields are fields1, fields2.... Can we allow passing an Array of fields as a single argument? @rafacanton

[rafacanton]

@ayush-kumar-423 @vishnuramn Hi, this is the approach we followed to expose what we internally call "ellipsis" pins. They are found in several operators, when we don't know the number of inputs of a certain type (because it can be set by the user), and the pins go from the starting one (3 in this case) until you don't connect any more.

The problem is that in Python we generate automatic code that has the pin names in there (see in this case here). That way you can have nice linting (because the code exists). This would mean that for ellipsis pins we would need to create an infinite number of inputs, and that cannot be handled. Hence the intermediate approach we followed: create 2 of them and then when you really need to connect a lot, make a loop as you did.

Accepting a list in the first input goes against the design of the ellipsis, as you are not using n pins, but one with n values. What do you think, @PProfizi?

[ayush-kumar-423]

Thanks @rafacanton for the the explanation. How about keeping things intact on the Server side and let PyDPF loop over the list of fields internally? The issue here is actually not the loop but the inconsistency of syntax; which is confusing. With the advent of SimAI we can expect a surge in the usage of this operator. Many might report this as a bug as they won't think of trying the C++ syntax route or might not even know that is possible.