Result Class

[iceblink-ansys]

🔍 Before submitting the issue

• I have searched among the existing issues
• I am using a Python virtual environment

🐞 Description of the bug

For some reason the results from PyMAPDL-reader are not the same as from mapdl in batch mode, though the stress order of magnitude is somewhat similar.

---

PyMAPDL-Reader Software and Environment Report

Date: Tue Dec 20 16:54:15 2022 CET

            OS : Linux
        CPU(s) : 24
       Machine : x86_64
  Architecture : 64bit
           RAM : 1511.6 GiB
   Environment : Python
   File system : xfs
   GPU Details : error

Python 3.7.13 (default, Apr 28 2022, 08:00:21) [GCC 8.2.0]

       pyvista : 0.37.0
           vtk : 9.2.2
         numpy : 1.21.6
       appdirs : 1.4.4

ansys.mapdl.reader : 0.52.4
tqdm : 4.64.1
matplotlib : 3.5.3
ansys.mapdl.core : 0.63.4
scipy : 1.7.3

example output:

PyMAPDL:

  1086208 -0.53896      -4.5807     -0.43128E-001-0.95561      0.18610      0.17292E-001
  1119277   7.6786      -54.789       9.1757      -13.006       8.5357      -6.9634     
  1119278   4.7530      -73.017       8.5624      -4.3764     -0.73627E-002 -2.2960     
  1119279   3.6917      -67.506       8.3602       2.9245      0.59262      -1.8712     
  1119280   6.1982      -75.804       3.4671       4.7029      -9.1468      0.43384     
  1119281   9.2134      -68.473       4.5270      -7.7405      -19.154      -2.3560     
  1119282  -2.2331      -82.818     -0.80377     -0.80763      -4.6933     -0.82316     
  1119283  -11.522      -223.40      -41.927       89.056      -114.62      -16.256     
  1119284  -4.2330      -68.573     -0.96242       1.3523      -7.9288      -1.9489     
  1119285   7.4691      -71.456       10.541      -11.240      -11.949      -4.9047     

mapdl:

  1086208    -0.538961     -4.58073   -0.0431284    -0.955614     0.186102    0.0172916
  1119277     0.936085     -74.7439      2.06109     -5.03342     -3.35435     -5.49832
  1119278     0.585308     -84.0512       3.4786     -4.43145     -9.51501     -2.02587
  1119279       2.5793     -79.4133      2.91215     -1.75299     -6.42161     -1.47082
  1119280       2.9808     -89.1512     0.283342     -4.16926     -8.42763    -0.116176
  1119281      7.15402     -74.3251      4.08113     -9.16976     -13.1968     -1.89268
  1119282     -2.37682     -88.1327     0.234747      0.23904     -3.91442     0.441464
  1119283     -4.29061     -172.119     -31.7608      84.6058      -99.442     -11.1323
  1119284       -3.617     -67.7072    -0.313461     0.521451     -7.62063     -1.82923
  1119285      1.89622     -83.4006      6.06942     0.206192      -11.354     -1.41076

📝 Steps to reproduce

I am extracting stress using PyMAPDL Reader (v2022, python 3.7, virtual environment). Reading a result file (generated by v18) into a Result Class, and then using "nodal_stress" method on the result class.

Then I compare the output with older output that was generated using an APDL script, using mapdl v18 in batch mode. Using the same result file. Using "PRNSOL,S,COMP".

Using only corner nodes on outside surfaces of solid-element components

💻 Which operating system are you using?

Linux

🐍 Which Python version are you using?

3.7

📦 Installed packages

