Cannot update python result plot with custom values on node IDs on a path.

Kev

Hi guys

Will try to make this as elaborative as possible. I am doing a custom weld throat thickness calculator ACT.

The premise:

I have a model containing only shells representing welded sheets/plates. I have shared typologies where the shells terminate with each other representing welds. Construction geometries in the form of Paths are defined on the welds (Weld paths). I also have named selections identifying the bodies that will provide the element orientations for the plots but that comes later.

I have developed a script that creates User plots for all the stress tensor values that will later be used to calculate the Weld throat size.

What I would like to do is to have a Python result plot that will only show the calculated throat size values on the given NodeIDs.

Issues:

I have this Python result code that shows all the node numbers as values on each node (Thanks to @Pernelle Marone-Hitz ):

https://discuss.ansys.com/discussion/1767/create-a-python-result-to-plot-the-node-id

This code run on my model gives the following result (notice how the node ID values start from 28!):

I know for a fact that the node IDs that correspond to my Path 1 , are the missing node ID values which are [1,2,....27].

I have modified the code to place given values on certain node IDs by overriding the nIds and data values :

nIds = [107, 807, 533, 108,1] &  data = map(float , [10 , 20, 30, 50,100])

I can see that the node ID of 1 is not coming though as the value of 100 is not on the scale. this can be seen in the screenshot below.

It is worth mentioning that I have tried initializing the nIds and data values using the stress results but to no difference.

Does anyone have any Ideas why I cannot get access to nodes on the path.

Is there a better way of doing this that I have not yet come across?

I am attaching my project file in case it could help.

Weld calculation Weaver method Automation_Archive.zip

As always many thanks for all the help and the excellent work :)

Pernelle Marone-Hitz

Hi @Kev , it might be that you're using a version that's too old and/or that you will likely have to solve the model again. In my case I'm using 23R1. I'm using the code below:

def post_started(sender, analysis):# Do not edit this line
    define_dpf_workflow(analysis)
 
 
def define_dpf_workflow(analysis):
 
    import mech_dpf
    import Ans.DataProcessing as dpf
    mech_dpf.setExtAPI(ExtAPI)
    dataSource = dpf.DataSources(analysis.ResultFileName)
    
    # Read mesh in results file
    mesh_op = dpf.operators.mesh.mesh_provider() # operator instanciation
    mesh_op.inputs.data_sources.Connect(dataSource)
    mesh = mesh_op.outputs.mesh.GetData()
    
    # retrieve displacement
    uZ = dpf.operators.result.displacement_Z()
    uZ.inputs.data_sources.Connect(dataSource)
    nIds = uZ.outputs.fields_container.GetData()[0].ScopingIds
    data = uZ.outputs.fields_container.GetData()[0].Data
    
    # create new field and assign values
    my_field = dpf.FieldsFactory.CreateScalarField(numEntities=0, location='Nodal')
    my_field.MeshedRegionSupport = mesh
    my_field.eShellLayers = dpf.enums.shellLayers.LayerIndependent
    
    for i in nIds:
        my_field.Add(i,[float(i)])
    my_field.ScopingIds = nIds
    #my_field.Data = [0.05 for i in range(0,len(data))]
    
    # forward field to an operator to plot it
    forward = dpf.operators.utility.forward_field()
    forward.inputs.field.Connect(my_field)
 
    dpf_workflow = dpf.Workflow()
    dpf_workflow.Add(forward)
    dpf_workflow.SetOutputContour(forward,dpf.enums.GFXContourType.FENodalScoping)
    dpf_workflow.Record('wf_id', False)
    this.WorkflowId = dpf_workflow.GetRecordedId()

Pernelle Marone-Hitz

Hi @Kev , there seems to be an issue related to topology sharing.

With no topology shared between the edges, this is what I get:

And when I share the topology, I get the same behavior as you do:

This seems to only occur for shell bodies, if I use solid bodies and share the topology I don't get this issue:

I'll have to take this to our development team, I will keep you posted.

Kev

Thanks @Pernelle Marone-Hitz . Hopefully this didn't put you through too much trouble.

It is a shame that this approach has that shortcoming. Alternatively, I was hoping to use the node coordinates approach as the scoping method but could not work it out yet. Would you know if going down that road will also lead to the same issue, when using shared typologies? Unfortunately sharing topology in our case is unavoidable as it drives a couple of other actions.

