Question on parallel script execution

[michalmac89]

Hello,

I'm working on genetic optimization of a mechanical structure. Given the parallel nature of the algorithm I was wondering whether it would be possible to execute my APDL scripts simultaneously, e.g. launching several docker images. Would that be possible?

Thank you in advance for your time and consideration.

Best regards, Michał.

[CesarRodriguezPereira]

I don't think you even need several docker images, as parallel instances are supported by pyansys in a really intuitive way: you create a pool of workers and then you map the function you want to run, much like you would with regular python pooling or threading. Detailed info in the docs: https://mapdldocs.pyansys.com/api/pool.html

[akaszynski]

I'm working on genetic optimization of a mechanical structure. Given the parallel nature of the algorithm I was wondering whether it would be possible to execute my APDL scripts simultaneously, e.g. launching several docker images. Would that be possible?

That's exactly what https://mapdldocs.pyansys.com/user_guide/pool.html# does. Launch several local instances of MAPDL and control them via the Pool class.

Alternatively, if you wanted to connect to several remote instances (either created by docker compose or started up on several VMs), you can connect to those instances via:

from ansys.mapdl.core import Mapdl

mapdl_a = Mapdl(ip=<IP of instance A>, port=<port of instance A>)
mapdl_b = Mapdl(ip=<IP of instance B>, port=<port of instance B>)
mapdl_c = Mapdl(ip=<IP of instance C>, port=<port of instance C>)

@CesarRodriguezPereira beat me to it by a second!

[CesarRodriguezPereira]

BTW, after just having used the Pool today for the first time (instead of running one model after another), an important note: the output from the map function is not ordered by your inputs, instead it's sorted by which models on your pool ran first. So you may need to pass your inputs as an output of your mapped function, in order to sort the actual outputs later.

[michalmac89]

Thanks a lot. I played a bit and this feature works like a wonder!
I have two follow-up questions:

1. In my input file I rely on relative paths to include some additional components. When I execute models in a pool, it seems that the relative paths do not work as ANSYS can't locate those files. Is there a way to set a working directory per script?

2. I tried to run the pool method on my Linux machine (tried on Windows so far) with ANSYS2020R2 (v202). I was not able to run the instance. Is there anything that I should set beforehand?

Afterwards, the kernel of my notebook dies.

I run scripts with command line at /opt/ansys_inc/v202/ansys/bin/mapdl

Thank you in advance, Michal.

PS. I noticed that some code in the documentation requires an update to link to latest package names. May I submit a merge request with changes to the docs?

[akaszynski]

In my input file I rely on relative paths to include some additional components. When I execute models in a pool, it seems that the relative paths do not work as ANSYS can't locate those files. Is there a way to set a working directory per script?

You can set the working directory of the pool from LocalMapdlPool, but that will configure the run location of the pool root directory, and the individual instances. This design choice was made to avoid conflicts with identical MAPDL job names. As for setting the working directory per instance of the pool, that's probably a bit harder to control. I'd just go with providing absolute paths for each input file.

I tried to run the pool method on my Linux machine (tried on Windows so far) with ANSYS2020R2 (v202). I was not able to run the instance. Is there anything that I should set beforehand?

The pool should have errored out stating that it only supports v211 or newer. v202 isn't supported by Linux via gRPC and individual instances will die, and apparently as an added bonus will kill the jupyter kernel. I'll submit a PR fixing this.

PS. I noticed that some code in the documentation requires an update to link to latest package names. May I submit a merge request with changes to the docs?

Contributions are always appreciated. Our CI/CD won't run for external contributors, so if you submit the PR don't be surprised or worried if the GitHub Actions fail. I'll verify it locally.

[natter1]

Are there any guidelines as to when such a pooling is faster compared to doing one script after the other? I would expect a FE simulation to be quite good at using several cores for a single model (but might be wrong).

[CesarRodriguezPereira]

The main guideline for pooling FE models is: go as parallell as you can, as long as you can keep every problem in RAM and don't hit any I/O bottlenecks. Due to Amdahl's law, throwing double the cores at a single problem won't cut the simulation time in half, while running twice the models at a time would cut the total execution time in half.

And yeah, FE models are great at parallel computing, but they're in the "coarse grained" parallelization (the task is well split and doesn't require that much communication). That said, running different models in parallel takes it one step further, making the whole problem "embarrassingly parallel", which is the best you can hope for.

In any case, if you're considering having really large batches of models, I would try first time them with different nproc in the mapdl instance, just to check how parallizable it is, and also to monitor RAM use.

[jgd10]

It seems this discussion has run its course so Ill close the issue for now :) .

[akaszynski]

Still need to add this:

The pool should have errored out stating that it only supports v211 or newer. v202 isn't supported by Linux via gRPC and individual instances will die, and apparently as an added bonus will kill the jupyter kernel. I'll submit a PR fixing this.