Using GetElementValues to get BFE values Bug?

1990chs
1990chs Member Posts: 45
10 Comments First Anniversary Name Dropper
**
edited January 22 in General Language Questions

Now I am using GetElementValues to get the elements temperatures values, but the result seems something wrong.
The element type is SOLID187 which has 10 nodes (4 cornor nodes)
The codes:

analysis = Model.Analyses[0]    
reader = analysis.GetResultsData()
BFEResults = reader.GetResult('BFE')
len(BFEResults.GetElementValues([1], True))
#>16
len(BFEResults.GetElementValues([1], False))
#>10
len(BFEResults.GetElementValues(1))
#>10
#-------------------------------------
#Try Stress
Stress=reader.GetResult('S')
Stress.SelectComponents(['X'])
len(Stress.GetElementValues([1],True))
#>10
len(Stress.GetElementValues([1],False))
#>4

As we can see, using GetElementValues to get elements IDs with or without midnode, the result count seems not right, but for stress, it is right.
I don't konw why BFEResults.GetElementValues([1], True) get 16 results, the SOLID187 has 10 maximum number.

Answers

  • 1990chs
    1990chs Member Posts: 45
    10 Comments First Anniversary Name Dropper
    **
    edited January 21

    It seems BFEResults.GetElementValues([1487],False) results are the same with BFEResults.GetElementValues(1487)
    So I am not sure why BFEResults.GetElementValues([1487],True) get 16 results.

  • Mike.Thompson
    Mike.Thompson Member, Employee Posts: 361
    25 Answers 100 Comments Second Anniversary 25 Likes
    ✭✭✭✭

    BFE results should be elemental and have a single value per component. It should not depend on number of nodes like stress which is element-nodal result.
    Check the component names of the BFE result

  • 1990chs
    1990chs Member Posts: 45
    10 Comments First Anniversary Name Dropper
    **
    edited January 22

    @Mike.Thompson said:
    BFE results should be elemental and have a single value per component. It should not depend on number of nodes like stress which is element-nodal result.
    Check the component names of the BFE result

    @Mike.Thompson
    According to the workbench solving file.dat file, the BFE is applied on the element node, and also it is the element result which should be the same with stress. And also the BFE only have one "BFE" component.
    The important thing is that two override function results are not the same.
    BFEResults.GetElementValues(1) this function get all the element nodes results which are familiar with stress.
    But BFEResults.GetElementValues([1], True) function also get all the element nodes results and the results numbers are not the same with previous override function which are very strange.
    The BFE applied in solving file:

    The BFE result type and Stress result type and their components:

    BFE components:

    BFEResults.Components
    #>>>['BFE']
    
  • ChrisC
    ChrisC Member Posts: 11
    First Anniversary First Comment
    **

    The ACT reader has always been a point of frustration for me. This is one of numerous bugs I've run into.

    I've copied an example block of code below as to how I've managed this. Create/add an mid-side node bool to the element lookup dictionary used to nodal averaging that is referenced when. Also, worth noting which version you're working in? Looking through the comments in my code, I had left a note saying the issue was fixed in 2022.2, but I left the code in to maintain computability with previous version. (I don't recall every verifying this thou)

    temp = reader.GetResult("BFE")
    
    # Define element cornder node index information
    # This is required for degenerate element handling, as Mechanical doesn't natively track degenerate element index info passed to the solver.
    nodeSolverIndexDict = {}
    #kHex20
    nodeSolverIndexDict.Add(ElementTypeEnum.kHex20,{0:0, 1:1, 2:2, 3:3, 4:4, 5:5, 6:6, 7:7, 'MidsideNodes':True})
    #kHex8
    nodeSolverIndexDict.Add(ElementTypeEnum.kHex8,{0:0, 1:1, 2:2, 3:3, 4:4, 5:5, 6:6, 7:7, 'MidsideNodes':False}) 
    #kPyramid13
    nodeSolverIndexDict.Add(ElementTypeEnum.kPyramid13,{0:0, 1:1, 2:2, 3:3, 4:4, 'MidsideNodes':True})
    #kQuad4
    nodeSolverIndexDict.Add(ElementTypeEnum.kQuad4,{ 0:0, 1:1, 2:2, 3:3, 'MidsideNodes':False})
    #kQuad8
    nodeSolverIndexDict.Add(ElementTypeEnum.kQuad8,{0:0, 1:1, 2:2, 3:3, 'MidsideNodes':True})
    #kTet10
    nodeSolverIndexDict.Add(ElementTypeEnum.kTet10,{0:0, 1:1, 2:2, 3:3, 'MidsideNodes':True})
    #kWedge15
    nodeSolverIndexDict.Add(ElementTypeEnum.kWedge15,{0:0, 1:1, 2:2, 3:4, 4:5, 5:6, 'MidsideNodes':True})
    #kTri6
    nodeSolverIndexDict.Add(ElementTypeEnum.kTri6,{0:0, 1:1, 2:2, 'MidsideNodes':True})
    #kWedge6
    nodeSolverIndexDict.Add(ElementTypeEnum.kWedge6,{0:0, 1:1, 2:2, 3:4, 4:5, 5:6, 'MidsideNodes':False})
    #kTri3
    nodeSolverIndexDict.Add(ElementTypeEnum.kTri3,{0:0, 1:1, 2:2, 'MidsideNodes':False})
    
    # Create Midside Boolean list to pass to reader.  Note this is required because as of 2021R2 the reader is buggy and the midside Boolean must match what is stored in the RST file or it will return incorrect results.  
    ElementMidsideBool = []
    for eid in elist:
        elemType = mesh.ElementById(eid).Type
        ElementMidsideBool.append(nodeSolverIndexDict[elemType]['MidsideNodes']) 
    
    # Retrieve element results from the RST file and store in the *resultarray lists for later processing.
    # Note that midside boolean is updated per element id and type for temp result array.  As of 2021R2, the reader does not return correct values unless it matches the element type midside nodes.  
    # Supposedly this is fixed as of 2022R2 and could possible be removed in the future, when support for 2021R2 is not longer required.   
    tresultarray = [temp.GetElementValues([eid],MidsideBool) for eid, MidsideBool in zip(elist, ElementMidsideBool)]
    
  • 1990chs
    1990chs Member Posts: 45
    10 Comments First Anniversary Name Dropper
    **

    @ChrisC Most time I use 2019R3 version, but I have check it in 2023 R1, the bug seems don't fix.
    In 2023 R1 version, if the element type is kHex20, then len(BFEResults.GetElementValues([1], True)) is 32 which kHex20 has 20 node number.
    Also, I have try to use your posted codes, but it seems the results are not right, I don't konw why.
    Another overwrite API BFEResults.GetElementValues(1) can get the right results, but if the result file size is big and element number is big, the calculating speed within loop is very slow. That is why I try to use BFEResults.GetElementValues(eIdlist, bool) to get the element BFE values.
    I have tried to search the BFEResults.GetElementValues([1], True) results. It seems the midnodes values are average again using cornor nodes, but actually for element the midnodes temperatures values have been assigned from thermal nodes results which are different with stress (the midnodes stress have no values and calculated by cornor nodes values). That is my guess.
    The attachment file is my guess calculating process.

  • 1990chs
    1990chs Member Posts: 45
    10 Comments First Anniversary Name Dropper
    **

    Cam any Ansys employee confirm this Bug ?

  • Mike.Thompson
    Mike.Thompson Member, Employee Posts: 361
    25 Answers 100 Comments Second Anniversary 25 Likes
    ✭✭✭✭

    If you feel this is a defect, please submit a service ticket to your local ANSYS support team. This is all supported functionality and should be applicable to technical support.