aiohttp==3.8.3
aiosignal==1.3.1
ansys-api-mapdl==0.5.1
ansys-api-platform-instancemanagement==1.0.0b3
ansys-corba==0.1.1
ansys-dpf-core==0.7.1
ansys-dpf-gate==0.3.0
ansys-dpf-gatebin==0.3.0
ansys-dpf-post==0.2.5
ansys-grpc-dpf==0.7.0
ansys-mapdl-core==0.63.4
ansys-mapdl-reader==0.52.4
ansys-platform-instancemanagement==1.0.2
appdirs==1.4.4
async-timeout==4.0.2
asynctest==0.13.0
attrs==22.1.0
cachetools==5.2.0
certifi==2022.12.7
charset-normalizer==2.1.1
cycler==0.11.0
fonttools==4.38.0
frozenlist==1.3.3
geomdl==5.3.1
google-api-core==2.11.0
google-api-python-client==2.70.0
google-auth==2.15.0
google-auth-httplib2==0.1.0
googleapis-common-protos==1.57.0
grpcio==1.51.1
httplib2==0.21.0
idna==3.4
imageio==2.22.4
importlib-metadata==5.1.0
kiwisolver==1.4.4
matplotlib==3.5.3
multidict==6.0.3
numpy==1.21.6
packaging==22.0
pexpect==4.8.0
Pillow==9.3.0
pooch==1.6.0
protobuf==3.20.3
protoc-gen-swagger==0.1.0
psutil==5.9.4
ptyprocess==0.7.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
pyiges==0.2.1
pyparsing==3.0.9
python-dateutil==2.8.2
pyvista==0.37.0
requests==2.28.1
rsa==4.9
scipy==1.7.3
scooby==0.7.0
six==1.16.0
tqdm==4.64.1
typing_extensions==4.4.0
uritemplate==4.1.1
urllib3==1.26.13
vtk==9.2.2
wslink==1.9.2
yarl==1.8.2
zipp==3.11.0

[iceblink-ansys]

Just noticed that there is also a:
/EFACET,4
in the APDL script. And according to the manual "/EFACET may affect results averaging."

Is there a way to do the same in PyAnsys?

[germa89]

Hi @iceblink-ansys

This is quite interesting topic, I'm going to ping @mikerife and @pmaroneh. Also @pvargasm which did an interesting job about averaging element/nodal.

[iceblink-ansys]

So it seems that these are the relevant commands:
/GRAPHICS,POWER
AVRES,1,
/POST1
/EFACET,4
PRNSOL,S,COMP

[mikerife]

Hi @iceblink-ansys
See the PyMAPDL documentation - there is an implementation of the /efacet apdl command:
https://mapdl.docs.pyansys.com/release/0.63/mapdl_commands/post1/_autosummary/ansys.mapdl.core.Mapdl.efacet.html?highlight=efacet#ansys.mapdl.core.Mapdl.efacet

MAPDL in batch uses Full Graphics by default, so be sure to be consistent there (MAPDL interactive uses Power graphics by default). That can affect averaging as well. I suggest using Full graphics in each method and compare the results.

Mike

[germa89]

We need to gather all of this somewhere... Maybe the FAQ section

[germa89]

MAPDL in batch uses Full Graphics by default, so be sure to be consistent there (MAPDL interactive uses Power graphics by default). That can affect averaging as well. I suggest using Full graphics in each method and compare the results.

@mikerife do you mean that the graphics configuration can affect listing output (i.e. PRNSOL) as well??

[mikerife]

Hi @germa89 yes. The *get and *vget (and some other apdl commands) always execute with full graphics even if power graphics is activated. Mike

[iceblink-ansys]

Hi @iceblink-ansys See the PyMAPDL documentation - there is an implementation of the /efacet apdl command: https://mapdl.docs.pyansys.com/release/0.63/mapdl_commands/post1/_autosummary/ansys.mapdl.core.Mapdl.efacet.html?highlight=efacet#ansys.mapdl.core.Mapdl.efacet

MAPDL in batch uses Full Graphics by default, so be sure to be consistent there (MAPDL interactive uses Power graphics by default). That can affect averaging as well. I suggest using Full graphics in each method and compare the results.

Mike

How does one set these options for ansys-mapdl-reader though? Or is that not possible and should I just fully switch to ansys-mapdl-core instead? That would be a shame, the reader is really easy to use.

On a sidenote: why is reading of result files not implemented as an iterator object? Loading the entire result file into memory is a bit excessive. And where is the proper place to ask questions such as this?

[mikerife]

Hi @iceblink-ansys
I just realized that I messed up my previous answer as I had PyMAPDL in mind. Let me revisit this.
Mike

[germa89]

Hi @iceblink-ansys

