[mohsen.shiea]

Hi Everybody,

As you might know, Ubuntu isn't yet supported by Ansys Inc and the roadmap of this company doesn't show any plan for supporting this operating system in the near future. For those who work with Ubuntu, which is one of the most popular Linux distributions, there are two main solutions to run Ansys products on this operating system: 1) Using virtual machines to run Ansys on a supported OS, which is heavyweight and has a limited performance and 2) installing the required packages and libraries on Ubuntu, some of which are not available on the Ubuntu repositories. In this regard, another viable alternative is installing Ansys on a docker container, which is fast and lightweight, and has virtually the same performance as the host machine. Of course, there are also disadvantages, which mainly concern the security issues of docker containers, but as long as the users are trustful and also attentive to what they do, the security risk may hardly be higher than those of the host machine. In addition, in the following procedure, limited permissions are given to the container to reduce its vulnerabilities to security threats.

In what follows, I share a procedure for installing and running Ansys software with GUI on a CentOS container. The main task is to setup both the container and host machine for running the GUI of the Ansys products, i.e. sharing the X11 screen of the host machine with the container. Therefore, most of the procedure deals with this task. It should be noted that this procedure is developed and tested on a machine with Ubuntu 20.04 OS (normal installation), which has two graphic cards, Intel UHD graphics and Nvidia GPU. The host machine uses the latest Nvidia driver available on the Ubuntu repository. Personally, I prefer to enable the Nvidia GPU on-demand mode to save power. This capability is called "PRIME Render Offload", about which more information can be found in the following links: https://askubuntu.com/questions/1201...erver-settings and https://download.nvidia.com/XFree86/...eroffload.html. However, this choice should not be a problem for those who prefer to use only Nvidia GPU or Intel graphics. Although, modifications to the following procedure may be needed to address issues related to different graphic configurations! For instance, two environment variables __NV_PRIME_RENDER_OFFLOAD and __GLX_VENDOR_LIBRARY_NAME are not needed if Nvidia GPU is selected as the only active graphic card.

At first, it is recommended to check that the Nvidia GPU is available and works correctly by running the following command (the two env variables are needed if "Nvidia On-Demand" is enabled otherwise you should omit them):

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep "OpenGL"

You should be able to see lines in the output similar to the following:

OpenGL vendor string: NVIDIA Corporation
OpenGL core profile version string: 4.6.0 NVIDIA 450.66
OpenGL version string: 4.6.0 NVIDIA 450.66
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 450.66

Also, executing the following command should open a window with rotating gears (again the two env variables are needed if "Nvidia On-Demand" is enabled otherwise you should omit them):

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears

In the case of professional-grade GPUs, you might keep glxgears running and launch the following command "nvidia-sim" in another terminal to confirm that the "glxgears" process is listed in the output.

The failure of one of the above tests may indicate a problem with the Nvidia driver setup.

Next step is the installation of the docker daemon following this link https://docs.docker.com/engine/install/ubuntu/
and then configuring it such that a non-root user can manage the docker as explained in this link: https://docs.docker.com/engine/insta...-non-root-user.

Enabling GPU in the container needs Nvidia Container Runtime, which can be installed following this link https://github.com/NVIDIA/nvidia-container-runtime. Essentially, you need to install the repository for Ubuntu (there is a link for doing that) and then installing "nvidia-container-runtime". Finally, you register the nvidia-runtime in the docker daemon by following one of the methods mentioned in the link (I recommend creating and modifying Daemon configuration file: /etc/docker/daemon.json)

You may also want to change the default storage location (/var/run/docker) of the docker images and running containers. It can be done by setting, respectively, "data-root" and "exec-root" configuration options in the Daemon configuration file. More information can be found here: https://docs.docker.com/config/daemo...emon-directory. Remember that the final docker image will have a dimension equal to the Ansys installation size, Therefore, it is better to change the location of the image storage if enough space in not available on the system partition. Reboot the system if the storage locations are changed.

One last configuration for the docker daemon is enabling ivp6 in containers as explained in this link https://docs.docker.com/config/daemon/ipv6/. You just need to add the same lines shown in the link to the /etc/docker/daemon.json and reload the docker daemon. Reboot the system.
You can check if the ivp6 is enabled for the docker by examining the output of the following command: "sudo ip addr". The following lines should appear under the docker0 connection:

