pymapdl
pymapdl copied to clipboard
Array parameters retrieval fail when the size is very big
As the title.
It will take extensive debugging in MAPDL.
Example
import numpy as np
from ansys.mapdl.core import launch_mapdl
mapdl = launch_mapdl()
mapdl.finish()
mapdl.clear()
mapdl.prep7()
dimensions = 1E7
mapdl.dim("myarr","", dimensions)
mapdl.vfill("myarr","rand",0, 1) # filling array with random numbers
# Retrieving
values = mapdl.parameters["myarr"] # fail with "MapdlExitedError: MAPDL server connection terminated"
# Setting
myarr = np.random.rand(int(1E7))
mapdl.parameters["myarr2"] = myarr*2
Hi German, So it looks like the issue is calling *VREAD in a loop; at some point MAPDL crashes (still not sure if it is PyMAPDL or MAPDL). For this case I got rid of all the loops to set parameters and used the good old method of defining a huge table as a CSV and read it all at once using *TREAD. Luckily it works!
What does mapdl.parameters["SET_PARAM"] = ... use behind the scenes? I am assuming it does exactly what I tried using *VREAD; that is why I see the exact same behaviour / crash?
By @ayush-kumar-423 Related to #2844
More info on this:
<_InactiveRpcError of RPC that terminated with:
status = StatusCode.RESOURCE_EXHAUSTED
details = "Received message larger than max (450037158 vs. 268435456)"
debug_error_string = "UNKNOWN:Error received from peer ipv4:10.105.52.33:50052 {created_time:"2024-07-30T11:52:58.266896+02:00", grpc_status:8, grpc_message:"Received message larger than max (450037158 vs. 268435456)"}"
Details:
Retrieving...
Traceback (most recent call last):
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/parameters.py", line 371, in __getitem__
val_ = interp_star_status(self._mapdl.starstatus(key))
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/_commands/session/run_controls.py", line 590, in starstatus
return self.run(command, **kwargs)
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/mapdl_core.py", line 2212, in run
text = self._run(command, verbose=verbose, mute=mute)
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/mapdl_grpc.py", line 904, in _run
response = self._send_command(cmd, mute=mute)
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/errors.py", line 330, in wrapper
raise MapdlExitedError(
ansys.mapdl.core.errors.MapdlExitedError: MAPDL server connection terminated unexpectedly while running:
*STATUS,MYARR,,,,,,,,,,,
called by:
_send_command
with the following error
<_InactiveRpcError of RPC that terminated with:
status = StatusCode.RESOURCE_EXHAUSTED
details = "Received message larger than max (450037158 vs. 268435456)"
debug_error_string = "UNKNOWN:Error received from peer ipv4:10.105.52.33:50052 {created_time:"2024-07-30T11:52:58.266896+02:00", grpc_status:8, grpc_message:"Received message larger than max (450037158 vs. 268435456)"}"
>
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/german.ayuso/pymapdl/tmp/tmp3.py", line 26, in <module>
values = mapdl.parameters["myarr"] # fail with "MapdlExitedError: MAPDL server connection terminated"
File "/Users/german.ayuso/pymapdl/src/ansys/mapdl/core/parameters.py", line 379, in __getitem__
raise IndexError("%s not a valid parameter_name" % key)
IndexError: MYARR not a valid parameter_name
Code to replicate
Details
import numpy as np
from ansys.mapdl.core import launch_mapdl
mapdl = launch_mapdl()
mapdl.finish()
mapdl.clear()
mapdl.prep7()
for dimensions in np.logspace(1, 7, 7):
print(dimensions)
dimensions = int(dimensions)
mapdl.dim("myarr","", dimensions)
mapdl.vfill("myarr","rand",0, 1) # filling array with random numbers
# Retrieving
print("Retrieving...")
values = mapdl.parameters["myarr"] # fail with "MapdlExitedError: MAPDL server connection terminated"
print("Retrieved.")
# Setting
myarr = np.random.rand(dimensions)
print("Setting...")
mapdl.parameters["myarr2"] = myarr*2
print("Set")
This can be overcomed by changing the env var PYMAPDL_MAX_MESSAGE_LENGTH:
export PYMAPDL_MAX_MESSAGE_LENGTH=471859200
It set to -1 it should remove any lenght limit.
Ideally we would like a more explicit message when failing.