Regarding your questions...

How does one set these options for ansys-mapdl-reader though? Or is that not possible and should I just fully switch to ansys-mapdl-core instead? That would be a shame, the reader is really easy to use.

Well... I agree reader is very easy to use, unfortunately the decision is to deprecate reader in favor of DPF-Core/Post. The reader is reading the binary directly so I presume the graphics configuration should not affect much. I do believe it will affect in the CDB files because I think the respective graphics commands are written in it. Probably @pmaroneh and @mikerife can add more on this.

On a sidenote: why is reading of result files not implemented as an iterator object? Loading the entire result file into memory is a bit excessive. And where is the proper place to ask questions such as this?

It is an interesting concept. Well.... one of the reasons to use DPF is that it implements lazy evaluation, so the RST file is not loaded fully until needed. That is why also we are working on replace reader by DPF. See ansys/pymapdl#1300

[germa89]

Hi @iceblink-ansys I just realized that I messed up my previous answer as I had PyMAPDL in mind. Let me revisit this. Mike

Don't worry at all. Think about it and let me know your conclusions, I will do the corresponding changes asap. :)

[iceblink-ansys]

Well... I agree reader is very easy to use, unfortunately the decision is to deprecate reader in favor of DPF-Core/Post. The reader is reading the binary directly so I presume the graphics configuration should not affect much. I do believe it will affect in the CDB files because I think the respective graphics commands are written in it. Probably @pmaroneh and @mikerife can add more on this.

On a sidenote: why is reading of result files not implemented as an iterator object? Loading the entire result file into memory is a bit excessive. And where is the proper place to ask questions such as this?

It is an interesting concept. Well.... one of the reasons to use DPF is that it implements lazy evaluation, so the RST file is not loaded fully until needed. That is why also we are working on replace reader by DPF. See pyansys/pymapdl#1300

Thanks for that, I guess I need to have a look at DPF-Core. (I was under the impression that one always needs a GUI for the DPF modules, and I only have a CLI). I was now looking into PyMapdl but that seems to be an almost one-on-one passthrough of APDL commands. Maybe good enough for now, but (like all new Ansys users) I'm trying to avoid the archaic (yet powerful) APDL as much as possible.

[iceblink-ansys]

Update: seems like DPF-Core is not able to do anything with result files older than v2021, so unfortunately this is not (yet) an option for me. It's okay for me to tinker around with the latest and greatest PyAnsys, but our result files will be old for quite a while...

[germa89]

Update: seems like PDF-Core is not able to do anything with result files older van v2021, so unfortunately this is not (yet) an option for me. It's okay for me to tinker around with the latest and greatest PyAnsys, but our result files will be old for quite a while...

Interesting...

@PProfizi @cbellot000 can you confirm this??

[akaszynski]

On a sidenote: why is reading of result files not implemented as an iterator object? Loading the entire result file into memory is a bit excessive. And where is the proper place to ask questions such as this?

Excellent question. It absolutely should be an iterator, but the decision to go down the path of loading the entire file to memory was made as a memory/CPU tradeoff.

[akaszynski]

How does one set these options for ansys-mapdl-reader though? Or is that not possible and should I just fully switch to ansys-mapdl-core instead? That would be a shame, the reader is really easy to use.

I'm afraid that the best way to do this would now (as mentioned by @germa89), would be to use PyDPF-Core. This reader will always have a relatively limited functionality since it's a rewrite (based on public FORTRAN headers) of how MAPDL reads rst files, rather than directly using the same libraries (as used with DPF).

Regardless, I appreciate the feedback and @PProfizi, I though we supported earlier than v2021 result files. I think you just need the latest install and you should be able to read older files. @iceblink-ansys, post any traceback you get from attempting to read those files in PyDPF-Core Issues.

[PProfizi]

Hi @akaszynski, @iceblink-ansys,
concerning DPF, it is shipped within the ANSYS Workbench unified install since 2021.1, yet it should be able to read results as old as version "10.0".

[iceblink-ansys]

Thanks for looking into it. Maybe it's simply a matter of removing the hardcoded version check then :)

See ansys/pydpf-core#748 (comment)