inet6 2001:db8:1::1/64 scope global tentative

valid_lft forever preferred_lft forever

inet6 fe80::1/64 scope link tentative

valid_lft forever preferred_lft forever

As mentioned previously, the container uses the X11 screen of the host machine. Thus, it is expected that the packages related to X11 required by Ansys are installed on the host machine. In my case (normal ubuntu installation and not minimal), I had to install the following font packages:

sudo apt install fontconfig xfonts-base xfonts-100dpi xfonts-75dpi xfonts-cyrillic

Reboot the system after installing the font packages.

We continue to create a container. The starting point is to use a CentOS image released by Nvidia Corporation on docker hub (https://hub.docker.com/u/nvidia), which is considered as a trustful source. The images with opengl (https://hub.docker.com/r/nvidia/opengl) are the appropriate ones. Use the following command to download the CentOS image with opengl:

docker pull nvidia/opengl:1.2-glvnd-runtime-centos7

Next, a dockerfile is created to add the required packages for Ansys installation to the downloaded image. Here is the dockerfile used by me (Don't forget to replace *** with the version of the Ansys software to be installed):

FROM nvidia/opengl:1.2-glvnd-runtime-centos7

RUN yum -y update && yum clean all

RUN yum -y install epel-release

RUN yum -y install sudo which lshw pciutils less tcsh wget gzip tar unzip vim \
firefox net-tools lsof strace gvfs mesa-demos mesa-dri-drivers mesa-filesystem \
mesa-libEGL mesa-libGLES mesa-libGL mesa-libGLU mesa-libOSMesa \
mesa-libgbm mesa-private-llvm openmotif glx-utils rpm tcl tk perl python3 gcc \
SDL blas compat-gcc-44 compat-gcc-44-c++ compat-libstdc++-33.i686 \
compat-libstdc++-33 compat-libtiff3 ftgl gcc-c++ glib2.i686 glib2 glibc.i686 glibc \
gstreamer gtk2 gtk2.i686 libSM libSM.i686 libXfont libXft.i686 libXft libXp \
libXp.i686 libXpm libXScrnSaver libXt libXt.i686 libXxf86vm libXxf86vm.i686 \
libjpeg-turbo libjpeg-turbo.i686 libmng libnotify libpng.i686 libpng libpng12 \
libpng12.i686 librdmacm libstdc++ libstdc++.i686 libstdc++-devel \
libstdc++-devel.i686 libtiff libtiff.i686 libxkbcommon-x11 motif motif.i686 \
openssl11-libs postgresql-libs python3-libs redhat-lsb sssd-client.i686 sssd-client \
tbb xalan-c xerces-c xorg-x11-fonts-ISO8859-1-75dpi xorg-x11-fonts-cyrillic xterm \
zlib giflib bzip2-libs qwt expat xorg-x11-apps mlocate dnf \
xcb-util-renderutil-0.3.9-3.el7.x86_64 libicu-50.2-4.el7_7.x86_64 \
xcb-util-0.4.0-2.el7.x86_64 xcb-util-image-0.4.0-2.el7.x86_64 \
xcb-util-keysyms-0.4.0-1.el7.x86_64 pcre2-utf16-10.23-2.el7.x86_64 \
xcb-util-wm-0.4.1-5.el7.x86_64 qt5-qtbase-common-5.9.7-2.el7.noarch \
qt5-qtbase-5.9.7-2.el7.x86_64 qt5-qtbase-gui-5.9.7-2.el7.x86_64 \
qt5-qtxmlpatterns-5.9.7-1.el7.x86_64 qt5-qtdeclarative-5.9.7-1.el7.x86_64 \
qt5-qtlocation-5.9.7-1.el7.x86_64 qt5-qtsensors-5.9.7-1.el7.x86_64 \
qt5-qtwebchannel-5.9.7-1.el7.x86_64 2:libogg-1.3.0-7.el7.x86_64 \
1:libvorbis-1.3.3-8.el7.1.x86_64 1:libtheora-1.1.1-8.el7.x86_64 \
cdparanoia-libs-10.2-17.el7.x86_64 libXv-1.0.11-1.el7.x86_64 \
libvisual-0.4.0-16.el7.x86_64 xml-common-0.6.3-39.el7.noarch \
iso-codes-3.46-2.el7.noarch orc-0.4.26-1.el7.x86_64 \
gstreamer-plugins-base-0.10.36-10.el7.x86_64 libxslt-1.1.28-5.el7.x86_64 \
libwebp-0.3.0-7.el7.x86_64 gdk-pixbuf2 libbsd libcanberra-gtk2 \
gstreamer1-plugins-bad-free gstreamer1-plugins-base; yum clean all

# Workbench and Ansys products
RUN echo -e '#!/bin/bash\n/ansys_inc/v***/Framework/bin/Linux64/runwb2 -oglhw' > /usr/bin/wb2 && \
    chmod +x /usr/bin/wb2

ENV ANSYS***_DIR=/ansys_inc/v***/ansys
ENV PATH=/ansys_inc/v***/fluent/bin:$PATH
ENV PATH=/ansys_inc/v***/CFX/bin:$PATH
ENV PATH=/ansys_inc/v***/icemcfd/linux64_amd/bin:$PATH

Run the following command to create the new image with the packages installed (Replace [ImageName] and [ImageTag] with those of your choice, e.g. ansys-docker:ver1.0):

docker build --tag [ImageName]:[ImageTag] .

Use the following commad to make sure that the image with the selected name and tag is created:

docker images

Create the following script (let's name it as "runContainer") to run a container based on the created image (replace [ContainerName] and [HostName] with those of your choice):

#!/bin/bash
export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia

# Name of the container in the docker daemon
CONTAINER_NAME=[ContainerName]

# Run the container based on image [ImageName]:[ImageTag]
docker run \
    --runtime=nvidia -it --rm --hostname=[HostName] \
    --device=/dev/dri:/dev/dri --env="DISPLAY=$DISPLAY" \
    --env="XAUTHORITY=$XAUTHORITY" --env="XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" \
    -e __NV_PRIME_RENDER_OFFLOAD=1 -e __GLX_VENDOR_LIBRARY_NAME=nvidia \
    -e NVIDIA_DRIVER_CAPABILITIES=all -e NVIDIA_VISIBLE_DEVICES=all \
    --volume="/tmp/.X11-unix/:/tmp/.X11-unix/:rw" -v $XAUTHORITY:$XAUTHORITY \
    -v $XDG_RUNTIME_DIR:$XDG_RUNTIME_DIR \
    --name $CONTAINER_NAME [ImageName]:[ImageTag]

The env variables __NV_PRIME_RENDER_OFFLOAD and __GLX_VENDOR_LIBRARY_NAME are needed to enable Nvidia GPU only when the operation mode "Nvidia On-Demand" is selected on the host.

Open a terminal in the directory of the script and execute the script with ./runContainer to run the container.
Set a password for the root by using "passwd" command and then create a user with the same username and user id and group id of the host machine. The information about the user on the host machine can be fetched by launching "id" command. Set a password also for the created user. Choose strong passwords! Then, the user should be added to the wheel group to be a sudoer. Finally, log in with the created user by:

su - username

Find the "render" group id on the host machine (search /etc/group file) and then create this group with the same group id on the container by using the following command:

sudo groupadd -g [groupid] render

Then add the created user to this group by launching the following command:

sudo usermod -a -G render username

Now open a terminal on the host machine and save the current state of the container as a new image by using the docker commit command (replace [NewImageTag] with that of your choice, e.g. ver2.0):

docker commit [ContainerName] [ImageName]:[NewImageTag]

and then close the container by launching "exit" command.

Now change the runContainer script as below:

#!/bin/bash
export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia

# Name of the container in the docker daemon
CONTAINER_NAME=[ContainerName]

MOUNTDIR=/media/username

docker run \
    --runtime=nvidia -it --rm --user username --hostname=[HostName] \
    --device=/dev/dri:/dev/dri --env="DISPLAY=$DISPLAY" \
    --env="XAUTHORITY=$XAUTHORITY" --env="XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" \
    -e __NV_PRIME_RENDER_OFFLOAD=1 -e __GLX_VENDOR_LIBRARY_NAME=nvidia \
    -e NVIDIA_DRIVER_CAPABILITIES=all -e NVIDIA_VISIBLE_DEVICES=all \
    --volume="/tmp/.X11-unix/:/tmp/.X11-unix/:rw" -v $XAUTHORITY:$XAUTHORITY \
    -v $XDG_RUNTIME_DIR:$XDG_RUNTIME_DIR -v $MOUNTDIR:$MOUNTDIR\
    --name $CONTAINER_NAME [ImageName]:[NewImageTag]

Mount all the Ansys .iso installation files and then execute the modified runContainer script.
Before beginning the installation, run "glxgears" command in the container and you should be able to see the rotating gears on the screen. Only for professional-grade GPUs: don't close the glxgears, open a terminal on the host machine and run "nvidia-smi" command to confirm that the glxgears process is listed in the output.
If glxgears works, proceed with the installation of the Ansys on the container. Enter the directory /media/username/ANSYS******_LINX64_Disk1 and run the script INSTALL as root:

sudo ./INSTALL

No error is expected during the installation. After the installation, enter the folder /usr/ansys_inc/v***/aisol/ and run the following command to grant write permissions to the user for the folder WBMWRegistry:

chmod -R 777 WBMWRegistry/

Again, open a terminal in the host machine and run the following command to save the container, which now includes the Ansys installation, as a new image (replace [LatestImageTag] with that of your choice, e.g. ver3.0 or latest):

docker commit [ContainerName] [ImageName]:[LatestImageTag]

It may take several minutes to save the image. Then, close the container by "exit" command and unmount the installation images.

Modify the runContainer script as below (replace *** with the Ansys version):

#!/bin/bash

ARGS=$@

export __NV_PRIME_RENDER_OFFLOAD=1
export __GLX_VENDOR_LIBRARY_NAME=nvidia

CONTAINER_NAME=[ContainerName]

docker container inspect -f '{{.State.Status}}' $CONTAINER_NAME > /dev/null 2>&1

if [ "$?" = "0" ]; then
    docker exec -it $CONTAINER_NAME bash -c ". ~/.bashrc ; $ARGS"
else
    ANSYSWORKDIR=/home/username/Ansys
    ANSYSDIR=/home/username/.ansys
    ANSYSCONFIGDIR=/home/username/.config/Ansys
    FLUENTCONFIGDIR=/home/username/.fluentconf

    docker run \
        --runtime=nvidia -it --rm --user username --hostname=[HostName] \
        --ulimit memlock=-1:-1 --ulimit stack=1073741824:1073741824 \
        --ipc="host" --cap-drop=ALL --security-opt=no-new-privileges \
        --shm-size=2g \
        --device=/dev/dri:/dev/dri --env="DISPLAY=$DISPLAY" \
        --env="XAUTHORITY=$XAUTHORITY" --env="XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" \
        -e __NV_PRIME_RENDER_OFFLOAD=1 -e __GLX_VENDOR_LIBRARY_NAME=nvidia \
        -e NVIDIA_DRIVER_CAPABILITIES=all -e NVIDIA_VISIBLE_DEVICES=all \
        -e QT_ACCESSIBILITY=1 -e ANSYS***_WORKING_DIRECTORY=$ANSYSWORKDIR \
        --volume="/tmp/.X11-unix/:/tmp/.X11-unix/:rw" -v $XAUTHORITY:$XAUTHORITY \
        -v $XDG_RUNTIME_DIR:$XDG_RUNTIME_DIR \
        -v $ANSYSDIR:$ANSYSDIR -v $ANSYSCONFIGDIR:$ANSYSCONFIGDIR \
        -v $FLUENTCONFIGDIR:$FLUENTCONFIGDIR -v $ANSYSWORKDIR:$ANSYSWORKDIR \
        --workdir $ANSYSWORKDIR --name $CONTAINER_NAME [ImageName]:[LatestImageTag]
fi

Create necessary folders to be shared with the container. In my case, I created one folder as the working directory to save or load project files (/home/username/Ansys) and three other folders to keep the settings of the ansys products on the host machine (/home/username/.ansys, /home/username/.config/Ansys, /home/username/.fluentconf), otherwise the settings are reset each time that you close the container.
Now you can execute the runContainer script to run the container and test Ansys products.
Note that you can open only one instance of the container with the same name, but it is not an issue if you want to open several Ansys products at the same time. The above script allows to run several Ansys products provided that the container is running. To do that, while the container is running, it is enough to execute the runContainer script in a new terminal of the host machine, passing the name of the desired Ansys product as an argument, e.g.:

./runContainer fluent

[EternalSeekerX]

Originally Posted by mohsen.shiea

- snip -

I use docker on my fedora to get a working ansys and starccm+ too. However I must enable systemd to get dbus working such that openmpi can actually work. How are you getting around that ? Does the nvidia docker base have systemd enabled? What's also wierd is my container only runs on Fedora no issue, has some issues on ubuntu, manjaro and suse. However doesn't bug me, since with systemd enabled centos I can run starccm+ flawlessly as well. It also seems like you are committing the ansys install inside the docker? I didn't do that, I just mounted a real volume on host and installed it such that I don't need to commit a huge 30gb install.

[mohsen.shiea]

Originally Posted by EternalSeekerX

I use docker on my fedora to get a working ansys and starccm+ too. However I must enable systemd to get dbus working such that openmpi can actually work. How are you getting around that ? Does the nvidia docker base have systemd enabled? What's also wierd is my container only runs on Fedora no issue, has some issues on ubuntu, manjaro and suse. However doesn't bug me, since with systemd enabled centos I can run starccm+ flawlessly as well. It also seems like you are committing the ansys install inside the docker? I didn't do that, I just mounted a real volume on host and installed it such that I don't need to commit a huge 30gb install.

Thanks for sharing your experience.
So Regarding the systemd, it is not enabled in the base Nvidia image.
I am using Intel as MPI type for Fluent and I haven't seen any issue with running Fluent in parallel mode (Ansys v2020R2). In addition, I used Ansys Meshing (v2020R2) to create a mesh of large number of cells and I am almost sure that, in that case, more than one processor were used. I worked also with ICEM CFD and Ansys Design Modeler without facing any particular issue. For CFX and Turbo Grid, I didn't conduct any simulation with them but both start without any error!
Again, as I said, I am using Intel mpi instead of openmpi. But, for example, Fluent works with openmpi in the above container as long as the required packages are installed (in my case, openssh-server and openssh-clients). There might be a warning of "Linux kernel CMA support", which seems to be due to restricted permissions of the container, but it can be avoided by setting an env variable (export OMPI_MCA_btl_vader_single_copy_mechanism=none). This is based on my experience, of course. Therefore, I don't have an idea about the issues you had with dbus and openmpi. The only thing that I remember about dbus is that there might be some restrictions placed by the apparmor profile used by docker daemon.
Finally, your suggestion for keeping the installation on a separate volume instead of committing it to the image is great. As soon as I get some free time, I would try it and then share the experience here.

[EternalSeekerX]

Originally Posted by mohsen.shiea

Thanks for sharing your experience.
So Regarding the systemd, it is not enabled in the base Nvidia image.
I am using Intel as MPI type for Fluent and I haven't seen any issue with running Fluent in parallel mode (Ansys v2020R2). In addition, I used Ansys Meshing (v2020R2) to create a mesh of large number of cells and I am almost sure that, in that case, more than one processor were used. I worked also with ICEM CFD and Ansys Design Modeler without facing any particular issue. For CFX and Turbo Grid, I didn't conduct any simulation with them but both start without any error!
Again, as I said, I am using Intel mpi instead of openmpi. But, for example, Fluent works with openmpi in the above container as long as the required packages are installed (in my case, openssh-server and openssh-clients). There might be a warning of "Linux kernel CMA support", which seems to be due to restricted permissions of the container, but it can be avoided by setting an env variable (export OMPI_MCA_btl_vader_single_copy_mechanism=none). This is based on my experience, of course. Therefore, I don't have an idea about the issues you had with dbus and openmpi. The only thing that I remember about dbus is that there might be some restrictions placed by the apparmor profile used by docker daemon.
Finally, your suggestion for keeping the installation on a separate volume instead of committing it to the image is great. As soon as I get some free time, I would try it and then share the experience here.

Could be, without systemd and xinit the flex license server wlll not run and fluent will have module failiure on Ansys 2019R3, with systemd enabled, no issues, everything works flawlessly.

[EternalSeekerX]

Hello again, so without further adieu let me post a small guide on how this is done. Please note that the way I am using docker is not really how its intended and as such may put some docker purist off. Also I have only gotten this to work well in Fedora using moby-engine, so using docker-ce on other distro may vary since this requires you to load systemd and init. Anyway lets get started.

First read this page: https://hub.docker.com/_/centos you can follow this to get a systemd enabled docker image which we will use. So lets get stared.

1). First create a dockerfile and save it to a directory you are comfortable with

2). Open a terminal in that directory and type

docker build --rm -t local/c7-systemd .

3). Once this is complete you will have pulled a docker image named local/c7-systemd that contains a CentOS 7.8 base image with systemd enabled

