This new test battery consists of a large number of simulation that are directly implemented in Gitlab: whenever a new push is made, the continuous integration pipeline launches a build phase and then a test phase. If everything went right, the merge is possible. Otherwise, the user is required to correct its mistake before being able to merge. This improves the robustness of the code and avoids mistakes.

Implemented by: Arthur Fanara, 2025

Gitlab's Continuous Integration (CI) is launched through the file .gitlab-ci.yml in which two steps are defined:

1. 1. A build phase that generates, in Unix, the Prepro.exe, Lagamine.exe and Select.exe. This gives a first information on the state of the code.
2. 2. A test phase that launches as many tests as implemented. It uses three .sh files:
   • run_tests.sh: this file cycles through the $CI_PROJECT/Tests/ folders in order to run each test. The prepro and lagamine is run for each test, then the .ipe, .ipn and .ipr are compared with the original results that may be found in a folder ExpectedResults. For the moment, the tolerance is set to 3% and any value below 1E-7 is rounded to 0.0.
   • run_prepro.sh: this file calls the newly generated prepro.exe for the test case.
   • run_lagamine.sh: this file calls the newly generated lagamine.exe for the test case. The .ipe, .ipn, .ipr, .log and .out are generated and exported in the artifacts of Gitlab, for further referencing. The simulations are run in sequential as all routines do not allow the use of parallelisation at the moment.

If one of the steps goes wrong, the job fails and the user is not allowed to merge its modification.

The folder 'Tests' contains all the tests.

Each test is in a separate subfolder named with the same name as the test defined in “Test_battery.txt”, preceded by its number. For example, 26_HYPOFE2_KFLU1 is the 26th test in the battery, and it verifies the integrity of the law HYPOFE2 with parameter KFLU1.

In this test subfolder, there are:

1. The necessary files to run the prepro and lagamine: .DAT, .LAG, .PRI, .DEP, .LIC, and so on.
2. A subfolder named “ExpectedResults” in which the results file are: the .ipn, .ipe and .ipr.

No other file should be found in this subfolder.

Local report

The local report is attached to the test folder and has the same name as the test (name_test.rep). This local report contains the details of the error(s) obtained when comparing the new test results to the reference.

It is structured as follows:

• Local error
• Decision (Success/ Failure): depending on the value of the error, the test is considered as passed or failed. The recommanded acceptance value for the error is 0.1% for a Mini test and 1% for a Big test.

Fig. ##: Local report Global report

The global report is attached to the principal python script folder (Report_date.rep).

It contains the following information:

• Number of tests
• Global error
• List of tests
• Decision (Success/ Failure): once one test is failed, the whole test battery is failed
• List of failed tests (if the test battery is failed)

Fig. ##: Global report

In order to ensure that your developments in the Lagamine code will keep functioning properly, it is highly recommanded that you add one or several tests specific to the law(s) or element(s) you use and develop.

To test a material law or an element, you should design a simple test, using only 1 element when possible. Preferably, your test should not take more than a few seconds to run. If you need to test something more complex, you can also create a “Big” test. However, the total number of Big tests should be limited to avoid excessive computational times for the whole test battery.
For instance, to test the visco-plastic 'CHAB' law, I created a test using a single element submitted to 2 cycles of alternated tension and compression (see CHAB_SC_TMF).

Once you have designed your test and created the necessary simulation files, you must identify the important variables that indicate whether your law/element is behaving as it should.
For the 'CHAB' law, I will check the values of the stress tensor, the thermal strain, the plastic strain along the loading direction, and the damage variables. These values can be obtained via the *.ipe result file.

Be sure to print out the values you want to check at the time step(s) you see fit.
To define the time steps at which you want a printing, you can use ILSAV = 1 or 2 in the ex.dat file.
Check Appendix 1: Printing options and Appendix 9: Printing files for more info about printing files.

After you have created your test and identified the variables that need to be checked, you need to write the comparator code.

This code should be written in a Python script. If Python is not already installed on your computer, you can download it from the official Python website: https://www.python.org/downloads/
Several editors exist to facilitate coding and debugging with Python. You can use Spyder or Visual Studio Code for instance.

For the comparator code, it is recommanded to use one of the existing comparators as an example. You can search in the Dokuwiki tests that use the same type of result files as you to find a code similar to what you should write.

To add a new test to the battery, you should:

• Add the new test to “http://www.lagamine.uliege.be/dokuwiki/doku.php/battery/listtests”
• Modify the file Test_battery.txt on Obelix: add the name of the new test
• Add the folder containing your test to the test battery directory. This folder should contain:
  • The files of simulation (with the same name as the test)
  • The reference simulation folder (with the same name as the test + “_ref”)
  • The comparator python script (with the same name as the test)