Abaqus Hardware and Licensing, Standalone and Via the 3DEXPERIENCE Platform

Personally, I find solving finite element problems way more interesting than installing the software, ensuring the hardware works and worrying about licenses. Unfortunately, hardware and licenses are needed to do the more interesting stuff. Therefore I’ll say a bit more about that in this blog.

I’ll go into the traditional options with standalone Abaqus as well as the running an .inp file using the 3DEXPERIENCE platform on the cloud.

Standalone

Traditionally, Abaqus is run as a standalone product, not connected to 3DEXPERIENCE. I'll first talk about hardware and software in this case.

Hardware - Standalone

Here at Simuleon we once considered writing a blog about hardware suggestions for Abaqus usage. However, we decided against this, since it can change quite quickly. To see whether your system is supported, check the program directories. If you forget the link, don't worry, this is also easily accessed via our support page: https://www.simuleon.com/simulia-support/ under Simulia hardware requirements.

This will tell you which operating systems are supported, which versions of fortran are needed for user subroutine linking, etc. so you can determine whether your system is ok.

For questions such as hardware selection, Simulia's knowledge base can provide additional info. QA00000059173 gives information on "Obtaining Performance Estimates for SIMULIA Abaqus with Different Hardware Configurations". This gives general recommendations as well as links to several papers. Check this out when you are thinking of getting a new system.

Licensing - Standalone

The most common licensing scheme nowadays (and the only one offered to new customers) is the use of extended tokens. In this case there are separate licenses for the graphical user interface and to run analyses. These licenses and tokens can be used for the entire extended portfolio, so not only Abaqus, but also Isight, FE-Safe, Tosca. The amount of tokens required depends on what you want to do. For Abaqus, the main driving factor is the amount of cores that the analysis will be run on. This can be calculated using the formula: INT(5 * N^0.422), our token calculator can calculate this for you. 

These licenses are usually leased for a year. It is also possible to buy them or to have a quarterly license. In the last case, there is an uplift.

With this licensing scheme tokens are used most effectively if there is constant simulation load throughout the year. To run an incidental project where results are required quickly (many cores used) a large amount of tokens is required for at least a quarter.

Running Analyses on the Cloud

Dassault now also offers the possibility to run Abaqus analyses while being connected to the platform. Here we already have an input file that has already been created in Abaqus (standalone) and this will be run via the platform. This requires the 'simulation manager'-app, which is part of the 'all physics analyst'- role. I'll first give a step-by-step example of how this works, and then discuss the options for hardware and license usage on the platform.

To run an analysis on the platform, we first need to log in. This assumes an account with the correct role is available.

In the V+R quadrant of the compass, select the Simulation Manager App and drag it to the dashboard (the area on the right):

You can enlarge this area with the diagonal arrow in the top right corner if you want to. Ass indicated in the screen, a new simulation can be started via the +-sign:

This opens the 'Create Simulation'-tab where you provide a title for the Simulation. This will allow you to find it back more easily later on.

As indicated, you can then simply drop your input file:

In this case, I'll use an example from one of our tutorials. Click on the 'play'-button in the top right corner to configure and run your analysis:

The next screen provides options that are similar to those when setting up a job in Abaqus/CAE. I will not discuss the 'license' or 'configuration' option now, but save that for the section on license and hardware respectively.

What is left is the input file selection, as well as the analysis type. Here you can select whether you want to run the entire analysis, or only do a syntax check or data check:

Y

You can also select the Abaqus version, currently 2019, 2020 en 2021 are available:

For the results format, you can select an .odb file and/or sim file and/or experience content.

The solver precision and output precision can be set, similar to an Abaqus job.

Once you click run, the analysis will be started.

You can then see what the current status is, as well as the output files generated:

There is also a monitor tab, that allows you to see a graph of e.g. total energy, kinetic energy, stable time increment etc. to track the progress of the analysis.

The log tab gives access to various output files:

The summary tab gives a summary of the analysis, including license usage:

Once the analysis is fully completed and postprocessing is done, the default image of a gear is changed into an image of the actual model:

We can then access the results. The .odb can be downloaded, but we can also view the results directly on the platform, e.g. using the 3D play app:

We can then show a movie of the von Mises stress, for example:

Video missing here 

You can also find a demo of this, a bit further down in this blog.

Hardware -3DEXPERIENCE Platform

When running an analysis on the platform, we don't need our own hardware.

Currently, there are three configuration available: small, medium and large, corresponding to 18, 36 or 144 cores.

When running on the cloud, the hardware is included. This means you do not need to invest in your own 144-core machine.

Licensing -3DEXPERIENCE Platform

In order to use the3DEXPERIENCE platform, a relevant role is required as a prerequisite. To run the analysis itself, there are two types of licenses available: tokens and credits.

Tokens work in the same way as we explained for the standalone product: you pay an (annual) fee and are allowed to use the tokens during this period. They can be checked out from a pool while running an analysis, and once the analysis completes they are returned to the pool.

In contrast to tokens, credits are consumable, they are 'used up'. If you pay for an analysis using credits, then you consume a certain amount of per hour. This amount depends on the amount of cores you run the analysis on. 

This allows a lot of flexibility. It may not be needed to buy additional tokens for the entire year if you want to run one analysis on more cores or when you want to run a small job, while a larger one is still running and consuming all tokens.

Comparison

This being said, let's compare both options:

In general, the platform option gives more flexibility and the option to pay for what you actually use, rather than the maximal load you need at some time during the year. This comes at the extra cost of needing the3DEXPERIENCE role. I haven't done a direct cost comparison between cloud tokens, cloud credits and stand alone tokens, please contact our sales department if you are thinking about using this and require more information.

Furthermore, my colleague Peter Straetemans had a nice presentation at the SIMIF, where he compared showed these options and also compared run times for different examples. He showed that for a large Abaqus/Standard model on 18 cores, the memory on the cloud did not suffice (paging) and the run time on the cloud was significantly slower than on his workstation. Small and medium sized jobs, as well as an Explicit job did work well. For explicit, using 144 cores on the cloud allowed the analysis to be run about two times as fast, compared to the 32 cores available in his work station. 

He also gave a very nice demo of running an analysis on the cloud, that I'd like to share with you:

There is a video missing here

Thanks Peter!

Conclusion

Though I haven't done enough testing to be 100% sure what is most useful when, the possibility to run on the cloud seems especially useful if you incidentally have a much higher workload than you normally have. Cloud hardware and consumable credits could then meet such an incidental peak, without the necessity to invest in hardware or a huge number of tokens. For a constant workload, I expect the traditional approach where Abaqus is run on the user's own system is still more cost effective, especially if the hardware is already available. I can imagine a hybrid approach where a base-load is covered by tokens and bursts are covered by credits could also make sense in some cases.