4). Now create a new bash script called Centos7-base and save it to a directory you are comfortable with (make sure to mark it as executable)

5). Open a terminal in the directory you saved the above script and type:

./Centos7-base

Wait till everything loads (this is where you may find some issues, with fedora everything loads except LSB (which is only because no static ip is set and can be ignored) but other distro using docker-ce some other parts such as fuse will fail, there are ways to get around it using more flags under docker run, but that is up to you to find out. Then once you see the CentOS7 login prompt, open another terminal and type in

docker exec -it CentOS7 /bin/bash

This is then load into bash shell for the centos docker (Note CentOS7 is the name of the docker session as indicated in the bash script, change it fi you want

6). Run yum update, and the enable extra repo you need (if any) and install all required dependencies for ansys and the system, such as mesa and xorg and gcc libraries and such. Remember the image is just a base image, you still need to populate it with packages.

7). Then open a new terminal and commit the changes using docker commit command,

docker commit CentOS7 c7-coreplus:ver2

you can either specify the name (i.e CentOS7) or with the seed (which you can find out using docker ps command). This will take a few minutes, for me it took about 5 minutes.

8). After in that same session kill the docker using the docker kill CentOS7 command. Now you can close all the terminals

9. Now create a new script Centos7-base2 and save it the directory you are working with. This new script will load the new docker image you just committed with real /opt and /home volumes including your /run volume where you will find any usb or cd images when you load them into your distro (in the script case, your host /run/media is now /mnt inside your container).