I also asked if there is a better way of doing this. I have the node IDs (and node Coordinates) and the value of interest I need shown on those locations. Is there another way to go about plotting this nodes vs values? Maybe updating existing user plots with the modified values for just the weld path?

Pernelle Marone-Hitz

Hi @Kev I'm pretty sure that this is a display /plotting issue, so I don't think that the way the node Ids are retrieved will matter. The way data should be provided in a Python Result is to use nodal, elemental, or nodal-elemental (nodes per element) information, so you would have to use the ids of the nodes or elements, but it will not be possible to use their coordinates.

One thing that you can try is to play with the dpf.enums.GFXContourType option. See more info here: https://ansyshelp.ansys.com/account/secured?returnurl=/Views/Secured/corp/v231/en/wb_sim/ds_python_result_examples_total_def_pro_provider2.html

You can also have a look at the "node based scoping " section of this page: https://ansysproducthelpqa.win.ansys.com/account/secured?returnurl=/Views/Secured/corp/v231/en/wb_sim/ds_scoping_results.html

In summary:

- If all nodes of an element face are scoped, then Mechanical will draw contour bands on the entire face, and draw the scoped nodes in contour colors.

- If some nodes of an element face are not scoped, then Mechanical will draw the face as transparent and draw the scoped nodes in contour colors.

- If all nodes of the geometry are scoped, then Mechanical will draw contour bands on the entire geometry.

But right now we have all the nodes scoped and still some missing contour bands, hence me thinking this is a plotting issue. I'll keep you posted as soon as I hear back from the dev team.

Kev

Hi @Pernelle Marone-Hitz. Was wondering if the developers got back to you regarding this. If there are no ways to get this method to create the results on the desired path then I guess it is back to the drawing board for me.

Would greatly appreciate an update on this or alternatively a hint at a work around as I seem to be stuck at the moment.

Cheers Pernelle and thanks again for all the help

Pernelle Marone-Hitz

Hi @Kev , the development team is looking into this but it might take some time, and at best there will be a fix for the next release. One workaround would be to not use shared topology and connect the bodies through contact instead. As suggested in my previous message you can also investigate whether dpf.enums.GFXContourType option has an influence on the plot. The last workaround I see is to use solid bodies instead of shell bodies as the issue does not appear in that case. I'm aware these suggestions are suboptimal but I'm afraid I don't have other ideas.

Kev

Thanks @Pernelle Marone-Hitz . That is a shame that there are no quick fixes for this. I did have a play with the dpf.enums.GFXContourType options but no luck. I see if I can push the idea of getting away from using shared topology.

Thanks for all the help Pernelle really appreciate all the efforts :)

Pernelle Marone-Hitz

Hi @Kev , I have some good news! My colleague from development looked into this and it turns out this is not a bug and is the expected behavior: The plotting issue here is due to an inconsistency between the eShelllayer enum and the geometry. Indeed adding:

my_field.eShellLayers = dpf.enums.shellLayers.LayerIndependent

does the trick. (looking at the shell layer of uZ.outputs.fields_container.GetData()[0] gives LayerIndependent).

To know how to display (and in particular how to split a Field between bodies some may be shell and other solid) we need to know the types of shell layers. NoneLayer is for unlayered geometry, LayerIndependent means that there is a single value for all shell layers.

After adding the line above, this is how the script looks like:

Kev

Wow Thanks so much @Pernelle Marone-Hitz !!! Sorry I don't get email notifications for theses messages for some reason.

Wish i had checked this post sooner. my work around was to do a search for the closest node tho those nodes and plot the value on them 😅. the guys here really did not like that approach.

This is amazing if it works!! I'm trying it now. Will see how I go :)

Thanks again.

Kev

Hi again @Pernelle Marone-Hitz . I did have a go and have to report that it did not work. I am getting the following error:

Seems like the property is read only or at least cannot be set in that fashion. This is were I was planning to use it on a sample py result code:

the odd thing is that when I quarry the eshellLayer property on this sample code, it is already set to LayerIndependant

Even with the eShellLayer property set to LayerIndependant I'm still seeing no results displayed on the shared topology locations:

I did play with the dpf_workflow.SetOutputContour property but made no difference.

Am I missing something? Could you paste the code you have used which allows you to set the eShellLayer value?

Kev

I see! Yeah sadly we are still on 2022 R1. No worries then @Pernelle Marone-Hitz :) I think the tool is functional enough as it is. hopefully soon we'll all migrate to 2023 and then I will give the code another go :)

Thanks for all the help Prenelle.

Cheers