igortg
commented
1 month ago Hey @florianreinle. Thanks for you extensive report about the issue.
On first look, I'd say this should be solved by the Ansys Rocky itself. PyRocky would then only export some API to start non-blocking grid function calculations. Doing this from PyRocky will always have the downside of transfer larges amount of data back and forth, as you mentioned.
I believe we have some improvements related to Custom Grid Function calculation performance on the Ansys Rocky roadmap. I'll present your issue to the team and check what they have to say.
đź“ť Description of the feature
Rocky can take a lot of time (e.g. also experienced 30min) calculating multiple grid functions during post processing, especially with high cell count and/or complex motionframes. I assume it's due to being designed serial/single thread for this task. I'm focusing on grid functions since it makes sense in this case.
đź’ˇ Steps for implementing the feature
1. PyRocky needs to handle parallel or async tasks to pass through. Current Error: the calling thread is not the owner of this proxy, create a new proxy in this thread or transfer ownership. Since pyro5 should work with this i consider this feasible. I can try to assist as well. BTW: Python 3.13 is out able to do multithreading without GIL (free threading). That’s the clear future, but I guess this does not make PyRocky a problematic import since no GIL is used and risk is only for the programmer… I’m not an expert regarding this.
2. Rocky needs to open a separate thread for each call so multiple calls can be put into action. To do it the simplest way, I suggest parallelism via time steps. Each time step has it's own result data, race conditions can be easily avoided.
2.1 If the timestep option is chosen, it makes also sense to avoid users creating race conditions there self. In this case you could create a GetGridFunctionParallel API call. CON is to transfer bigger data chunks via PyRocky, PRO no parallel PyRocky needed, easier for coding
2.2 A very nice idea is also editing GetGridFunction to accept more options: time_step --> starttime step (if only this parameter --> works like today for backwards compatibility) NEW: end_time_step (iterate parallel form start to end if this parameter is given) NEW: parallel as bool or num_threads as int (works serial if false, 1 or not there, but parallel in the other cases) This way let's assume parallel execution is a bit more risky you can use a try-catch block in the user python program if parallel gives an exception you can try the same in serial mode again. This way the code afterwards will see the same data. The value of start and end makes it easy to create a resulting array parallel but still in the right order.
What do you, dear experts, think about this?
Best regards
Florian Reinle
đź”— Useful links and references
No response