10). Make sure to mount your install media first and make sure your host can access it, then run the new script and docker exec into it. Check you can see the install media in /mnt, if so proceed to install the software, install destination should be your /opt directory. Because of the way the volume is mounted, anything you write in your opt folder inside the container is going to your actual /opt folder (so we are not writing it to the docker image directly, this also saves us from having to commit the docker again), once that is done, you can then setup your license server and run it like you would on an actual CentOS7 install.

The only difference here is im running a full blown centos distro using host resources, and any and all commercial apps will work.

[mohsen.shiea]

Originally Posted by EternalSeekerX

Could be, without systemd and xinit the flex license server wlll not run and fluent will have module failiure on Ansys 2019R3, with systemd enabled, no issues, everything works flawlessly.

I understand. You need systemd to run services of the license manager of Ansys. In my case, the license is already available on a server machine.

[EternalSeekerX]

Originally Posted by mohsen.shiea

I understand. You need systemd to run services of the license manager of Ansys. In my case, the license is already available on a server machine.

Ahh that makes sense!! I'm gonna see if I can run the license on the host side, maybe I don't need full systemd. Just tried and it fails to find the server, oh well xD

[LUIS1717]

Excellent Post,
I am very grateful for your help!!!!

[LUIS1717]

Hi everyone,



