Temperature read from rst file seems to differ from nodal values

[JackGuyver]

Hi everybody,

a colleague of mine recently set up a simulation test case where we plan to combine mechanical and thermal loads (basically forces and heatfluxes). To do so, SURF154 and SURF152 elements for the respective loads, as well as SOLID226 and SOLID227 elements for the volumes in the mesh are being created.

In principal this works as expected and when processed in the Ansys Workbench or Tecplot, the results look good. However, we did observe a deviation from the other methods when reading the nodal temperature data using pyansys.pymapdl.reader.

The image I attached shows the difference between the nodal temperature read from the rst file using Tecplot and the pyansys reader. To read the temperatures I used the following minimum example script (with the latest version 0.51.3 of the reader):

#!/usr/bin/env python                                                           
from ansys.mapdl import reader                                                  
                                                                                
rstData = reader.read_binary('structure.rst')                                   
                                                                                
resultIndex = rstData.nsets - 1                                                 
nodeIDs, nodalData = rstData.nodal_temperature(resultIndex)                     
                                                                                
for i in range(nodeIDs.shape[0]):                                               
    print(nodeIDs[i], nodalData[i])

A heat flux boundary condition is applied to the side of the cube facing us (X=Xmin). The top side (Z=Zmax) is prepared to be loaded with a force (which is zero by now).

Although the deviations are relatively small (max. is 0.89K), I wonder what causes them. From what I understand, the nodal temperature should be a state variable that is, once defined by solving the system, not depending on the connectivity or element type of the elements the node is belonging to (other than e.g. a nodal value for the heatflux). Thus, the nodal temperature should be the same when read by any of the tools at hand (Workbench, Tecplot, pyansys), right?

Do you have any idea what the cause of this deviation could be? I assume that it is not connected to the FEM model, but mainly due to how the reader parses the data. I would be very thankful for any hint or explanation.

For now I only attached the results file structure.rst.zip, but as you have probably already guessed, the shown case is a minimum working example and I could easily provide any data (e.g. input file, workbench project), if that helps somehow.

Best regards,
Sebastian

[akaszynski]

Thus, the nodal temperature should be the same when read by any of the tools at hand (Workbench, Tecplot, pyansys), right?

Quite right. It's a primary result and not a derived result like element stresses (computed at integration points, extrapolated/interpolated to nodes, averaged, etc).

Looking into this now, thanks for the thorough explanation!

[akaszynski]

I'm seeing the same issue on my end:

"""Compare temperaturs from ansys-mapdl-reader with mapdl"""

import os
import shutil

import numpy as np

from ansys.mapdl import reader as pymapdl_reader
from ansys.mapdl import core as pymapdl


path = 'structure.rst'
rst = pymapdl_reader.read_binary(path)

# rst.plot()

nnum, temp_from_rst = rst.nodal_temperature(0)


mapdl = pymapdl.launch_mapdl()

shutil.copy(path, os.path.join(mapdl.directory, 'file.rst'))

mapdl.post1()
mapdl.set(1, 1)
temp_from_mapdl = mapdl.post_processing.nodal_temperature
# Identical to: print(mapdl.prnsol('TEMP'))

diff =  temp_from_mapdl - temp_from_rst
nnum = mapdl.mesh.nnum
for node_diff, node_num in zip(diff, nnum):
    print(f'Node {node_num:3}    {node_diff:9.5f}')

Returns:

Node   1      0.00000
Node   2     -0.00000
Node   3     -0.00000
Node   4      0.00000
Node   5      0.00000
Node   6     -0.00000
Node   7      0.00000
Node   8     -0.00000
Node   9      0.89025
Node  10      0.88855
Node  11      0.89025
Node  12      0.16225
Node  13      0.05435
Node  14      0.05270
Node  15      0.16369
Node  16      0.16369
Node  17      0.05270
Node  18      0.00000
Node  19      0.00000
Node  20     -0.00000
Node  21     -0.00000
Node  22      0.00000
Node  23      0.00000
Node  24     -0.00000
Node  25     -0.00000
Node  26      0.00000
Node  27      0.00000

---

In regards to this being a primary result, I noticed that MAPDL is returning mid-side values, indicating that it's computed temperatures as a primary result. However, the file extension is a rst file and I'm seeing the primary results are displacement values from the result file. Turns out that the ansys-mapdl-reader is computing the results from the element solution table EPT as derived results, and this is probably leading to the discrepancy between the solutions.

Let me dig a little more and see if the temperatures are stored in a different record.

[akaszynski]

Let me dig a little more and see if the temperatures are stored in a different record.

Actually, I think what's going on is ansys-mapdl-reader and MAPDL are either including/excluding the solution from the 154/152 elements.

Working on a bug-fix for this.

[JackGuyver]

Thank you very much for your fast reply and your explanation.

I already wondered if the root of this deviation has anything to do with our simulation setup. I'm well aware that we do bend the intended usage quite a bit by using the SURF152 elements together with thermal boundary conditions within a deformation simulation writing a rst file.
However, this works quite well for our use cases and enables us to use force- and heatflux-boundary conditions simultaneously.

[akaszynski]

Got a fix, turns out I just ignore 154 elements. Patch coming...

[akaszynski]

Resolved in #61 and released in ansys-mapdl-reader==0.51.4.

Please let me know if this solves your issue.

[JackGuyver]

After updating to 0.51.4 the temperatures now indeed are what I would expect for my original test case.

Thank you very much for the very fast and detailed reply and the version update.
The speed and quality of your support is really impressive.

Resolved > Closed.
Best regards from Germany,
Sebastian