first of all thanks very much for the post.


I dont know if it problem with my machine, but I follow every step and I cannot run wb2. Fluents, CFX, etc works, but wb not. Any other has the same issue?



This is the output from terminal


[luis@luishp lic_admin]$ wb2

Unhandled exception caught :

System.DllNotFoundException: Ans.QT.dll
at Ansys.UI.Toolkit.QT.Application.SetPluginDirectory () [0x000f2] in <e7c7446121f840669624fa95f993ad23>:0
at Ansys.UI.Toolkit.QT.Application..ctor () [0x00006] in <e7c7446121f840669624fa95f993ad23>:0
at Ansys.UI.Toolkit.QT.UIFactory.newApplication () [0x00000] in <e7c7446121f840669624fa95f993ad23>:0
at Ansys.UI.Toolkit.UIFactory.newApplication () [0x0000f] in <10126af23bce40849ad4266af89c19d0>:0
at Ansys.UI.Toolkit.Application.InstantiateIApplicati on () [0x00000] in <10126af23bce40849ad4266af89c19d0>:0
at Ansys.UI.Toolkit.Application..cctor () [0x0000a] in <10126af23bce40849ad4266af89c19d0>:0
--- System.TypeInitializationException: The type initializer for 'Ansys.UI.Toolkit.Application' threw an exception.
at Ansys.UI.UIManager..ctor () [0x00060] in <ae858717b3ff416bbc7818997e97838b>:0
at Ansys.UI.UIManager.get_Instance () [0x00029] in <ae858717b3ff416bbc7818997e97838b>:0
at Ans.Program.Runtime.InitializeSplashScreen () [0x00060] in <cf1e21c8e81e4bdba692baf9de1b41d1>:0
at Ans.Program.Runtime.Initialize (Ans.Program.RuntimeSettings settings) [0x00237] in <cf1e21c8e81e4bdba692baf9de1b41d1>:0
at Ans.Program.ExecutableBase.Run (Ans.Program.CommandLineParse parser) [0x0000d] in <f93613d2cf72432192ab9d28923ae59b>:0
at Ans.Program.ExecutableBase.DoMain (System.String[] args) [0x000cf] in <f93613d2cf72432192ab9d28923ae59b>:0

/proc/self/maps:
00400000-009fd000 r-xp 00000000 08:01 57018323 /usr/ansys_inc/v211/Tools/mono/Linux64/bin/mono
00bfd000-00bff000 r--p 005fd000 08:01 57018323 /usr/ansys_inc/v211/Tools/mono/Linux64/bin/mono
00bff000-00c0c000 rw-p 005ff000 08:01 57018323 /usr/ansys_inc/v211/Tools/mono/Linux64/bin/mono


....


7fff3bc47000-7fff3bc68000 rw-p 00000000 00:00 0 [stack]
7fff3bcb3000-7fff3bcb7000 r--p 00000000 00:00 0 [vvar]
7fff3bcb7000-7fff3bcb9000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]

Native stacktrace:

/ansys_inc/v211/Tools/mono/Linux64/bin/mono() [0x4b7a08]
/ansys_inc/v211/Tools/mono/Linux64/bin/mono() [0x42b25c]
/usr/lib64/libpthread.so.0(+0xf630) [0x7fa74e76a630]
/lib64/ld-linux-x86-64.so.2(+0xbbe6) [0x7fa74f53dbe6]
/lib64/ld-linux-x86-64.so.2(+0x1466c) [0x7fa74f54666c]
/lib64/ld-linux-x86-64.so.2(+0xf7d4) [0x7fa74f5417d4]
/lib64/ld-linux-x86-64.so.2(+0x13b8b) [0x7fa74f545b8b]
/usr/lib64/libc.so.6(+0x13d842) [0x7fa74e2b3842]
/lib64/ld-linux-x86-64.so.2(+0xf7d4) [0x7fa74f5417d4]
/usr/lib64/libc.so.6(__libc_dlopen_mode+0x52) [0x7fa74e2b3902]
/usr/lib64/libpthread.so.0(+0xfdb3) [0x7fa74e76adb3]
/usr/lib64/libpthread.so.0(+0xff7c) [0x7fa74e76af7c]
/usr/lib64/libpthread.so.0(__pthread_unwind+0x42) [0x7fa74e769362]
/usr/lib64/libpthread.so.0(+0x8ef7) [0x7fa74e763ef7]
/ansys_inc/v211/Tools/mono/Linux64/bin/mono() [0x757c70]
/ansys_inc/v211/Tools/mono/Linux64/bin/mono() [0x756e78]
/usr/lib64/libpthread.so.0(+0x7ea5) [0x7fa74e762ea5]
/usr/lib64/libc.so.6(clone+0x6d) [0x7fa74e2749fd]

Debug info from gdb:


================================================== ===============
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
================================================== ===============

/ansys_inc/v211/Framework/bin/Linux64/runwb2: line 22: 942 Aborted (core dumped) $MONO_PREFIX/bin/mono "$@"

[pons]

Originally Posted by LUIS1717

[luis@luishp lic_admin]$ wb2

Unhandled exception caught :

System.DllNotFoundException: Ans.QT.dll

I got the same error. It turns out that the workbench needs an additional package. Try

sudo yum install qt5-qtwebkit.x86_64

inside the container.

(To make the fix permanent, commit the container to a new image)

(BTW many thanks to mohsen.shiea for the very helpful instructions!)

[LUIS1717]

Thanks a lot, i will try it!

[xl576832]

Thanks for your post.